There seem to be 2 different approaches taken in the foreman code
1)
seems to indicate the intention to nullify the organization-host
association if organization gets deleted. This tells me that its ok to
delete the org with hosts associated to it.
"has_many_hosts :dependent => :nullify"
Looking at the commit dates for both, they were merged a mere month after
each other (jan - feb 2013). 2 came before 1 .
I prefer 1 over 2 … Unassociate the Org from the Host if the org gets
deleted instead of blocking the delete. Whats your preferred approach.
Kindly let me know.
To me, as a user, if I delete an org (or location) I'd simply want the
foreman resources to be unassociated from it. It may be the case, for
example, that a resource like a provisioning template is shared among
multiple orgs. A host is different, I know, in that it can belong to only
one org but I would still lean towards consistency by throwing it into the
bucket of unassociated hosts.
···
On Wed, Jun 8, 2016 at 3:05 PM, Partha Aji wrote:
There seem to be 2 different approaches taken in the foreman code
1) https://github.com/theforeman/foreman/blob/develop/app/models/taxonomies/organization.rb#L8
seems to indicate the intention to nullify the organization-host
association if organization gets deleted. This tells me that its ok to
delete the org with hosts associated to it.
“has_many_hosts :dependent => :nullify”
Looking at the commit dates for both, they were merged a mere month after
each other (jan - feb 2013). 2 came before 1 .
I prefer 1 over 2 … Unassociate the Org from the Host if the org gets
deleted instead of blocking the delete. Whats your preferred approach.
Kindly let me know.
I think that has to be the choice - whilst you could go to the edit
location page and unassign every signle resource from a bazillion tabs,
it very tedious, and ends up with the same result anyway. So long as we
document the behaviour clearly, then I think it's fine to just drop
associations
···
On 8 June 2016 at 21:23, Tom McKay wrote:
To me, as a user, if I delete an org (or location) I’d simply want the
foreman resources to be unassociated from it. It may be the case, for
example, that a resource like a provisioning template is shared among
multiple orgs. A host is different, I know, in that it can belong to only
one org but I would still lean towards consistency by throwing it into the
bucket of unassociated hosts.
I lean towards the second atm, if taxonomies are enabled we should not add
more actions leading to hosts being unassociated. I consider host without
organization in organization enabled instance as a bug. Long term I'd like to
see all hosts that are unassociated today being in fact associated to some
default org. Once we have that, we could set the host association to this new
default org on organization deletion.
Anyway if there are more votes for option 1, I as a user would like to know
that there were some hosts that were moved to the unasssociated hosts bucket.
At least a warning would be good.
···
--
Marek
On Wednesday 08 of June 2016 16:23:48 Tom McKay wrote:
To me, as a user, if I delete an org (or location) I’d simply want the
foreman resources to be unassociated from it. It may be the case, for
example, that a resource like a provisioning template is shared among
multiple orgs. A host is different, I know, in that it can belong to only
one org but I would still lean towards consistency by throwing it into the
bucket of unassociated hosts.
On Wed, Jun 8, 2016 at 3:05 PM, Partha Aji paji@redhat.com wrote:
There seem to be 2 different approaches taken in the foreman code
1) https://github.com/theforeman/foreman/blob/develop/app/models/taxonomies/o
rganization.rb#L8 seems to indicate the intention to nullify the
organization-host
association if organization gets deleted. This tells me that its ok to
delete the org with hosts associated to it.
“has_many_hosts :dependent => :nullify”
Looking at the commit dates for both, they were merged a mere month after
each other (jan - feb 2013). 2 came before 1 .
I prefer 1 over 2 … Unassociate the Org from the Host if the org gets
deleted instead of blocking the delete. Whats your preferred approach.
Kindly let me know.
I prefer still allowing the user to delete the org but tell the user
what took place.
As a user, I find it very bothersome when systems block removal of
objects because 'that object is in use'. When you are trying to remove
things a system should always allow removal without forcing you to
determine which things need to be un-associated to complete the task at
hand.
Mike
···
On 06/09/2016 07:37 AM, Marek Hulán wrote:
> Hello
>
> I lean towards the second atm, if taxonomies are enabled we should not add
> more actions leading to hosts being unassociated. I consider host without
> organization in organization enabled instance as a bug. Long term I'd like to
> see all hosts that are unassociated today being in fact associated to some
> default org. Once we have that, we could set the host association to this new
> default org on organization deletion.
>
> Anyway if there are more votes for option 1, I as a user would like to know
> that there were some hosts that were moved to the unasssociated hosts bucket.
> At least a warning would be good.
>
> --
> Marek
>
> On Wednesday 08 of June 2016 16:23:48 Tom McKay wrote:
>> To me, as a user, if I delete an org (or location) I'd simply want the
>> foreman resources to be unassociated from it. It may be the case, for
>> example, that a resource like a provisioning template is shared among
>> multiple orgs. A host is different, I know, in that it can belong to only
>> one org but I would still lean towards consistency by throwing it into the
>> bucket of unassociated hosts.
>>
>> On Wed, Jun 8, 2016 at 3:05 PM, Partha Aji wrote:
>>> While working on one of the org deletion bugs (
>>> http://projects.theforeman.org/issues/15336) I hit upon this
>>> inconsistency in Foreman code base and would like suggestions on the
>>> agreeable behavior.
>>>
>>> So here is the user action
>>> 1) User creates an org
>>> 2) Assigns a host to that org
>>> 3) Deletes that org
>>>
>>> There seem to be 2 different approaches taken in the foreman code
>>> 1)
>>> https://github.com/theforeman/foreman/blob/develop/app/models/taxonomies/o
>>> rganization.rb#L8 seems to indicate the intention to nullify the
>>> organization-host
>>> association if organization gets deleted. This tells me that its ok to
>>> delete the org with hosts associated to it.
>>> "has_many_hosts :dependent => :nullify"
>>>
>>> 2)
>>> https://github.com/theforeman/foreman/blob/develop/test/functional/api/v2/
>>> locations_controller_test.rb#L74 seems to indicate we do Not want to
>>> delete orgs/locations if hosts are attached to it. "should NOT destroy
>>> location if hosts use it" .
>>>
>>> Looking at the commit dates for both, they were merged a mere month after
>>> each other (jan - feb 2013). 2 came before 1 .
>>>
>>> I prefer 1 over 2 .. Unassociate the Org from the Host if the org gets
>>> deleted instead of blocking the delete. Whats your preferred approach.
>>> Kindly let me know.
>>>
>>> Partha
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "foreman-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to foreman-dev+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
–
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650-254-4248
> From: "Marek Hulán" <mhulan@redhat.com>
> To: foreman-dev@googlegroups.com
> Cc: "Tom McKay" <thomasmckay@redhat.com>, "ohadlevy" <ohadlevy@redhat.com>
> Sent: Thursday, June 9, 2016 10:37:23 AM
> Subject: Re: [foreman-dev] Org with host deletion question
>
> Hello
>
> I lean towards the second atm, if taxonomies are enabled we should not add
> more actions leading to hosts being unassociated. I consider host without
> organization in organization enabled instance as a bug. Long term I'd like to
> see all hosts that are unassociated today being in fact associated to some
> default org. Once we have that, we could set the host association to this new
> default org on organization deletion.
Yea but the default org stuff is just totally broken. We tried to set this
by default (there are settings to do this) and stuff explodes because Puppet
parser generated objects don't get in a taxonomy. It's not trivial at all.
> Anyway if there are more votes for option 1, I as a user would like to know
> that there were some hosts that were moved to the unasssociated hosts bucket.
> At least a warning would be good.
I would vote for disassociating, the "XX is still used by YY" errors in Foreman
are very frustrating, and in this case I don't think it's especially unwarranted.
Giving the user a warning saves them a lot of hassle. If the hosts aren't useful
anymore, they can then go and delete them, or if they want to keep using them,
assign them to new orgs/locations.
···
----- Original Message -----
–
Marek
On Wednesday 08 of June 2016 16:23:48 Tom McKay wrote:
To me, as a user, if I delete an org (or location) I’d simply want the
foreman resources to be unassociated from it. It may be the case, for
example, that a resource like a provisioning template is shared among
multiple orgs. A host is different, I know, in that it can belong to only
one org but I would still lean towards consistency by throwing it into the
bucket of unassociated hosts.
On Wed, Jun 8, 2016 at 3:05 PM, Partha Aji paji@redhat.com wrote:
There seem to be 2 different approaches taken in the foreman code
1) https://github.com/theforeman/foreman/blob/develop/app/models/taxonomies/o
rganization.rb#L8 seems to indicate the intention to nullify the
organization-host
association if organization gets deleted. This tells me that its ok to
delete the org with hosts associated to it.
“has_many_hosts :dependent => :nullify”
Looking at the commit dates for both, they were merged a mere month after
each other (jan - feb 2013). 2 came before 1 .
I prefer 1 over 2 … Unassociate the Org from the Host if the org gets
deleted instead of blocking the delete. Whats your preferred approach.
Kindly let me know.
I lean towards the second atm, if taxonomies are enabled we should not
add
more actions leading to hosts being unassociated. I consider host without
organization in organization enabled instance as a bug. Long term I’d
like to
see all hosts that are unassociated today being in fact associated to
some
default org. Once we have that, we could set the host association to
this new
default org on organization deletion.
Yea but the default org stuff is just totally broken. We tried to set this
by default (there are settings to do this) and stuff explodes because
Puppet
parser generated objects don’t get in a taxonomy. It’s not trivial at all.
Anyway if there are more votes for option 1, I as a user would like to
know
that there were some hosts that were moved to the unasssociated hosts
bucket.
At least a warning would be good.
I would vote for disassociating, the “XX is still used by YY” errors in
Foreman
are very frustrating, and in this case I don’t think it’s especially
unwarranted.
Giving the user a warning saves them a lot of hassle. If the hosts aren’t
useful
anymore, they can then go and delete them, or if they want to keep using
them,
assign them to new orgs/locations.
–
Marek
On Wednesday 08 of June 2016 16:23:48 Tom McKay wrote:
To me, as a user, if I delete an org (or location) I’d simply want the
foreman resources to be unassociated from it. It may be the case, for
example, that a resource like a provisioning template is shared among
multiple orgs. A host is different, I know, in that it can belong to
only
one org but I would still lean towards consistency by throwing it into
the
bucket of unassociated hosts.
On Wed, Jun 8, 2016 at 3:05 PM, Partha Aji paji@redhat.com wrote:
rganization.rb#L8 seems to indicate the intention to nullify the
organization-host
association if organization gets deleted. This tells me that its ok
to
delete the org with hosts associated to it.
“has_many_hosts :dependent => :nullify”
>
> > From: "Marek Hulán" <mhulan@redhat.com>
> > To: foreman-dev@googlegroups.com
> > Cc: "Tom McKay" <thomasmckay@redhat.com>, "ohadlevy" <ohadlevy@redhat.com>
> > Sent: Thursday, June 9, 2016 10:37:23 AM
> > Subject: Re: [foreman-dev] Org with host deletion question
> >
> > Hello
> >
> > I lean towards the second atm, if taxonomies are enabled we should not add
> > more actions leading to hosts being unassociated. I consider host without
> > organization in organization enabled instance as a bug. Long term I'd like
> > to see all hosts that are unassociated today being in fact associated to
> > some default org. Once we have that, we could set the host association to
> > this new default org on organization deletion.
>
> Yea but the default org stuff is just totally broken. We tried to set this
> by default (there are settings to do this) and stuff explodes because Puppet
> parser generated objects don't get in a taxonomy. It's not trivial at all.
Yes, that's why I said long term. I'm just trying to not make the situation
even worse until we get to the point where we feel comfortable with how
taxonomies work.
> > Anyway if there are more votes for option 1, I as a user would like to
> > know
> > that there were some hosts that were moved to the unasssociated hosts
> > bucket. At least a warning would be good.
>
> I would vote for disassociating, the "XX is still used by YY" errors in
> Foreman are very frustrating, and in this case I don't think it's
> especially unwarranted. Giving the user a warning saves them a lot of
> hassle. If the hosts aren't useful anymore, they can then go and delete
> them, or if they want to keep using them, assign them to new
> orgs/locations.
How about it would let me choose which org/loc the host should be reassigned
during the deletion? And if it's too strict, there could be one option - leave
disassociated ideally with some hint that such host are only visible in any
context.
···
On Thursday 09 of June 2016 14:33:04 Stephen Benjamin wrote:
> ----- Original Message -----
–
Marek
–
Marek
On Wednesday 08 of June 2016 16:23:48 Tom McKay wrote:
To me, as a user, if I delete an org (or location) I’d simply want the
foreman resources to be unassociated from it. It may be the case, for
example, that a resource like a provisioning template is shared among
multiple orgs. A host is different, I know, in that it can belong to
only
one org but I would still lean towards consistency by throwing it into
the
bucket of unassociated hosts.
On Wed, Jun 8, 2016 at 3:05 PM, Partha Aji paji@redhat.com wrote:
There seem to be 2 different approaches taken in the foreman code
1) https://github.com/theforeman/foreman/blob/develop/app/models/taxonomi
es/o
rganization.rb#L8 seems to indicate the intention to nullify the
organization-host
association if organization gets deleted. This tells me that its ok to
delete the org with hosts associated to it.
“has_many_hosts :dependent => :nullify”
Looking at the commit dates for both, they were merged a mere month
after
each other (jan - feb 2013). 2 came before 1 .
I prefer 1 over 2 … Unassociate the Org from the Host if the org gets
deleted instead of blocking the delete. Whats your preferred
approach.
Kindly let me know.
> Could we perhaps go with option 1 in the CLI/API and then for the UI,
> warn users that the org has hosts (but allow them to continue if they
> click ok)?
>
+1 a confirm dialog seems a good option to me. API/CLI could solve the
issue with a --force parameter. By default it would warn, stop and
advice using --force if you really want to proceed.
If that's not working for other I'd like to see at least a message about
what's been disassociated.
----- Original Message -----
> From: "Marek Hulán" <mhulan@redhat.com <mailto:mhulan@redhat.com>>
> To:foreman-dev@googlegroups.com <mailto:foreman-dev@googlegroups.com>
> Cc: "Tom McKay" <thomasmckay@redhat.com <mailto:thomasmckay@redhat.com>>, "ohadlevy"
<ohadlevy@redhat.com <mailto:ohadlevy@redhat.com>>
> Sent: Thursday, June 9, 2016 10:37:23 AM
> Subject: Re: [foreman-dev] Org with host deletion question
>
> Hello
>
> I lean towards the second atm, if taxonomies are enabled we should not add
> more actions leading to hosts being unassociated. I consider host without
> organization in organization enabled instance as a bug. Long term I'd like to
> see all hosts that are unassociated today being in fact associated to some
> default org. Once we have that, we could set the host association to this new
> default org on organization deletion.
Yea but the default org stuff is just totally broken. We tried to
set this
by default (there are settings to do this) and stuff explodes
because Puppet
parser generated objects don't get in a taxonomy. It's not trivial
at all.
> Anyway if there are more votes for option 1, I as a user would like to know
> that there were some hosts that were moved to the unasssociated hosts bucket.
> At least a warning would be good.
I would vote for disassociating, the "XX is still used by YY" errors
in Foreman
are very frustrating, and in this case I don't think it's especially
unwarranted.
Giving the user a warning saves them a lot of hassle. If the hosts
aren't useful
anymore, they can then go and delete them, or if they want to keep
using them,
assign them to new orgs/locations.
> --
> Marek
>
> On Wednesday 08 of June 2016 16:23:48 Tom McKay wrote:
> > To me, as a user, if I delete an org (or location) I'd simply
want the
> > foreman resources to be unassociated from it. It may be the
case, for
> > example, that a resource like a provisioning template is shared
among
> > multiple orgs. A host is different, I know, in that it can
belong to only
> > one org but I would still lean towards consistency by throwing
it into the
> > bucket of unassociated hosts.
> >
> > On Wed, Jun 8, 2016 at 3:05 PM, Partha Aji <paji@redhat.com > <mailto:paji@redhat.com>> wrote:
> > > While working on one of the org deletion bugs (
> > > http://projects.theforeman.org/issues/15336) I hit upon this
> > > inconsistency in Foreman code base and would like
suggestions on the
> > > agreeable behavior.
> > >
> > > So here is the user action
> > > 1) User creates an org
> > > 2) Assigns a host to that org
> > > 3) Deletes that org
> > >
> > > There seem to be 2 different approaches taken in the foreman code
> > > 1)
> > >
https://github.com/theforeman/foreman/blob/develop/app/models/taxonomies/o
> > > rganization.rb#L8 seems to indicate the intention to nullify the
> > > organization-host
> > > association if organization gets deleted. This tells me that
its ok to
> > > delete the org with hosts associated to it.
> > > "has_many_hosts :dependent => :nullify"
> > >
> > > 2)
> > >
https://github.com/theforeman/foreman/blob/develop/test/functional/api/v2/
> > > locations_controller_test.rb#L74 seems to indicate we do Not
want to
> > > delete orgs/locations if hosts are attached to it. "should
NOT destroy
> > > location if hosts use it" .
> > >
> > > Looking at the commit dates for both, they were merged a mere
month after
> > > each other (jan - feb 2013). 2 came before 1 .
> > >
> > > I prefer 1 over 2 .. Unassociate the Org from the Host if the
org gets
> > > deleted instead of blocking the delete. Whats your preferred
approach.
> > > Kindly let me know.
> > >
> > > Partha
> > >
> > > --
> > > You received this message because you are subscribed to the
Google Groups
> > > "foreman-dev" group.
> > > To unsubscribe from this group and stop receiving emails from
it, send an
> > > email to foreman-dev+unsubscribe@googlegroups.com
<mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
> > > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the
Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
send an
> email to foreman-dev+unsubscribe@googlegroups.com
<mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-dev+unsubscribe@googlegroups.com
<mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
