In regards to issue : Bug #7743: Duplicate OSes can be created - Foreman
From what I can tell and have experienced, the expected behavior is that
you can no longer create an OS with the same Name, Major, and Minor version
as another OS.
I find this to be a problem. As we spin our own distros, we often have
multiple OS which have the same Name, major, minor, but a different
description and subsequently different installation media, provisioning
templates, etc.
We used to be able to do this with 1.6.x but since upgrading to 1.9.x we no
longer can. I am hoping we can have this fixed so we can once again create
"duplicate" OSes. Perhaps add the description as another field to validate
uniqueness.
I didn't look at the code change, but this truly appears to simply be a UI
behavior issue as all of our existing "duplicated" OS do not appear to be
causing any ill effects with foreman thus far.
Thanks,
Ryan
I have exactly the same use case, and have ended up working around it with
lots of variables in my Hostgroups, which I'm not too happy with.
The major problem I had with multiple OSs with different parameters is that
Foreman was randomly reassigning my hosts to different variants of the same
OS based on the Facter facts that it received. There's an open ticket about
this here: Bug #6006: OS facts should not overwrite the OS selected to provision with - Foreman
Maybe the thing to do is go back to allowing "duplicate" OSs, and then when
parsing facts first make sure that the already-assigned OS matches the
specs presented by Facter; if so, do nothing. If not, reassign.
But I'd still not want to reassign at all if the host is Managed, because
the next rebuild would get a different image.
Cheers,
Aaron
···
On Wed, Sep 30, 2015 at 11:24 AM, Ryan Dyer wrote:
In regards to issue : Bug #7743: Duplicate OSes can be created - Foreman
From what I can tell and have experienced, the expected behavior is that
you can no longer create an OS with the same Name, Major, and Minor version
as another OS.
I find this to be a problem. As we spin our own distros, we often have
multiple OS which have the same Name, major, minor, but a different
description and subsequently different installation media, provisioning
templates, etc.
We used to be able to do this with 1.6.x but since upgrading to 1.9.x we
no longer can. I am hoping we can have this fixed so we can once again
create “duplicate” OSes. Perhaps add the description as another field to
validate uniqueness.
I didn’t look at the code change, but this truly appears to simply be a UI
behavior issue as all of our existing “duplicated” OS do not appear to be
causing any ill effects with foreman thus far.
Thanks,
Ryan
–
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.
>
> I found that if I make the following change below to my running server
> (and restart apache) it gives me the functionality I want. YMMV obviously,
> but I'm hoping this can be added to the official code base. Assuming it
> doesn't have some bad side effect I am unaware of.
>
File: app/models/operatingsystem.rb
Line 33
From:
:uniqueness => { :scope => [:major, :minor], :message => N_("Operating
system version already exists")}
To:
:uniqueness => { :scope => [:major, :minor, :description], :message =>
N_("Operating system version already exists")}
Thanks
Ryan
> I have exactly the same use case, and have ended up working around it
> with lots of variables in my Hostgroups, which I'm not too happy with.
>
> The major problem I had with multiple OSs with different parameters is
> that Foreman was randomly reassigning my hosts to different variants of
> the same OS based on the Facter facts that it received. There's an open
> ticket about this here: Bug #6006: OS facts should not overwrite the OS selected to provision with - Foreman
Looks related, and partly what #7743 was addressing by preventing many
OSes with the same attributes.
> Maybe the thing to do is go back to allowing "duplicate" OSs, and then
> when parsing facts first make sure that the already-assigned OS matches
> the specs presented by Facter; if so, do nothing. If not, reassign.
>
> But I'd still not want to reassign at all if the host is Managed,
> because the next rebuild would get a different image.
Yeah, that's a frequent problem and your solution might work. I guess
we'd have to figure out what to do when the host starts reporting an OS
that doesn't match the assigned OS, but is managed (it's used as both a
reporting and provisioning mechanism…).
Ryan, please do file a new bug with the issue(s) that you're getting
from this change and we can begin to track possible fixes.
···
On 30/09/15 19:46, Aaron Stone wrote:
–
Dominic Cleal
dominic@cleal.org
> > I have exactly the same use case, and have ended up working around it
> > with lots of variables in my Hostgroups, which I'm not too happy with.
> >
> > The major problem I had with multiple OSs with different parameters is
> > that Foreman was randomly reassigning my hosts to different variants of
> > the same OS based on the Facter facts that it received. There's an open
> > ticket about this here: Bug #6006: OS facts should not overwrite the OS selected to provision with - Foreman
>
> Looks related, and partly what #7743 was addressing by preventing many
> OSes with the same attributes.
>
> > Maybe the thing to do is go back to allowing "duplicate" OSs, and then
> > when parsing facts first make sure that the already-assigned OS matches
> > the specs presented by Facter; if so, do nothing. If not, reassign.
> >
> > But I'd still not want to reassign at all if the host is Managed,
> > because the next rebuild would get a different image.
>
> Yeah, that's a frequent problem and your solution might work. I guess
> we'd have to figure out what to do when the host starts reporting an OS
> that doesn't match the assigned OS, but is managed (it's used as both a
> reporting and provisioning mechanism…).
>
I wonder how to break the link between provisioning and reporting on this
field? There are a couple of fields that get parsed from facter, including
the architecture and hardware model fields.
Does this problem happen for other fields, for example, if you assign an
x86 architecture in order to provision a 32-bit OS onto an x86_64 system,
does the architecture change to x86_64 after system facts are collected,
causing the next rebuild to be a 64-bit OS build?
Ryan, please do file a new bug with the issue(s) that you're getting
···
On Tue, Oct 6, 2015 at 12:00 AM, Dominic Cleal wrote:
> On 30/09/15 19:46, Aaron Stone wrote:
> from this change and we can begin to track possible fixes.
>
> --
> Dominic Cleal
> dominic@cleal.org
>
> --
> 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.
>
> > Maybe the thing to do is go back to allowing "duplicate" OSs, and then
> > when parsing facts first make sure that the already-assigned OS matches
> > the specs presented by Facter; if so, do nothing. If not, reassign.
> >
> > But I'd still not want to reassign at all if the host is Managed,
> > because the next rebuild would get a different image.
>
> Yeah, that's a frequent problem and your solution might work. I guess
> we'd have to figure out what to do when the host starts reporting an OS
> that doesn't match the assigned OS, but is managed (it's used as both a
> reporting and provisioning mechanism…).
>
> Ryan, please do file a new bug with the issue(s) that you're getting
> from this change and we can begin to track possible fixes.
>
> –
> Dominic Cleal
> dom...@cleal.org
>
The server reporting back to foreman isn't an issue for us based on our use
case. We don't install puppet on the systems as these are "appliances" and
we have our own software upgrade mechanism. So we use foreman strictly for
provisioning bare metal. This is obviously where a difference in use cases
can effect the development of the product. I will open a bug for this
shortly. Thanks for the response.
