On Thursday 09 of June 2016 14:33:04 Stephen Benjamin wrote:
> ----- Original Message -----
> 
> > From: "Marek Hulán" <[email protected]>
> > To: [email protected]
> > Cc: "Tom McKay" <[email protected]>, "ohadlevy" <[email protected]>
> > 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.

--
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 <[email protected]> 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/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"
> > > > 
> > > > 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 [email protected].
> > > > 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 [email protected].
> > 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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to