Hi,
Over the past few weeks a group of us have proceeded to design out a way
to combine Hosts in foreman with Content Hosts in Katello as well as
possibly providing a design for future integration into the host model.
There have been a few upstream discussions focused on different aspects
of this but I wanted to present our (mostly) finalized design:
There is an initial implementation of the design to show how puppet
related concerns would be abstracted out:
Feedback Welcome! We will be holding a design review very soon as well.
-Justin Sherrill
Couple of questions (keep in mind I am playing "dumb" when asking these so
as not to make assumptions):
- Does "Non-Goal" mean "this out of scope so don't ask about it" ?
- Can you explain a little bit what a 'ContentConcernPackage' is compared
to just an 'Erratum' in this design? I am not following the connection.
- Within secondary goals you mention 'Provisioning' as a concern, but I do
not see that in the design?
- What is a SubscriptionFactName?
- All the concerns are fairly generic sounding in nature except for the
PuppetConcern (i.e. it's not ConfigurationConcern). I don't suppose that
the 'environment_id' on the PuppetConcern could be 'puppet_environment_id'
to be specific?
- Would the proposed API/CLI changes occur if the second approach was
taken? In the second approach, as a developer, do I interact with a host
object always and through it the content and subscription hosts or do I
interact directly with whichever is appropriate?
- Would all hosts have all registered concerns available to them for use?
Eric
···
On Tue, May 5, 2015 at 9:30 AM, Justin Sherrill wrote:
Hi,
Over the past few weeks a group of us have proceeded to design out a way
to combine Hosts in foreman with Content Hosts in Katello as well as
possibly providing a design for future integration into the host model.
There have been a few upstream discussions focused on different aspects of
this but I wanted to present our (mostly) finalized design:
HostUnification - Katello - Foreman
There is an initial implementation of the design to show how puppet
related concerns would be abstracted out:
https://github.com/ShimShtein/foreman/tree/host-concerns
Feedback Welcome! We will be holding a design review very soon as well.
-Justin Sherrill
–
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.
> Hi,
>
> Over the past few weeks a group of us have proceeded to design out a way to
> combine Hosts in foreman with Content Hosts in Katello as well as possibly
> providing a design for future integration into the host model.
>
> There have been a few upstream discussions focused on different aspects of
> this but I wanted to present our (mostly) finalized design:
> HostUnification - Katello - Foreman
Is this Concern pattern a standard thing? I find it very confusing, as
they don't appear to be ActiveSupport::Concern, which Foreman also uses.
subscription-manager facts in the facts page is awesome!
···
On Tue, May 05, 2015 at 09:30:50AM -0400, Justin Sherrill wrote:
There is an initial implementation of the design to show how puppet related
concerns would be abstracted out:
https://github.com/ShimShtein/foreman/tree/host-concerns
Feedback Welcome! We will be holding a design review very soon as well.
-Justin Sherrill
–
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.
> Couple of questions (keep in mind I am playing "dumb" when asking
> these so as not to make assumptions):
>
> 1. Does "Non-Goal" mean "this out of scope so don't ask about it" ?
You can ask, but it is out of scope.
> 2. Can you explain a little bit what a 'ContentConcernPackage' is
> compared to just an 'Erratum' in this design? I am not following the
> connection.
Erratum is a separate object that lives on its own a system cannot be
associated with it unless it has been synced. The same is not true for
packages. A host may have a package installed that has not been synced
and we still need to show that. It may also not have nearly as much
information. We probably could rename it to "InstalledPackage" to make
it a tad more clear.
> 3. Within secondary goals you mention 'Provisioning' as a concern, but
> I do not see that in the design?
Correct. The design was meant to be a achievable implementation and to
allow for further extension into things like provisioning. We did not
fully design out implementation, although it was discussed on the
foreman-dev list. If that design is accepted, the puppet concern would
be the only 'concern' that is pure foreman that would be implemented
right away
> 4. What is a SubscriptionFactName?
This relates to how foreman provides the ability to store different
'sources' of facts. You can see how the chef plugin uses it here:
https://github.com/theforeman/foreman_chef/tree/master/app/models/foreman_chef
> 5. All the concerns are fairly generic sounding in nature except for
> the PuppetConcern (i.e. it's not ConfigurationConcern). I don't
> suppose that the 'environment_id' on the PuppetConcern could be
> 'puppet_environment_id' to be specific?
Correct, as you may have a ChefConcern or SaltConcern that is completely
different. I think naming the PuppetConcern's attribute
'puppet_environment_id' may be a tad verbose.
> 6. Would the proposed API/CLI changes occur if the second approach was
> taken? In the second approach, as a developer, do I interact with a
> host object always and through it the content and subscription hosts
> or do I interact directly with whichever is appropriate?
Yes, assuming the P2 items are tackled, it would remain the same. You
would go through the host object completely.
-Justin
···
On 05/06/2015 01:42 PM, Eric D Helms wrote:
- Would all hosts have all registered concerns available to them for use?
Eric
On Tue, May 5, 2015 at 9:30 AM, Justin Sherrill <jsherril@redhat.com > mailto:jsherril@redhat.com> wrote:
Hi,
Over the past few weeks a group of us have proceeded to design out
a way to combine Hosts in foreman with Content Hosts in Katello as
well as possibly providing a design for future integration into
the host model.
There have been a few upstream discussions focused on different
aspects of this but I wanted to present our (mostly) finalized
design:
http://projects.theforeman.org/projects/katello/wiki/HostUnification
There is an initial implementation of the design to show how
puppet related concerns would be abstracted out:
https://github.com/ShimShtein/foreman/tree/host-concerns
Feedback Welcome! We will be holding a design review very soon as
well.
-Justin Sherrill
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
>
>
> Is this Concern pattern a standard thing? I find it very confusing, as
> they don't appear to be ActiveSupport::Concern, which Foreman also uses.
>
We are thinking about changing it to aspects, which is more consistent with
the academic meaning.
> subscription-manager facts in the facts page is awesome!
>
As a concept we are thinking about multiple providers for facts.
> - Stephen
>
>
-Shimon
···
On Thursday, May 7, 2015 at 10:19:53 AM UTC+3, Stephen Benjamin wrote:
>
>
> Couple of questions (keep in mind I am playing "dumb" when asking these so
> as not to make assumptions):
>
> 1. Does "Non-Goal" mean "this out of scope so don't ask about it" ?
>
> You can ask, but it is out of scope.
>
> 2. Can you explain a little bit what a 'ContentConcernPackage' is
> compared to just an 'Erratum' in this design? I am not following the
> connection.
>
> Erratum is a separate object that lives on its own a system cannot be
> associated with it unless it has been synced. The same is not true for
> packages. A host may have a package installed that has not been synced and
> we still need to show that. It may also not have nearly as much
> information. We probably could rename it to "InstalledPackage" to make it
> a tad more clear.
>
> 3. Within secondary goals you mention 'Provisioning' as a concern, but I
> do not see that in the design?
>
> Correct. The design was meant to be a achievable implementation and to
> allow for further extension into things like provisioning. We did not
> fully design out implementation, although it was discussed on the
> foreman-dev list. If that design is accepted, the puppet concern would be
> the only 'concern' that is pure foreman that would be implemented right away
>
About provisioning: in the new design, it should be separated to multiple
aspects - PXEProvisioning, ImageProvisioning and so on.
We don't have to implement it right away - it can be done as a refactoring
task at a later stage.
>
> 4. What is a SubscriptionFactName?
>
>
> This relates to how foreman provides the ability to store different
> 'sources' of facts. You can see how the chef plugin uses it here:
> https://github.com/theforeman/foreman_chef/tree/master/app/models/foreman_chef
>
>
> 5. All the concerns are fairly generic sounding in nature except for the
> PuppetConcern (i.e. it's not ConfigurationConcern). I don't suppose that
> the 'environment_id' on the PuppetConcern could be 'puppet_environment_id'
> to be specific?
>
>
> Correct, as you may have a ChefConcern or SaltConcern that is completely
> different. I think naming the PuppetConcern's attribute
> 'puppet_environment_id' may be a tad verbose.
>
I agree, it's a bit too verbose - the call will be something like
"host.puppet_aspect.environment". I am not sure that it is not verbose
enough.
···
On Wednesday, May 6, 2015 at 11:59:51 PM UTC+3, jsherril wrote:
> On 05/06/2015 01:42 PM, Eric D Helms wrote:
- Would the proposed API/CLI changes occur if the second approach was
taken? In the second approach, as a developer, do I interact with a host
object always and through it the content and subscription hosts or do I
interact directly with whichever is appropriate?
Yes, assuming the P2 items are tackled, it would remain the same. You
would go through the host object completely.
-Justin
- Would all hosts have all registered concerns available to them for
use?
Eric
On Tue, May 5, 2015 at 9:30 AM, Justin Sherrill <jshe...@redhat.com > <javascript:>> wrote:
Hi,
Over the past few weeks a group of us have proceeded to design out a way
to combine Hosts in foreman with Content Hosts in Katello as well as
possibly providing a design for future integration into the host model.
There have been a few upstream discussions focused on different aspects
of this but I wanted to present our (mostly) finalized design:
HostUnification - Katello - Foreman
There is an initial implementation of the design to show how puppet
related concerns would be abstracted out:
https://github.com/ShimShtein/foreman/tree/host-concerns
Feedback Welcome! We will be holding a design review very soon as well.
-Justin Sherrill
–
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...@googlegroups.com <javascript:>.
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...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> Is this Concern pattern a standard thing? I find it very
> confusing, as
> they don't appear to be ActiveSupport::Concern, which Foreman also
> uses.
>
> We are thinking about changing it to aspects, which is more consistent
> with the academic meaning.
I will update the wiki page to use 'aspect' instead of 'concern' to
avoid confusion with active support 'concerns'.
-Justin
···
On 05/11/2015 04:19 AM, Shim Shtein wrote:
> On Thursday, May 7, 2015 at 10:19:53 AM UTC+3, Stephen Benjamin wrote:
subscription-manager facts in the facts page is awesome!
As a concept we are thinking about multiple providers for facts.
- Stephen
-Shimon
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
