>
>
>
>
>>
>> As mentioned previously, a small team of developers from the Foreman and
>> Katello communities are working to assess the feasibility of Katello as an
>> engine as part of the Foreman platform. The team plans to stick to a
>> constrained minimally viable workflow for this effort. We'd like to open up
>> the proposed minimal workflow, open questions and notes from the initial
>> discussions to the broader community for discussion and awareness. Please
>> comment inline questions, and concerns anyone may have (or corrections).
>> Keep in mind, the goal of this is to move quickly but use the communities
>> to help ensure we don't overlook or miss potentially big issues.
>>
>>
>> Minimally Viable Workflow
>>
>> Non-functional Requirements:
>>
>> - The engine should include RestFul API accesss.
>>
>>
>> - The engine should include a UI interaction for each entitiy.
>>
>>
>> - Keep the project in a constant functional state.
>>
>>
>> Workflow:
>>
>>
>> - Create a custom Product and Repository
>>
>>
>> - Product: Fedora 19
>>
>>
>> - Repository: Fedora 19 x86_64
>>
>>
>> - Sync Content
>>
>>
>> - Create Environment Path
>>
>>
>> - Environments: Dev, Test, and Prod
>>
>>
>> - Create Content View
>>
>>
>> - Create a Content View Definition
>>
>>
>> - Add Fedora 19 product and repository
>>
>>
>> - Publish the Content View
>>
>>
>> - Promote the Content View through Dev, Test and Prod
>>
>>
>> - Create a Host Group
>>
>>
>> - Provision a Machine
>>
>>
>> - Consume Content from System
>>
>>
>> Q: Do we need to show the provisioned machine accessing the content
>> from the content view?
>> A: Potentially - through either an updated .repo file or
>> subscription-manager
>>
>> Q: Do we need to include the provisioned machine registering back?
>> A: Puppet will register the system back to Foreman.
>>
>> Q: Do we need to include Candlepin orchestration since we are using
>> only custom providers/products/repositories?
>> A: Idea is that we could start with using kickstart and puppet for Custom
>> products and not support subscription-manager out the gate for the
>> simplified workflow.
>>
>>
>> Given that a large percentage of the complexity in katello is in the
>> overlap between candlepin/rhsm and pulp, will there be any thought given to
>> what would be needed to support candlepin/rhsm in the future (Unless the
>> requirement for rhsm support has been dropped in any way )?
>>
>> I fear that if no thought is given up front, it may either make it
>> extremely difficult to integrated RHSM support, or would make it such that
>> custom content cannot be consumed in the same way as red hat content by
>> rhsm.
>>
>
> Thats a great feedback… and:
> 1. I do see a benefit for handing content only without subscriptions (e.g.
> there should not be a hard dependency on CP for repo sync, etc).
>
> Completely agree! Katello provided this more recently to some degree via
> http published repos (it just never provided a way to bind to them, and
> wasn't fully flushed out yet).
>
> 2. I don't have a clear understanding of what that statement means, can
> you provide some more usage cases where you think this path is wrong? we
> are looking for all the feedback we can get as early as possible.
>
>
> Within the subscription manager (rhsm) world (love it or hate it), several
> things occur:
>
> 1. If using rhsm, all repo definitions are configured within
> /etc/yum.red/redhat.repo on the client.
>
good… can't see an issue here.
>
> 2. If using rhsm, sets of repos within a product must exist within the
> same directory level, generally something like
> /$CandlepinOrg/$CandlepinEnv/path/to/repo (sometimes with arch and release
> substitutions for red hat content). This is controlled by some sort of
> prefix level, so maybe that can be mitigated.
>
is there any reason we are not prefixing it with the CV name? is that a
hard requirement from CP to have $CP_ORG/$CP_ENV ?
>
> 3. In katello two different orgs could import their own manifest with
> that contained the same product (such as RHEL), This gave each org their
> own 'copy' of rhel they could manage, but each 'copy' has the same content
> path for that products repos defined. (such as for example
> /rhel/6/x86_64/os/). Hence the reason for the prefix above. If a product
> can exist across multiple orgs/envs, you can't rely on an org or
> environment for a unique path to the content.
>
Assuming Client A gets a repo that goes to:
/org1/prod/rhel/6/x86_64/updates
when I update prod, that system will see new content
however, I can keep Client B from getting those updates (e.g. as I dont
have downtime for it), do i simply disable yum? this is less realistic when
talking about puppet content.
another approch would be yum repo url would be
/org/CV/rhel/6/… or even just /CV/rhel/6…
and then every time the client changes context, his yum repo would be
updated?
>
> So largely, i guess a number of questions pop up:
>
> 1. Is it an end goal requirement that rhsm handle all things
> content/subscription for a RHEL system. It seems silly to have to use it
> for Red hat content, but have to use something else for other content. I
> think custom content might work assuming the prefix is blank, but I'm not
> entirely sure.
>
I don't know the 'official' answer, but I would say no, it should be one
way to get your repos, I could see
-
kickstart configuration
-
puppet configuration
-
another yum plugin?
-
Should I be able to create and sync two different instances of a
> manifest-created repo (in two different orgs for instance)?
>
Why not? you don't have to… but why make that separation?
>
> In short candlepin integration is quite complex and can add constraints to
> the system. It added quite a lot of constraints to katello, but many of
> them may have just been the way it was implemented originally and not
> inherent to the application. I think its just worth figuring out how it'll
> work with foreman's content and having some sort of plan (and possibly a
> manually set up validation of said plan) to make sure we don't dig
> ourselves into a hole that either prohibits the use of rhsm, or puts
> foreman in a state where certain content is treated differently than other
> content.
>
What happens when we add debian support to pulp? would you still expect to
have CP handling the content?
I'm not against CP integration at all, but I'm in favour of getting pulp
support and to integrate with as many implementation backs as possible
(puppet, rhsm etc).
>
>
>
> 3. does it make sense to add subscription management for custom
> content? iif it is, is it hard requirement, nice to have etc ?
>
>
>
>>
>>
>>
>> Q: Do we need to support GPG keys?
>> A: Completely optional so leave it as is for now.
>>
>> Q: Do we need to handle Providers?
>> A: Move to remove from the MVP for now.
>>
>> Notes
>>
>>
>> - We could remove Provider from the workflow since the provider
>> concept really only serves as a way to identify and lock down Red Hat
>> specific content and we are targeting custom content to start.
>>
>>
>> - We could use a kickstart or Puppet configuration to handle to
>> enabling the content
>>
>>
>> - Need to reconcile Foreman puppet environments and the Katello
>> environment/promotion path
>>
>>
>> - Repository and product versioning without content views as a
>> simpler starter path
>>
>> What does this mean exactly? Inventing a new versioning
>> system/concept for repositories? Content views aren't actually that
>> complex of an entity, and it sounds like an new entity is being proposed
>> rather than trying to simplify a starting. Although it might depend on
>> exactly what is meant by 'repository and product versioning'.
>>
>
> The challenge we are trying to solve is how to map existing foreman
> objects to katello objects, the way I currently look at it, it seems like
> environments in foreman are actually CV (assuming we go with a single
> puppet repo per CV), the environment is what the puppet gets.
>
> We are currently targeting to get an end to end scenario with a 'simple'
> workflow, once we got this, we would work on adding multiple repo
> versioning etc… so we are not avoiding CV as an object, rather probably
> will work on it next week 
>
> I understand that, however i'm not seeing the 'building blocks' of the
> same feature that katello has, I'm seeing a new/different feature
> completely being formed. (Which is fine if thats our goal, we just need to
> make sure it satisfies all the use cases that content views satisfy.)
>
we are hopefully doing short cycles, so we can amend, our first cycle was
aiming repo sync <-> os <-> hostgroup <-> manage a system/host… we need
to add more logic now.
>
> * Content views don't have 'versioned' products or repositories. They are
> in themselves a version of multiple product or repositories. Content View
> A version 1 has a set of repos that are a snapshot in time.
>
right… we are only starting to look at CV this week.
> * the flow of content views are this:
> * User defines some set of content (and optional filters) called a
> "content view definition" and publishes it creating a content view (version
> 1)
> * User pushes that content view into an environment.
> * Systems subscribe and receive content from the content view in that
> environment
> * User modified content view definition and re-publishes it with new
> content and/or refined filters (creating version 2 of the content view)
> * User moves version 2 into the environment replacing version 1
> * System assigned to the Content view in that particular environment
> automatically gets version 2
>
I'm in mixed feelings about that, see above.
>
> Can you explain a little bit more about why a content view (and not a
> content view version, or a content_view/environment combination) matches up
> to a foreman environment and what exactly the workflow would be for
> 'versioned' repositories and products?
>
give us a few days to come with the right answers, we were not as focused
on that for this week…
Thanks for the feedback, very useful!
Ohad
···
On Thu, Jul 25, 2013 at 6:16 PM, Justin Sherrill wrote:
> On 07/25/2013 02:23 AM, Ohad Levy wrote:
> On Thu, Jul 25, 2013 at 12:03 AM, Justin Sherrill wrote:
>> On 07/24/2013 03:05 PM, Eric D Helms wrote:
Thanks!
-Justin
Ohad
-Justin
- Two proposed plans of attack:
- Choice 1 (current approach): re-write Katello as a full
mountable engine that re-uses foreman as a base
- Choice 2: re-use Katello as-is and mount it as an engine inside
Foreman. Migrate it over time to start re-using unified architectural
services (rbac, jobs processing, configuration, unified UI tooling)
The current proposal by the team is to target having a consistently
functional engine that iteratively opens up complexity on top of the
workflow each week. The first weeks goals:
Week of 7/24 Goal
- Create a Product, and Repository
- Associate a repository, host, host group, environment,
operatingsystem and architectures
- Sync a repository
- Boot a host using a repository
Thanks,
Eric
–
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/groups/opt_out.
–
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/groups/opt_out.
–
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/groups/opt_out.
–
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/groups/opt_out.
