[Foreman provisioning] Provisioning re-design proposal

Shimon_Shtein · February 24, 2015, 1:01pm

Here is a proposal for refactoring our provisioning orchestration system.
Please comment, I want to be sure I am not missing something big here.

Provisioning as an aspect

Current state:

The Host object contains a lot of information about the provisioning
procedure.
This information, once used when the host is provisioned is not used by
other subsystems
in Foreman.
The provisioning is performed by different disjoint components
(orchestration classes)
that are using a priority mechanism to define the correct order in which
each component
should run. As a cosequence, there is no way to know in what state the
provisioning is.
The same provisioning system uses a non-persistent ActiveRecord hooks
to tap into the work.

The proposal:

Create a separate object that will hold the information for the
provisioning.
Move the connection of a target to an aspect (concern). It will make
possible to provision objects other than hosts, like NICs.
Each provision strategy will get its own class, each instance of this
class will be the provisioning data of a single host.

Data models:
We are introducing two new objects to the system:

The provisioning relation object: This object is pretty simple - it's
only responsibility is to connect the target to its provisioning.
Target model class name
Target ID
Provision strategy class name
Provision model ID
Provision state: New - in process - success - failure
State change timestamp
Provision instance state: The state saved by the selected strategy to
maintain the provisioning process. Each provision strategy will be able to
save its own relevant state.
Examples for the provision strategies and their properties:
I will present a flat hierarchy, but it's doesn't (and won't) be the case -
strategies should inherit/use aspect concepts where it's appropriate.

PXE provision
Provision interface: which interface should be used for provisioning
PXELinux template
Provision template
Finish template
Installation medium
iPXE provision
Provision interface: which interface should be used for provisioning
iPXELinux template
Provision template
Finish template
Installation medium

image-based provision
Provision interface
Image
Finish template

Advantages:
From user perspective:

No need to think about provisioning properties, if the host is not
provisioned
No need to think about properties that are not relevant for the
selected provision strategy
Better way to monitor the provision process (as long as the strategy
is written the right way)
It would be possible to create a UI specific to each provisioning
system.

From developer perspective:

Cleaning up the Host object
Removing cross-concern dependency
Creating pluggable architecture for orchestrations - it will be
possible add another orchestrations via plugins
Creating a single object responsible for the orchestration process -
no need to guess the dependencies
Moving the responsibilities of creating/modifying actual objects
(such as DNS records) to the models that describe them.
The ability to derive each property using a different strategy - some
properties will be derived from the host/hostgroup hierarchy,
others (such as installation media) could be derived from the
organizations/locations hierarchy.

Backwards compatibility:
Since there are properties that are moved out of the host, it can break
extensions that were relying
on them. To handle it, a new concern will be created, that will delegate
all the relevant properties
to the orchestration subsystem with a deprecation warning.
The hooks plugin will be changed a bit to enable the old behavior

ohadlevy · February 24, 2015, 7:18pm

> Here is a proposal for refactoring our provisioning orchestration system.
> Please comment, I want to be sure I am not missing something big here.
>
> Provisioning as an aspect
>
> Current state:
>
> 1. The Host object contains a lot of information about the
> provisioning procedure.
> This information, once used when the host is provisioned is not used
> by other subsystems
> in Foreman.
>
> I'm not sure what exactly you mean by that, but the host object supports
different modes where provisioning can be enable/disabled, for example
managed = true, or unattend=false, which is currently all done in the same
class.

>
> 1. The provisioning is performed by different disjoint components
> (orchestration classes)
> that are using a priority mechanism to define the correct order in
> which each component
> should run. As a cosequence, there is no way to know in what state the
> provisioning is.
>
> thats not true, the orchestration state is shared, the provisioning state
is partly tracked and in an inconsistent way (e.g. image build vs pxe
build).

>
> 1. The same provisioning system uses a non-persistent ActiveRecord
> hooks to tap into the work.
>
>
> The proposal:
>
> 1. Create a separate object that will hold the information for the
> provisioning.
> 2. Move the connection of a target to an aspect (concern). It will
> make possible to provision objects other than hosts, like NICs.
>
> thats actually possible today (as they are concerns that are shared across
host/nics)

>
> 1.
> 2. Each provision strategy will get its own class, each instance of
> this class will be the provisioning data of a single host.
>
>
> Data models:
> We are introducing two new objects to the system:
> 1. The provisioning relation object: This object is pretty simple - it's
> only responsibility is to connect the target to its provisioning.
> Target model class name
> Target ID
> Provision strategy class name
> Provision model ID
> Provision state: New - in process - success - failure
> State change timestamp
>
> 2. Provision instance state: The state saved by the selected strategy to
> maintain the provisioning process. Each provision strategy will be able to
> save its own relevant state.
> Examples for the provision strategies and their properties:
> I will present a flat hierarchy, but it's doesn't (and won't) be the case
> - strategies should inherit/use aspect concepts where it's appropriate.
>
> PXE provision
> Provision interface: which interface should be used for provisioning
> PXELinux template
> Provision template
> Finish template
>
cant this be hidden behind an OS ? (or os profile - arch/os/ptable)

> Installation medium
> iPXE provision
> Provision interface: which interface should be used for provisioning
> iPXELinux template
> Provision template
> Finish template
>
ditto as above

> Installation medium
>
> image-based provision
> Provision interface
> Image
> Finish template
>
> Advantages:
> From user perspective:
>
> 1. No need to think about provisioning properties, if the host is not
> provisioned
> 2. No need to think about properties that are not relevant for the
> selected provision strategy
> 3. Better way to monitor the provision process (as long as the
> strategy is written the right way)
> 4. It would be possible to create a UI specific to each provisioning
> system.
>
>
> what about hooks/states ? can you describe which states will we introduce
and which kind of new events people can hook into?

> From developer perspective:
>
> 1. Cleaning up the Host object
> 2. Removing cross-concern dependency
> 3. Creating pluggable architecture for orchestrations - it will be
> possible add another orchestrations via plugins
> 4. Creating a single object responsible for the orchestration process
> - no need to guess the dependencies
> 5. Moving the responsibilities of creating/modifying actual objects
> (such as DNS records) to the models that describe them.
> 6. The ability to derive each property using a different strategy -
> some properties will be derived from the host/hostgroup hierarchy,
> others (such as installation media) could be derived from the
> organizations/locations hierarchy.
>
>
> Backwards compatibility:
> Since there are properties that are moved out of the host, it can break
> extensions that were relying
> on them. To handle it, a new concern will be created, that will delegate
> all the relevant properties
> to the orchestration subsystem with a deprecation warning.
> The hooks plugin will be changed a bit to enable the old behavior
>
> would this break the api (v1/v2) ?

thanks,
Ohad

···

On Tue, Feb 24, 2015 at 3:01 PM, Shim Shtein wrote:

–
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.

iNecas · February 25, 2015, 2:18pm

DISCLAIMER: I'm as unbiased as a Dynflow developer can be

First of all thanks for bringing this topic up. I'm really glad
the about the focus on refactoring the orchestration, and I fully
agree with problems you've stated in the "Current state part".

To the proposal itself, to be honest, many of the features you've described
here are already part of the Dynflow or foreman-tasks and Dynflow itself was designed
in a way to support the Foreman's host orchestration, such as:

tracking the state of the process (including the progress)
storing the data about the provisioning in the action inputs
pluggable architecture through the subsciptions
connection between ActiveRecord resources and the task by the use of the locks
top-down approach for the orchestration

Additionally, there are other features that come with Dynflow for free:

rescue strategies (pause/resume and skip are implemented now, more of the to come)
ability to make more complex orchestrations as composition of simpler ones
support for running independent steps concurrently
not limited just to provisioning
already integration in the CLI
heavily used Katello, Staypuf, some appearance also in docker, chef and others
testing helpers
extendability via middlewares

I know moving to the Dynflow is the next step. However, since there is some overlap
already in this proposal, I would like to suggest the following:

build the example host orchestration on Dynflow. The scenario would be:

a. create ip reservation
b. create dns record
c. create ftfp file
d. create libvirt VM
e. wait for the provisioning the finish
f. update the ftfp to local boot
review that, identifying the overlaps with the current proposal
identify the improvements required on Dynflow based on that review
identify things that fit outside of Dynflow/Foreman-tasks

It should be possible to do the step 1 in few days, so we could
do the review next week.

My main concern about the current proposal and the "without Dynflow first"
approach is the risk of the overlapping and doing some things twice. That
doesn't mean only duplicate effort, but also twice as many migrations etc.
On the other hand, if there are things that the orchestration needs from foreman-tasks/dynflow,
others will already benefit from the improvements.

One lesson learned from moving Katello on Dynflow was: we already had a branch
with most of the things Dynflowised, while new updates were still being made
in the old orchestration, which caused pains on both side: the dynflow branch
needed to be rebased often with conflicts, not mentioning the pain to do
changes in the old orchestration in the meantime. So this time, I would like
to take different approach and given we're moving to Dynflow anyway,
counting on that from the beginning.

Even if it doesn't show up as viable alternative to start with, it might
bring more light on the goal where (I hope) we would like to get.

On the foreman-tasks and Dynflow being "Ivan's projects", we can fix that
with more people starting working on that: if there are gaps to fill
(there are already some known ones) to support the host orchestration case,
I would be more than happy to work with others on implementing them.

– Ivan

···

----- Original Message ----- > Here is a proposal for refactoring our provisioning orchestration system. > Please comment, I want to be sure I am not missing something big here. > > Provisioning as an aspect > > *Current state:* > > 1. The Host object contains a lot of information about the provisioning > procedure. > This information, once used when the host is provisioned is not used by > other subsystems > in Foreman. > 2. The provisioning is performed by different disjoint components > (orchestration classes) > that are using a priority mechanism to define the correct order in which > each component > should run. As a cosequence, there is no way to know in what state the > provisioning is. > 3. The same provisioning system uses a non-persistent ActiveRecord hooks > to tap into the work. > > > *The proposal*: > > 1. Create a separate object that will hold the information for the > provisioning. > 2. Move the connection of a target to an aspect (concern). It will make > possible to provision objects other than hosts, like NICs. > 3. Each provision strategy will get its own class, each instance of this > class will be the provisioning data of a single host. > > > *Data models*: > We are introducing two new objects to the system: > 1. The provisioning relation object: This object is pretty simple - it's > only responsibility is to connect the target to its provisioning. > Target model class name > Target ID > Provision strategy class name > Provision model ID > Provision state: New - in process - success - failure > State change timestamp > > 2. Provision instance state: The state saved by the selected strategy to > maintain the provisioning process. Each provision strategy will be able to > save its own relevant state. > Examples for the provision strategies and their properties: > I will present a flat hierarchy, but it's doesn't (and won't) be the case - > strategies should inherit/use aspect concepts where it's appropriate. > > PXE provision > Provision interface: which interface should be used for provisioning > PXELinux template > Provision template > Finish template > Installation medium > iPXE provision > Provision interface: which interface should be used for provisioning > iPXELinux template > Provision template > Finish template > Installation medium > > image-based provision > Provision interface > Image > Finish template > > *Advantages*: > From user perspective: > > 1. No need to think about provisioning properties, if the host is not > provisioned > 2. No need to think about properties that are not relevant for the > selected provision strategy > 3. Better way to monitor the provision process (as long as the strategy > is written the right way) > 4. It would be possible to create a UI specific to each provisioning > system. > > > From developer perspective: > > 1. Cleaning up the Host object > 2. Removing cross-concern dependency > 3. Creating pluggable architecture for orchestrations - it will be > possible add another orchestrations via plugins > 4. Creating a single object responsible for the orchestration process - > no need to guess the dependencies > 5. Moving the responsibilities of creating/modifying actual objects > (such as DNS records) to the models that describe them. > 6. The ability to derive each property using a different strategy - some > properties will be derived from the host/hostgroup hierarchy, > others (such as installation media) could be derived from the > organizations/locations hierarchy. > > > *Backwards compatibility:* > Since there are properties that are moved out of the host, it can break > extensions that were relying > on them. To handle it, a new concern will be created, that will delegate > all the relevant properties > to the orchestration subsystem with a deprecation warning. > The hooks plugin will be changed a bit to enable the old behavior > > -- > 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. >

lzap · February 25, 2015, 8:19am

Sidenote: Ivan's effort called foreman-tasks allows similar thing, but
it's even more generic and provides more options like suspending failed
actions where appropriate (e.g. if DNS reservation is not required for
provisioning to finish then it can be configured not to trigger rollback
so administrators can fix it later on).

LZ

···

On Tue, Feb 24, 2015 at 05:01:33AM -0800, Shim Shtein wrote: > Here is a proposal for refactoring our provisioning orchestration system. > Please comment, I want to be sure I am not missing something big here. > > Provisioning as an aspect > > *Current state:* > > 1. The Host object contains a lot of information about the provisioning > procedure. > This information, once used when the host is provisioned is not used by > other subsystems > in Foreman. > 2. The provisioning is performed by different disjoint components > (orchestration classes) > that are using a priority mechanism to define the correct order in which > each component > should run. As a cosequence, there is no way to know in what state the > provisioning is. > 3. The same provisioning system uses a non-persistent ActiveRecord hooks > to tap into the work. > > > *The proposal*: > > 1. Create a separate object that will hold the information for the > provisioning. > 2. Move the connection of a target to an aspect (concern). It will make > possible to provision objects other than hosts, like NICs. > 3. Each provision strategy will get its own class, each instance of this > class will be the provisioning data of a single host. > > > *Data models*: > We are introducing two new objects to the system: > 1. The provisioning relation object: This object is pretty simple - it's > only responsibility is to connect the target to its provisioning. > Target model class name > Target ID > Provision strategy class name > Provision model ID > Provision state: New - in process - success - failure > State change timestamp > > 2. Provision instance state: The state saved by the selected strategy to > maintain the provisioning process. Each provision strategy will be able to > save its own relevant state. > Examples for the provision strategies and their properties: > I will present a flat hierarchy, but it's doesn't (and won't) be the case - > strategies should inherit/use aspect concepts where it's appropriate. > > PXE provision > Provision interface: which interface should be used for provisioning > PXELinux template > Provision template > Finish template > Installation medium > iPXE provision > Provision interface: which interface should be used for provisioning > iPXELinux template > Provision template > Finish template > Installation medium > > image-based provision > Provision interface > Image > Finish template > > *Advantages*: > From user perspective: > > 1. No need to think about provisioning properties, if the host is not > provisioned > 2. No need to think about properties that are not relevant for the > selected provision strategy > 3. Better way to monitor the provision process (as long as the strategy > is written the right way) > 4. It would be possible to create a UI specific to each provisioning > system. > > > From developer perspective: > > 1. Cleaning up the Host object > 2. Removing cross-concern dependency > 3. Creating pluggable architecture for orchestrations - it will be > possible add another orchestrations via plugins > 4. Creating a single object responsible for the orchestration process - > no need to guess the dependencies > 5. Moving the responsibilities of creating/modifying actual objects > (such as DNS records) to the models that describe them. > 6. The ability to derive each property using a different strategy - some > properties will be derived from the host/hostgroup hierarchy, > others (such as installation media) could be derived from the > organizations/locations hierarchy. > > > *Backwards compatibility:* > Since there are properties that are moved out of the host, it can break > extensions that were relying > on them. To handle it, a new concern will be created, that will delegate > all the relevant properties > to the orchestration subsystem with a deprecation warning. > The hooks plugin will be changed a bit to enable the old behavior > > -- > 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.

–
Later,
Lukas #lzap Zapletal

Marek_Hulan · March 15, 2015, 4:37pm

Hello

We had a further discussion today about removing provision related objects
from host and hostgroup. I'll try to summarize outcomes and kindly ask for
inputs from others. All comments are welcome. I attached a quick diagram
illustrating the changes.

Some entity names were changed so here's the mapping of previous names to
names used in the diagram:
Provisioning relation object -> Provisioning
Provisioning strategy -> Provisioning method
Provision instance state -> Provisioning snap

We'd basically split Hostgroup into two parts. Everything related to
configuration would remain part of a Hostgroup (puppet classes, config groups,
Environment) while the rest which is related to provision would be extracted
to a new entity called ProvisionGroup (work name, suggestions appreciated).
When user build a new host he'd be able select one Hostgroup and one
ProvisionGroup. We'd also introduce a ProvisioningSnap which is a copy of all
required foreign keys of provisioning data, based on selected
ProvisioningMethod. ProvisioningMethod may be something like PXE, Image etc.
When we have a ProvisioningSnap and user selected a ProvisioningMethod, we can
start Provisioning - this represents the actual act.

The biggest difference between Hostgroup and ProvisionGroup (for me) is that
any change in Hostgroup associations are applied immediately (e.g. you assign
new puppet class, it's part of ENC output) while changes in ProvisionGroup do
affect only new provisionings. The pointers to the data are kept in
ProvisioningSnap so you can reprovision host in a same way it has been
provisioned before. If user changes the linked object, e.g. installation
medium URL, we can display a warning that there is a ProvisioningSnap that
refers to it, so the action would invalidate the snap. So users might add new
object rather than editing existing one.

One small inconsistency in previous statement is that changes of puppet
parameter overrides assigned to OS would still apply immediately, even though
the OS was originally assigned through ProvisionGroup. I think we should keep
the OS association on Host object but keep the meaning of this relationship
only relevant for configuration, not provisioning. I think this relationship
is still useful on Foreman installations that are not used for provisioning.
The other way would be, that we should only look at facts, but it does not
look right to me.

One thing we didn't agree on is whether the ProvisioningSnap should contain
all available data, or just those required for particular ProvisioningMethod.
Opinions are again very welcome. Provisioning snap could sometimes contain
installation media (PXE based provisioning method) sometimes not (Image
based). Or we could always store all data such as installation medium, even if
they are not required for currently selected provisioning method.

Thanks for your input.

···

-- Marek

On Tuesday 24 of February 2015 05:01:33 Shim Shtein wrote:

Here is a proposal for refactoring our provisioning orchestration system.
Please comment, I want to be sure I am not missing something big here.

Provisioning as an aspect

Current state:

The Host object contains a lot of information about the provisioning
procedure.
This information, once used when the host is provisioned is not used by
other subsystems
in Foreman.

The provisioning is performed by different disjoint components
(orchestration classes)
that are using a priority mechanism to define the correct order in which
each component
should run. As a cosequence, there is no way to know in what state the
provisioning is.

The same provisioning system uses a non-persistent ActiveRecord hooks
to tap into the work.

The proposal:

Create a separate object that will hold the information for the
provisioning.

Move the connection of a target to an aspect (concern). It will make
possible to provision objects other than hosts, like NICs.

Each provision strategy will get its own class, each instance of this
class will be the provisioning data of a single host.

Data models:
We are introducing two new objects to the system:

The provisioning relation object: This object is pretty simple - it’s
only responsibility is to connect the target to its provisioning.
Target model class name
Target ID
Provision strategy class name
Provision model ID
Provision state: New - in process - success - failure
State change timestamp

Provision instance state: The state saved by the selected strategy to
maintain the provisioning process. Each provision strategy will be able to
save its own relevant state.
Examples for the provision strategies and their properties:
I will present a flat hierarchy, but it’s doesn’t (and won’t) be the case -
strategies should inherit/use aspect concepts where it’s appropriate.

PXE provision
Provision interface: which interface should be used for provisioning
PXELinux template
Provision template
Finish template
Installation medium
iPXE provision
Provision interface: which interface should be used for provisioning
iPXELinux template
Provision template
Finish template
Installation medium

image-based provision
Provision interface
Image
Finish template

Advantages:
From user perspective:

No need to think about provisioning properties, if the host is not
provisioned

No need to think about properties that are not relevant for the
selected provision strategy

Better way to monitor the provision process (as long as the strategy
is written the right way)

It would be possible to create a UI specific to each provisioning
system.

From developer perspective:

Cleaning up the Host object

Removing cross-concern dependency

Creating pluggable architecture for orchestrations - it will be
possible add another orchestrations via plugins

Creating a single object responsible for the orchestration process -
no need to guess the dependencies

Moving the responsibilities of creating/modifying actual objects
(such as DNS records) to the models that describe them.

The ability to derive each property using a different strategy - some
properties will be derived from the host/hostgroup hierarchy,
others (such as installation media) could be derived from the
organizations/locations hierarchy.

Backwards compatibility:
Since there are properties that are moved out of the host, it can break
extensions that were relying
on them. To handle it, a new concern will be created, that will delegate
all the relevant properties
to the orchestration subsystem with a deprecation warning.
The hooks plugin will be changed a bit to enable the old behavior

–
Marek

Shimon_Shtein · February 25, 2015, 8:48am

>
>
>
>
>> Here is a proposal for refactoring our provisioning orchestration system.
>> Please comment, I want to be sure I am not missing something big here.
>>
>> Provisioning as an aspect
>>
>> Current state:
>>
>> 1. The Host object contains a lot of information about the
>> provisioning procedure.
>> This information, once used when the host is provisioned is not used
>> by other subsystems
>> in Foreman.
>>
>> I'm not sure what exactly you mean by that, but the host object supports
> different modes where provisioning can be enable/disabled, for example
> managed = true, or unattend=false, which is currently all done in the same
> class.
>
I was relating to the actual properties that are relevant only for
provisioning such as image location, partition table layout, installation
media. As you've mentioned, they all are in the host class.

>
>> 1. The provisioning is performed by different disjoint components
>> (orchestration classes)
>> that are using a priority mechanism to define the correct order in
>> which each component
>> should run. As a cosequence, there is no way to know in what state
>> the provisioning is.
>>
>> thats not true, the orchestration state is shared, the provisioning state
> is partly tracked and in an inconsistent way (e.g. image build vs pxe
> build).
>
Bad words chosen on my side: Maybe " As a cosequence, there is no way to
know in what state the provisioning is." should be changed to: "As a
cosequence, there is no way to know in which stage the provisioning is."?
Does it make more sense this way? Of course the actual state of the system
is shared, you can always query the relevant object. I was talking about a
decentralized nature of the current process, which
implies difficulty in understanding of the provisioning process as a single
unit. Good example for this difficulty is determining which components will
run for the current host. To determine this, you will
have to read the code of each component and decide whether it will kick in
or not.
Of course you can audit each step that was taken and analyze it after the
run, but it will be difficult to describe it a-priori.

>
>> 1. The same provisioning system uses a non-persistent ActiveRecord
>> hooks to tap into the work.
>>
>>
>> The proposal:
>>
>> 1. Create a separate object that will hold the information for the
>> provisioning.
>> 2. Move the connection of a target to an aspect (concern). It will
>> make possible to provision objects other than hosts, like NICs.
>>
>> thats actually possible today (as they are concerns that are shared
> across host/nics)
>
It's true, but all the objects share the same orchestration components, so
basically they all try to share a single strategy. It requires extra
conditional code in each of
the components, especially when introducing provisioning for a new resource
[sorry for the overloaded term, can't find better one to describe anything
that can be provisioned].
My proposal allows to create different strategies for different objects, so
each strategy will concentrate on a single object, which will simplify the
orchestration code and
allow more flexibility in designing new strategies. I don't think you
should use the same process to provision a router, a NIC and a virtual
guest.

>
>> 1.
>> 2. Each provision strategy will get its own class, each instance of
>> this class will be the provisioning data of a single host.
>>
>>
>> Data models:
>> We are introducing two new objects to the system:
>> 1. The provisioning relation object: This object is pretty simple - it's
>> only responsibility is to connect the target to its provisioning.
>> Target model class name
>> Target ID
>> Provision strategy class name
>> Provision model ID
>> Provision state: New - in process - success - failure
>> State change timestamp
>>
>> 2. Provision instance state: The state saved by the selected strategy to
>> maintain the provisioning process. Each provision strategy will be able to
>> save its own relevant state.
>> Examples for the provision strategies and their properties:
>> I will present a flat hierarchy, but it's doesn't (and won't) be the case
>> - strategies should inherit/use aspect concepts where it's appropriate.
>>
>> PXE provision
>> Provision interface: which interface should be used for provisioning
>> PXELinux template
>> Provision template
>> Finish template
>>
> cant this be hidden behind an OS ? (or os profile - arch/os/ptable)
>
Probably I don't understand the question. Each template is relevant to a
variety of objects: Most important is the strategy, but as it is today, it
can be associated with an OS, OS family, environment and maybe
location/organization.
Each provision should determine each of these parameters. In my proposal,
each provision can define its own rules for deriving the right value for
each one of the parameters, including other parameters as OS mirror and so
on.
When the user chooses to provision a resource, the strategy kicks in and
determines what are the exact values that the host will be provisioned
with. There is nothing that prevents the strategy even asking the user more
questions
in order to complete the whole list of it's required information.

> Installation medium
>>
> The same rules from above apply for all properties, including
installation medium.

> iPXE provision
>> Provision interface: which interface should be used for provisioning
>> iPXELinux template
>> Provision template
>> Finish template
>>
> ditto as above
>
>> Installation medium
>>
>> image-based provision
>> Provision interface
>> Image
>> Finish template
>>
>> Advantages:
>> From user perspective:
>>
>> 1. No need to think about provisioning properties, if the host is not
>> provisioned
>> 2. No need to think about properties that are not relevant for the
>> selected provision strategy
>> 3. Better way to monitor the provision process (as long as the
>> strategy is written the right way)
>> 4. It would be possible to create a UI specific to each provisioning
>> system.
>>
>>
>> what about hooks/states ? can you describe which states will we introduce
> and which kind of new events people can hook into?
>
Let's divide the issue into two:
There are the generic states of the provisioning process: Provision
requested, Executing, Failed, Succeeded.
It is pretty much the same as in the current state.
The second part is the states that are specific to a provision strategy:
those are determined/implemented by each strategy on its own.
For example PXE strategy can define a set of states like TFTP server is
waiting, System is booting from the generic image, Operating system
installed and so on.
Of course these states are not relevant for other types of provisioning
like image based provisioning.

>
>
>> From developer perspective:
>>
>> 1. Cleaning up the Host object
>> 2. Removing cross-concern dependency
>> 3. Creating pluggable architecture for orchestrations - it will be
>> possible add another orchestrations via plugins
>> 4. Creating a single object responsible for the orchestration process
>> - no need to guess the dependencies
>> 5. Moving the responsibilities of creating/modifying actual objects
>> (such as DNS records) to the models that describe them.
>> 6. The ability to derive each property using a different strategy -
>> some properties will be derived from the host/hostgroup hierarchy,
>> others (such as installation media) could be derived from the
>> organizations/locations hierarchy.
>>
>>
>> Backwards compatibility:
>> Since there are properties that are moved out of the host, it can break
>> extensions that were relying
>> on them. To handle it, a new concern will be created, that will delegate
>> all the relevant properties
>> to the orchestration subsystem with a deprecation warning.
>> The hooks plugin will be changed a bit to enable the old behavior
>>
>> would this break the api (v1/v2) ?
>
It's a good question. As far as I can see it shouldn't, but I would really
appreciate if somebody will point out where should be a problem.
The current provisioning is an automatic action based on the state of the
host - so it has no reflection in the API itself, which should be safe for
the API.
I had already mentioned the "compatibility aspect" that will enable us to
retain even the code that handles API requests with properties
that were moved out from the object.

···

On Tuesday, February 24, 2015 at 9:18:41 PM UTC+2, ohadlevy wrote: > On Tue, Feb 24, 2015 at 3:01 PM, Shim Shtein > wrote:

thanks,
Ohad

–
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.

Shimon_Shtein · February 25, 2015, 9:02am

Actually this is the preparation step that can later on leverage Ivan's
effort for the orchestration.
My intent was to break the orchestration change into multiple stages that
will be small enough to handle.
First stage will be the change in the models structure that is introduced
here. It actually introduces
a new first-rate citizen in foreman - the orchestration. Once the system
will be stable with this concept
of orchestration as a strategy/state machine, it will be easier to move to
the next stage.
The second stage is writing new strategies that could be based on any state
machine engine, specifically Ivan's one.

···

On Wednesday, February 25, 2015 at 10:19:07 AM UTC+2, Lukas Zapletal wrote: > > Sidenote: Ivan's effort called foreman-tasks allows similar thing, but > it's even more generic and provides more options like suspending failed > actions where appropriate (e.g. if DNS reservation is not required for > provisioning to finish then it can be configured not to trigger rollback > so administrators can fix it later on). > > LZ > > On Tue, Feb 24, 2015 at 05:01:33AM -0800, Shim Shtein wrote: > > Here is a proposal for refactoring our provisioning orchestration > system. > > Please comment, I want to be sure I am not missing something big here. > > > > Provisioning as an aspect > > > > *Current state:* > > > > 1. The Host object contains a lot of information about the > provisioning > > procedure. > > This information, once used when the host is provisioned is not used > by > > other subsystems > > in Foreman. > > 2. The provisioning is performed by different disjoint components > > (orchestration classes) > > that are using a priority mechanism to define the correct order in > which > > each component > > should run. As a cosequence, there is no way to know in what state > the > > provisioning is. > > 3. The same provisioning system uses a non-persistent ActiveRecord > hooks > > to tap into the work. > > > > > > *The proposal*: > > > > 1. Create a separate object that will hold the information for the > > provisioning. > > 2. Move the connection of a target to an aspect (concern). It will > make > > possible to provision objects other than hosts, like NICs. > > 3. Each provision strategy will get its own class, each instance of > this > > class will be the provisioning data of a single host. > > > > > > *Data models*: > > We are introducing two new objects to the system: > > 1. The provisioning relation object: This object is pretty simple - it's > > only responsibility is to connect the target to its provisioning. > > Target model class name > > Target ID > > Provision strategy class name > > Provision model ID > > Provision state: New - in process - success - failure > > State change timestamp > > > > 2. Provision instance state: The state saved by the selected strategy to > > maintain the provisioning process. Each provision strategy will be able > to > > save its own relevant state. > > Examples for the provision strategies and their properties: > > I will present a flat hierarchy, but it's doesn't (and won't) be the > case - > > strategies should inherit/use aspect concepts where it's appropriate. > > > > PXE provision > > Provision interface: which interface should be used for provisioning > > PXELinux template > > Provision template > > Finish template > > Installation medium > > iPXE provision > > Provision interface: which interface should be used for provisioning > > iPXELinux template > > Provision template > > Finish template > > Installation medium > > > > image-based provision > > Provision interface > > Image > > Finish template > > > > *Advantages*: > > From user perspective: > > > > 1. No need to think about provisioning properties, if the host is not > > provisioned > > 2. No need to think about properties that are not relevant for the > > selected provision strategy > > 3. Better way to monitor the provision process (as long as the > strategy > > is written the right way) > > 4. It would be possible to create a UI specific to each provisioning > > system. > > > > > > From developer perspective: > > > > 1. Cleaning up the Host object > > 2. Removing cross-concern dependency > > 3. Creating pluggable architecture for orchestrations - it will be > > possible add another orchestrations via plugins > > 4. Creating a single object responsible for the orchestration process > - > > no need to guess the dependencies > > 5. Moving the responsibilities of creating/modifying actual objects > > (such as DNS records) to the models that describe them. > > 6. The ability to derive each property using a different strategy - > some > > properties will be derived from the host/hostgroup hierarchy, > > others (such as installation media) could be derived from the > > organizations/locations hierarchy. > > > > > > *Backwards compatibility:* > > Since there are properties that are moved out of the host, it can break > > extensions that were relying > > on them. To handle it, a new concern will be created, that will delegate > > all the relevant properties > > to the orchestration subsystem with a deprecation warning. > > The hooks plugin will be changed a bit to enable the old behavior > > > > -- > > 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 . > > For more options, visit https://groups.google.com/d/optout. > > > -- > Later, > Lukas #lzap Zapletal >

ohadlevy · February 25, 2015, 3:08pm

> DISCLAIMER: I'm as unbiased as a Dynflow developer can be
>
> First of all thanks for bringing this topic up. I'm really glad
> the about the focus on refactoring the orchestration, and I fully
> agree with problems you've stated in the "Current state part".
>
> To the proposal itself, to be honest, many of the features you've described
> here are already part of the Dynflow or foreman-tasks and Dynflow itself
> was designed
> in a way to support the Foreman's host orchestration, such as:
>
> * tracking the state of the process (including the progress)
> * storing the data about the provisioning in the action inputs
> * pluggable architecture through the subsciptions
> * connection between ActiveRecord resources and the task by the use of the
> locks
> * top-down approach for the orchestration
>
> Additionally, there are other features that come with Dynflow for free:
>
> * rescue strategies (pause/resume and skip are implemented now, more of
> the to come)
> * ability to make more complex orchestrations as composition of simpler
> ones
> * support for running independent steps concurrently
> * not limited just to provisioning
> * already integration in the CLI
> * heavily used Katello, Staypuf, some appearance also in docker, chef and
> others
> * testing helpers
> * extendability via middlewares
>
> I know moving to the Dynflow is the next step. However, since there is
> some overlap
> already in this proposal, I would like to suggest the following:
>
> 1. build the example host orchestration on Dynflow. The scenario would be:
>
> a. create ip reservation
> b. create dns record
> c. create ftfp file
> d. create libvirt VM
> e. wait for the provisioning the finish
> f. update the ftfp to local boot
>
>

my overall Goal is not to use dynflow, rather then to provide more
functionality, robustness etc around provisioning, for example I want
answers to the following questions:

can i provision via this hostgroup?
is my infrastructure ready to provision?
can i react to provisioning failures automatically?
can i know exactly in which state my provisioning is on?

dynflow is most likely the right way forward to implement such features,
but its not just about the orchestration part.
we did start with a "hack" answering some of these questions via the
rebuilt host action, but this was done without changing the host object,
and only for the rebuilt action instead of the more general case.

my point is, that regardless of implementation (dynflow or otherwise) I
would like to reduce the scope of the host object, its overloaded and makes
any new feature challenging because of its scope.

I think shim started in the right approach to reduce the scope of the host
object, by moving all of the provisioning related properties out of the
host object, this to me sounds like it can happen prior to dynflow work?

Ohad

review that, identifying the overlaps with the current proposal

···

On Wed, Feb 25, 2015 at 4:18 PM, Ivan Necas wrote: > > 3. identify the improvements required on Dynflow based on that review > > 4. identify things that fit outside of Dynflow/Foreman-tasks > > It should be possible to do the step 1 in few days, so we could > do the review next week. > > My main concern about the current proposal and the "without Dynflow first" > approach is the risk of the overlapping and doing some things twice. That > doesn't mean only duplicate effort, but also twice as many migrations etc. > On the other hand, if there are things that the orchestration needs from > foreman-tasks/dynflow, > others will already benefit from the improvements. > > One lesson learned from moving Katello on Dynflow was: we already had a > branch > with most of the things Dynflowised, while new updates were still being > made > in the old orchestration, which caused pains on both side: the dynflow > branch > needed to be rebased often with conflicts, not mentioning the pain to do > changes in the old orchestration in the meantime. So this time, I would > like > to take different approach and given we're moving to Dynflow anyway, > counting on that from the beginning. > > Even if it doesn't show up as viable alternative to start with, it might > bring more light on the goal where (I hope) we would like to get. > > On the foreman-tasks and Dynflow being "Ivan's projects", we can fix that > with more people starting working on that: if there are gaps to fill > (there are already some known ones) to support the host orchestration case, > I would be more than happy to work with others on implementing them. > > -- Ivan > > ----- Original Message ----- > > Here is a proposal for refactoring our provisioning orchestration system. > > Please comment, I want to be sure I am not missing something big here. > > > > Provisioning as an aspect > > > > *Current state:* > > > > 1. The Host object contains a lot of information about the > provisioning > > procedure. > > This information, once used when the host is provisioned is not used > by > > other subsystems > > in Foreman. > > 2. The provisioning is performed by different disjoint components > > (orchestration classes) > > that are using a priority mechanism to define the correct order in > which > > each component > > should run. As a cosequence, there is no way to know in what state the > > provisioning is. > > 3. The same provisioning system uses a non-persistent ActiveRecord > hooks > > to tap into the work. > > > > > > *The proposal*: > > > > 1. Create a separate object that will hold the information for the > > provisioning. > > 2. Move the connection of a target to an aspect (concern). It will > make > > possible to provision objects other than hosts, like NICs. > > 3. Each provision strategy will get its own class, each instance of > this > > class will be the provisioning data of a single host. > > > > > > *Data models*: > > We are introducing two new objects to the system: > > 1. The provisioning relation object: This object is pretty simple - it's > > only responsibility is to connect the target to its provisioning. > > Target model class name > > Target ID > > Provision strategy class name > > Provision model ID > > Provision state: New - in process - success - failure > > State change timestamp > > > > 2. Provision instance state: The state saved by the selected strategy to > > maintain the provisioning process. Each provision strategy will be able > to > > save its own relevant state. > > Examples for the provision strategies and their properties: > > I will present a flat hierarchy, but it's doesn't (and won't) be the > case - > > strategies should inherit/use aspect concepts where it's appropriate. > > > > PXE provision > > Provision interface: which interface should be used for provisioning > > PXELinux template > > Provision template > > Finish template > > Installation medium > > iPXE provision > > Provision interface: which interface should be used for provisioning > > iPXELinux template > > Provision template > > Finish template > > Installation medium > > > > image-based provision > > Provision interface > > Image > > Finish template > > > > *Advantages*: > > From user perspective: > > > > 1. No need to think about provisioning properties, if the host is not > > provisioned > > 2. No need to think about properties that are not relevant for the > > selected provision strategy > > 3. Better way to monitor the provision process (as long as the > strategy > > is written the right way) > > 4. It would be possible to create a UI specific to each provisioning > > system. > > > > > > From developer perspective: > > > > 1. Cleaning up the Host object > > 2. Removing cross-concern dependency > > 3. Creating pluggable architecture for orchestrations - it will be > > possible add another orchestrations via plugins > > 4. Creating a single object responsible for the orchestration process > - > > no need to guess the dependencies > > 5. Moving the responsibilities of creating/modifying actual objects > > (such as DNS records) to the models that describe them. > > 6. The ability to derive each property using a different strategy - > some > > properties will be derived from the host/hostgroup hierarchy, > > others (such as installation media) could be derived from the > > organizations/locations hierarchy. > > > > > > *Backwards compatibility:* > > Since there are properties that are moved out of the host, it can break > > extensions that were relying > > on them. To handle it, a new concern will be created, that will delegate > > all the relevant properties > > to the orchestration subsystem with a deprecation warning. > > The hooks plugin will be changed a bit to enable the old behavior > > > > -- > > 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. > > > > -- > 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. >

Petr_Chalupa · March 2, 2015, 1:09pm

DISCLAIMER: Another unbiased Dynflow developer:

It seems to me that the amount of effort needed:

to make the middle-step, or
to go directly to be using Dynflow
is about the same. Hence I think is best to target Dyflow usage from the
beginning especially if it'll provide more features.

Reasoning:

Both cases need to extract provisioning from Host model
In one case there is a new object to hold it in second it would be
transformed to a collection of Dynflow Actions
Dynflow Actions may take more time to write but on the other hand
there will be no need to write any code handling the orchestration
itself (which would be duplication mostly I guess).

Petr

···

On 25.02.15 15:18, Ivan Necas wrote: > DISCLAIMER: I'm as unbiased as a Dynflow developer can be :) > > First of all thanks for bringing this topic up. I'm really glad > the about the focus on refactoring the orchestration, and I fully > agree with problems you've stated in the "Current state part". > > To the proposal itself, to be honest, many of the features you've described > here are already part of the Dynflow or foreman-tasks and Dynflow itself was designed > in a way to support the Foreman's host orchestration, such as: > > * tracking the state of the process (including the progress) > * storing the data about the provisioning in the action inputs > * pluggable architecture through the subsciptions > * connection between ActiveRecord resources and the task by the use of the locks > * top-down approach for the orchestration > > Additionally, there are other features that come with Dynflow for free: > > * rescue strategies (pause/resume and skip are implemented now, more of the to come) > * ability to make more complex orchestrations as composition of simpler ones > * support for running independent steps concurrently > * not limited just to provisioning > * already integration in the CLI > * heavily used Katello, Staypuf, some appearance also in docker, chef and others > * testing helpers > * extendability via middlewares > > I know moving to the Dynflow is the next step. However, since there is some overlap > already in this proposal, I would like to suggest the following: > > 1. build the example host orchestration on Dynflow. The scenario would be: > > a. create ip reservation > b. create dns record > c. create ftfp file > d. create libvirt VM > e. wait for the provisioning the finish > f. update the ftfp to local boot > > 2. review that, identifying the overlaps with the current proposal > > 3. identify the improvements required on Dynflow based on that review > > 4. identify things that fit outside of Dynflow/Foreman-tasks > > It should be possible to do the step 1 in few days, so we could > do the review next week. > > My main concern about the current proposal and the "without Dynflow first" > approach is the risk of the overlapping and doing some things twice. That > doesn't mean only duplicate effort, but also twice as many migrations etc. > On the other hand, if there are things that the orchestration needs from foreman-tasks/dynflow, > others will already benefit from the improvements. > > One lesson learned from moving Katello on Dynflow was: we already had a branch > with most of the things Dynflowised, while new updates were still being made > in the old orchestration, which caused pains on both side: the dynflow branch > needed to be rebased often with conflicts, not mentioning the pain to do > changes in the old orchestration in the meantime. So this time, I would like > to take different approach and given we're moving to Dynflow anyway, > counting on that from the beginning. > > Even if it doesn't show up as viable alternative to start with, it might > bring more light on the goal where (I hope) we would like to get. > > On the foreman-tasks and Dynflow being "Ivan's projects", we can fix that > with more people starting working on that: if there are gaps to fill > (there are already some known ones) to support the host orchestration case, > I would be more than happy to work with others on implementing them. > > -- Ivan > > ----- Original Message ----- >> Here is a proposal for refactoring our provisioning orchestration system. >> Please comment, I want to be sure I am not missing something big here. >> >> Provisioning as an aspect >> >> *Current state:* >> >> 1. The Host object contains a lot of information about the provisioning >> procedure. >> This information, once used when the host is provisioned is not used by >> other subsystems >> in Foreman. >> 2. The provisioning is performed by different disjoint components >> (orchestration classes) >> that are using a priority mechanism to define the correct order in which >> each component >> should run. As a cosequence, there is no way to know in what state the >> provisioning is. >> 3. The same provisioning system uses a non-persistent ActiveRecord hooks >> to tap into the work. >> >> >> *The proposal*: >> >> 1. Create a separate object that will hold the information for the >> provisioning. >> 2. Move the connection of a target to an aspect (concern). It will make >> possible to provision objects other than hosts, like NICs. >> 3. Each provision strategy will get its own class, each instance of this >> class will be the provisioning data of a single host. >> >> >> *Data models*: >> We are introducing two new objects to the system: >> 1. The provisioning relation object: This object is pretty simple - it's >> only responsibility is to connect the target to its provisioning. >> Target model class name >> Target ID >> Provision strategy class name >> Provision model ID >> Provision state: New - in process - success - failure >> State change timestamp >> >> 2. Provision instance state: The state saved by the selected strategy to >> maintain the provisioning process. Each provision strategy will be able to >> save its own relevant state. >> Examples for the provision strategies and their properties: >> I will present a flat hierarchy, but it's doesn't (and won't) be the case - >> strategies should inherit/use aspect concepts where it's appropriate. >> >> PXE provision >> Provision interface: which interface should be used for provisioning >> PXELinux template >> Provision template >> Finish template >> Installation medium >> iPXE provision >> Provision interface: which interface should be used for provisioning >> iPXELinux template >> Provision template >> Finish template >> Installation medium >> >> image-based provision >> Provision interface >> Image >> Finish template >> >> *Advantages*: >> From user perspective: >> >> 1. No need to think about provisioning properties, if the host is not >> provisioned >> 2. No need to think about properties that are not relevant for the >> selected provision strategy >> 3. Better way to monitor the provision process (as long as the strategy >> is written the right way) >> 4. It would be possible to create a UI specific to each provisioning >> system. >> >> >> From developer perspective: >> >> 1. Cleaning up the Host object >> 2. Removing cross-concern dependency >> 3. Creating pluggable architecture for orchestrations - it will be >> possible add another orchestrations via plugins >> 4. Creating a single object responsible for the orchestration process - >> no need to guess the dependencies >> 5. Moving the responsibilities of creating/modifying actual objects >> (such as DNS records) to the models that describe them. >> 6. The ability to derive each property using a different strategy - some >> properties will be derived from the host/hostgroup hierarchy, >> others (such as installation media) could be derived from the >> organizations/locations hierarchy. >> >> >> *Backwards compatibility:* >> Since there are properties that are moved out of the host, it can break >> extensions that were relying >> on them. To handle it, a new concern will be created, that will delegate >> all the relevant properties >> to the orchestration subsystem with a deprecation warning. >> The hooks plugin will be changed a bit to enable the old behavior >> >> -- >> 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. >> >

Gwmngilfen · March 15, 2015, 9:25pm

I need to re-read the whole proposal for a better reaction, but just a
small thing that bugged me: -1 for using "snap". To me "snap" means
"broken" (as in "the branch snapped"). If you mean "provisioning
state" then call it that.

Greg

···

On 15 March 2015 at 16:37, Marek Hulan wrote: > Provision instance state -> Provisioning snap

stbenjam · March 15, 2015, 8:56pm

> Hello
>
> We had a further discussion today about removing provision related objects
> from host and hostgroup. I'll try to summarize outcomes and kindly ask for
> inputs from others. All comments are welcome. I attached a quick diagram
> illustrating the changes.
>
> Some entity names were changed so here's the mapping of previous names to
> names used in the diagram:
> Provisioning relation object -> Provisioning
> Provisioning strategy -> Provisioning method
> Provision instance state -> Provisioning snap
>
> We'd basically split Hostgroup into two parts. Everything related to
> configuration would remain part of a Hostgroup (puppet classes, config groups,
> Environment) while the rest which is related to provision would be extracted
> to a new entity called ProvisionGroup (work name, suggestions appreciated).
> When user build a new host he'd be able select one Hostgroup and one
> ProvisionGroup. We'd also introduce a ProvisioningSnap which is a copy of all
> required foreign keys of provisioning data, based on selected
> ProvisioningMethod. ProvisioningMethod may be something like PXE, Image etc.
> When we have a ProvisioningSnap and user selected a ProvisioningMethod, we can
> start Provisioning - this represents the actual act.
>
> The biggest difference between Hostgroup and ProvisionGroup (for me) is that
> any change in Hostgroup associations are applied immediately (e.g. you assign
> new puppet class, it's part of ENC output) while changes in ProvisionGroup do
> affect only new provisionings. The pointers to the data are kept in
> ProvisioningSnap so you can reprovision host in a same way it has been
> provisioned before. If user changes the linked object, e.g. installation
> medium URL, we can display a warning that there is a ProvisioningSnap that
> refers to it, so the action would invalidate the snap. So users might add new
> object rather than editing existing one.
>
> One small inconsistency in previous statement is that changes of puppet
> parameter overrides assigned to OS would still apply immediately, even though
> the OS was originally assigned through ProvisionGroup. I think we should keep
> the OS association on Host object but keep the meaning of this relationship
> only relevant for configuration, not provisioning. I think this relationship
> is still useful on Foreman installations that are not used for provisioning.
> The other way would be, that we should only look at facts, but it does not
> look right to me.
>
> One thing we didn't agree on is whether the ProvisioningSnap should contain
> all available data, or just those required for particular ProvisioningMethod.
> Opinions are again very welcome. Provisioning snap could sometimes contain
> installation media (PXE based provisioning method) sometimes not (Image
> based). Or we could always store all data such as installation medium, even if
> they are not required for currently selected provisioning method.
>
> Thanks for your input.

So the kinds of fields that are both on host groups and hosts will move
to only being on the HostGroup / ProvisionGroup objects? I.e. Puppet
master? Or will it still work the same where I can build a one-off host
without these objects?

ProvisionSnap seems to introduce partial versioning of the information,
why not go whole hog? Many Katello users have expressed a desire
for managing host groups through a lifecycle like they do content, why
don't we adopt the same language and flow in Foreman instead of creating
something different?

If I have some object I use to define a "widgets.com production web
server" - why not version this, and promote through named
environments like development, QA, production, etc. I want to be able
to play with objects in a development environment, and then apply those
changes to Production with a few clicks. How is that use case addressed
here?

And one final thought, anything being done here should play nicely with
plugins, ideally via defined extension points, and we need to coordinate
the features to ensure continued comatability between Foreman develop
and Katello master.

···

On Sun, Mar 15, 2015 at 06:37:56PM +0200, Marek Hulan wrote:

–
Marek

On Tuesday 24 of February 2015 05:01:33 Shim Shtein wrote:

Here is a proposal for refactoring our provisioning orchestration system.
Please comment, I want to be sure I am not missing something big here.

Provisioning as an aspect

Current state:

The Host object contains a lot of information about the provisioning
procedure.
This information, once used when the host is provisioned is not used by
other subsystems
in Foreman.

The provisioning is performed by different disjoint components
(orchestration classes)
that are using a priority mechanism to define the correct order in which
each component
should run. As a cosequence, there is no way to know in what state the
provisioning is.

The same provisioning system uses a non-persistent ActiveRecord hooks
to tap into the work.

The proposal:

Create a separate object that will hold the information for the
provisioning.

Move the connection of a target to an aspect (concern). It will make
possible to provision objects other than hosts, like NICs.

Each provision strategy will get its own class, each instance of this
class will be the provisioning data of a single host.

Data models:
We are introducing two new objects to the system:

The provisioning relation object: This object is pretty simple - it’s
only responsibility is to connect the target to its provisioning.
Target model class name
Target ID
Provision strategy class name
Provision model ID
Provision state: New - in process - success - failure
State change timestamp

Provision instance state: The state saved by the selected strategy to
maintain the provisioning process. Each provision strategy will be able to
save its own relevant state.
Examples for the provision strategies and their properties:
I will present a flat hierarchy, but it’s doesn’t (and won’t) be the case -
strategies should inherit/use aspect concepts where it’s appropriate.

PXE provision
Provision interface: which interface should be used for provisioning
PXELinux template
Provision template
Finish template
Installation medium
iPXE provision
Provision interface: which interface should be used for provisioning
iPXELinux template
Provision template
Finish template
Installation medium

image-based provision
Provision interface
Image
Finish template

Advantages:
From user perspective:

No need to think about provisioning properties, if the host is not
provisioned

No need to think about properties that are not relevant for the
selected provision strategy

Better way to monitor the provision process (as long as the strategy
is written the right way)

It would be possible to create a UI specific to each provisioning
system.

From developer perspective:

Cleaning up the Host object

Removing cross-concern dependency

Creating pluggable architecture for orchestrations - it will be
possible add another orchestrations via plugins

Creating a single object responsible for the orchestration process -
no need to guess the dependencies

Moving the responsibilities of creating/modifying actual objects
(such as DNS records) to the models that describe them.

The ability to derive each property using a different strategy - some
properties will be derived from the host/hostgroup hierarchy,
others (such as installation media) could be derived from the
organizations/locations hierarchy.

Backwards compatibility:
Since there are properties that are moved out of the host, it can break
extensions that were relying
on them. To handle it, a new concern will be created, that will delegate
all the relevant properties
to the orchestration subsystem with a deprecation warning.
The hooks plugin will be changed a bit to enable the old behavior

–
Marek

–
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.

–
Best Regards,

Stephen Benjamin
Red Hat Engineering

ohadlevy · March 16, 2015, 8:46am

> Hello
>
> We had a further discussion today about removing provision related objects
> from host and hostgroup. I'll try to summarize outcomes and kindly ask for
> inputs from others. All comments are welcome. I attached a quick diagram
> illustrating the changes.
>
> Some entity names were changed so here's the mapping of previous names to
> names used in the diagram:
> Provisioning relation object -> Provisioning
> Provisioning strategy -> Provisioning method
> Provision instance state -> Provisioning snap
>
> We'd basically split Hostgroup into two parts. Everything related to
> configuration would remain part of a Hostgroup (puppet classes, config
> groups,
> Environment) while the rest which is related to provision would be
> extracted
> to a new entity called ProvisionGroup (work name, suggestions appreciated).
>
os/provision profile ?

> When user build a new host he'd be able select one Hostgroup and one
> ProvisionGroup. We'd also introduce a ProvisioningSnap which is a copy of
> all
> required foreign keys of provisioning data, based on selected
> ProvisioningMethod. ProvisioningMethod may be something like PXE, Image
> etc.
> When we have a ProvisioningSnap and user selected a ProvisioningMethod, we
> can
> start Provisioning - this represents the actual act.
>
The biggest difference between Hostgroup and ProvisionGroup (for me) is that
> any change in Hostgroup associations are applied immediately (e.g. you
> assign
> new puppet class, it's part of ENC output) while changes in ProvisionGroup
> do
> affect only new provisionings. The pointers to the data are kept in
> ProvisioningSnap so you can reprovision host in a same way it has been
> provisioned before. If user changes the linked object, e.g. installation
> medium URL, we can display a warning that there is a ProvisioningSnap that
> refers to it, so the action would invalidate the snap. So users might add
> new
> object rather than editing existing one.
>
> when you split hostgroups, what happens to the host object? does it keeps
all of the foreign keys in it (ptable_id, media_id etc) or rather it now
refers to a provisioning snap?

> One small inconsistency in previous statement is that changes of puppet
> parameter overrides assigned to OS would still apply immediately, even
> though
> the OS was originally assigned through ProvisionGroup. I think we should
> keep
> the OS association on Host object but keep the meaning of this relationship
> only relevant for configuration, not provisioning. I think this
> relationship
> is still useful on Foreman installations that are not used for
> provisioning.
> The other way would be, that we should only look at facts, but it does not
> look right to me.
>
right, that would cause inconsistency, see

and there is an open question about when can some fields be edited, for
example, do you want to allow to change the OS of a host in non build state?

>
> One thing we didn't agree on is whether the ProvisioningSnap should contain
> all available data, or just those required for particular
> ProvisioningMethod.
> Opinions are again very welcome. Provisioning snap could sometimes contain
> installation media (PXE based provisioning method) sometimes not (Image
> based). Or we could always store all data such as installation medium,
> even if
> they are not required for currently selected provisioning method.
>
whats the pro/con ?

thanks
Ohad

···

On Sun, Mar 15, 2015 at 6:37 PM, Marek Hulan wrote:

Thanks for your input.

–
Marek

On Tuesday 24 of February 2015 05:01:33 Shim Shtein wrote:

Here is a proposal for refactoring our provisioning orchestration system.
Please comment, I want to be sure I am not missing something big here.

Provisioning as an aspect

Current state:

The Host object contains a lot of information about the
provisioning
procedure.
This information, once used when the host is provisioned is not used
by
other subsystems
in Foreman.

The provisioning is performed by different disjoint components
(orchestration classes)
that are using a priority mechanism to define the correct order in
which
each component
should run. As a cosequence, there is no way to know in what state the
provisioning is.

The same provisioning system uses a non-persistent ActiveRecord
hooks
to tap into the work.

The proposal:

Create a separate object that will hold the information for the
provisioning.

Move the connection of a target to an aspect (concern). It will
make
possible to provision objects other than hosts, like NICs.

Each provision strategy will get its own class, each instance of
this
class will be the provisioning data of a single host.

Data models:
We are introducing two new objects to the system:

The provisioning relation object: This object is pretty simple - it’s
only responsibility is to connect the target to its provisioning.
Target model class name
Target ID
Provision strategy class name
Provision model ID
Provision state: New - in process - success - failure
State change timestamp

Provision instance state: The state saved by the selected strategy to
maintain the provisioning process. Each provision strategy will be able
to
save its own relevant state.
Examples for the provision strategies and their properties:
I will present a flat hierarchy, but it’s doesn’t (and won’t) be the
case -
strategies should inherit/use aspect concepts where it’s appropriate.

PXE provision
Provision interface: which interface should be used for provisioning
PXELinux template
Provision template
Finish template
Installation medium
iPXE provision
Provision interface: which interface should be used for provisioning
iPXELinux template
Provision template
Finish template
Installation medium

image-based provision
Provision interface
Image
Finish template

Advantages:
From user perspective:

No need to think about provisioning properties, if the host is not
provisioned

No need to think about properties that are not relevant for the
selected provision strategy

Better way to monitor the provision process (as long as the
strategy
is written the right way)

It would be possible to create a UI specific to each provisioning
system.

From developer perspective:

Cleaning up the Host object

Removing cross-concern dependency

Creating pluggable architecture for orchestrations - it will be
possible add another orchestrations via plugins

Creating a single object responsible for the orchestration process

no need to guess the dependencies
5. Moving the responsibilities of creating/modifying actual objects
(such as DNS records) to the models that describe them.
6. The ability to derive each property using a different strategy -
some
properties will be derived from the host/hostgroup hierarchy,
others (such as installation media) could be derived from the
organizations/locations hierarchy.

Backwards compatibility:
Since there are properties that are moved out of the host, it can break
extensions that were relying
on them. To handle it, a new concern will be created, that will delegate
all the relevant properties
to the orchestration subsystem with a deprecation warning.
The hooks plugin will be changed a bit to enable the old behavior

–
Marek

–
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.

iNecas · March 16, 2015, 3:05pm

> Hello
>
> We had a further discussion today about removing provision related objects
> from host and hostgroup. I'll try to summarize outcomes and kindly ask for
> inputs from others. All comments are welcome. I attached a quick diagram
> illustrating the changes.
>
> Some entity names were changed so here's the mapping of previous names to
> names used in the diagram:
> Provisioning relation object -> Provisioning
> Provisioning strategy -> Provisioning method
> Provision instance state -> Provisioning snap
>
> We'd basically split Hostgroup into two parts. Everything related to
> configuration would remain part of a Hostgroup (puppet classes, config
> groups,
> Environment) while the rest which is related to provision would be extracted
> to a new entity called ProvisionGroup (work name, suggestions appreciated).
> When user build a new host he'd be able select one Hostgroup and one
> ProvisionGroup. We'd also introduce a ProvisioningSnap which is a copy of all
> required foreign keys of provisioning data, based on selected
> ProvisioningMethod. ProvisioningMethod may be something like PXE, Image etc.
> When we have a ProvisioningSnap and user selected a ProvisioningMethod, we
> can
> start Provisioning - this represents the actual act.

If the goal is to represent the state of the host in respect to the provisioning,
what about, rather then doing it for every provisioning act, doing it the
state-machine way. So the ProvisioningState would contain the information
about the current state of the host from the provisioning perspective,
with defined transitions, such as:

ProvisioningState:
pending -> initializing-compute-resource -> building -> waiting to be ready

Similarly, there would be another state machine (with common code base), for
modeling the state machine for PuppetState(not-applied -> up-to-date -> out-of-sync),
SubscriptionState (unsubscribed -> valid -> invalid), UpdatesApplicabilityState (up-to-date,
errata-applicable-in-current-environment, errata-applicable-in-library),
ScapComplience(ok -> failed), even OrchstrationState (no-tasks-running -> some-tasks-running -> some-tasks-failed).

Ideally (at least from my point of view), a Dynflow actions would be used to switch
the values of the actions, on one could hook into the dynflow actions that represent
the change (for all the goodness that it brings from the stability and visibility point of view).

Every host would have at most one type of every state object type. When defining the
interfaces properly, we could build a generic 'status page', where very state
type would define, what it means to be green (everything fine)/yellow
(you might take some actions here)/red (you're doomed, do something with it).

One could then filter all hosts, that need attention in general, or focus on
some state type.

It even might make sense to not limit this just to hosts, but other objects
(smart-proxy, content view, a docker container) have also states that
are worth tracking/being able to do filters on.

– Ivan

···

----- Original Message -----

The biggest difference between Hostgroup and ProvisionGroup (for me) is that
any change in Hostgroup associations are applied immediately (e.g. you assign
new puppet class, it’s part of ENC output) while changes in ProvisionGroup do
affect only new provisionings. The pointers to the data are kept in
ProvisioningSnap so you can reprovision host in a same way it has been
provisioned before. If user changes the linked object, e.g. installation
medium URL, we can display a warning that there is a ProvisioningSnap that
refers to it, so the action would invalidate the snap. So users might add new
object rather than editing existing one.

One small inconsistency in previous statement is that changes of puppet
parameter overrides assigned to OS would still apply immediately, even though
the OS was originally assigned through ProvisionGroup. I think we should keep
the OS association on Host object but keep the meaning of this relationship
only relevant for configuration, not provisioning. I think this relationship
is still useful on Foreman installations that are not used for provisioning.
The other way would be, that we should only look at facts, but it does not
look right to me.

One thing we didn’t agree on is whether the ProvisioningSnap should contain
all available data, or just those required for particular ProvisioningMethod.
Opinions are again very welcome. Provisioning snap could sometimes contain
installation media (PXE based provisioning method) sometimes not (Image
based). Or we could always store all data such as installation medium, even
if
they are not required for currently selected provisioning method.

Thanks for your input.

–
Marek

On Tuesday 24 of February 2015 05:01:33 Shim Shtein wrote:

Here is a proposal for refactoring our provisioning orchestration system.
Please comment, I want to be sure I am not missing something big here.

Provisioning as an aspect

Current state:

The Host object contains a lot of information about the provisioning
procedure.
This information, once used when the host is provisioned is not used by
other subsystems
in Foreman.

The provisioning is performed by different disjoint components
(orchestration classes)
that are using a priority mechanism to define the correct order in which
each component
should run. As a cosequence, there is no way to know in what state the
provisioning is.

The same provisioning system uses a non-persistent ActiveRecord hooks
to tap into the work.

The proposal:

Create a separate object that will hold the information for the
provisioning.

Move the connection of a target to an aspect (concern). It will make
possible to provision objects other than hosts, like NICs.

Each provision strategy will get its own class, each instance of this
class will be the provisioning data of a single host.

Data models:
We are introducing two new objects to the system:

The provisioning relation object: This object is pretty simple - it’s
only responsibility is to connect the target to its provisioning.
Target model class name
Target ID
Provision strategy class name
Provision model ID
Provision state: New - in process - success - failure
State change timestamp

Provision instance state: The state saved by the selected strategy to
maintain the provisioning process. Each provision strategy will be able to
save its own relevant state.
Examples for the provision strategies and their properties:
I will present a flat hierarchy, but it’s doesn’t (and won’t) be the case -
strategies should inherit/use aspect concepts where it’s appropriate.

PXE provision
Provision interface: which interface should be used for provisioning
PXELinux template
Provision template
Finish template
Installation medium
iPXE provision
Provision interface: which interface should be used for provisioning
iPXELinux template
Provision template
Finish template
Installation medium

image-based provision
Provision interface
Image
Finish template

Advantages:
From user perspective:

No need to think about provisioning properties, if the host is not
provisioned

No need to think about properties that are not relevant for the
selected provision strategy

Better way to monitor the provision process (as long as the strategy
is written the right way)

It would be possible to create a UI specific to each provisioning
system.

From developer perspective:

Cleaning up the Host object

Removing cross-concern dependency

Creating pluggable architecture for orchestrations - it will be
possible add another orchestrations via plugins

Creating a single object responsible for the orchestration process -
no need to guess the dependencies

Moving the responsibilities of creating/modifying actual objects
(such as DNS records) to the models that describe them.

The ability to derive each property using a different strategy - some
properties will be derived from the host/hostgroup hierarchy,
others (such as installation media) could be derived from the
organizations/locations hierarchy.

Backwards compatibility:
Since there are properties that are moved out of the host, it can break
extensions that were relying
on them. To handle it, a new concern will be created, that will delegate
all the relevant properties
to the orchestration subsystem with a deprecation warning.
The hooks plugin will be changed a bit to enable the old behavior

–
Marek

–
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.

iNecas · February 25, 2015, 4:28pm

>
> > DISCLAIMER: I'm as unbiased as a Dynflow developer can be
> >
> > First of all thanks for bringing this topic up. I'm really glad
> > the about the focus on refactoring the orchestration, and I fully
> > agree with problems you've stated in the "Current state part".
> >
> > To the proposal itself, to be honest, many of the features you've described
> > here are already part of the Dynflow or foreman-tasks and Dynflow itself
> > was designed
> > in a way to support the Foreman's host orchestration, such as:
> >
> > * tracking the state of the process (including the progress)
> > * storing the data about the provisioning in the action inputs
> > * pluggable architecture through the subsciptions
> > * connection between ActiveRecord resources and the task by the use of the
> > locks
> > * top-down approach for the orchestration
> >
> > Additionally, there are other features that come with Dynflow for free:
> >
> > * rescue strategies (pause/resume and skip are implemented now, more of
> > the to come)
> > * ability to make more complex orchestrations as composition of simpler
> > ones
> > * support for running independent steps concurrently
> > * not limited just to provisioning
> > * already integration in the CLI
> > * heavily used Katello, Staypuf, some appearance also in docker, chef and
> > others
> > * testing helpers
> > * extendability via middlewares
> >
> > I know moving to the Dynflow is the next step. However, since there is
> > some overlap
> > already in this proposal, I would like to suggest the following:
> >
> > 1. build the example host orchestration on Dynflow. The scenario would be:
> >
> > a. create ip reservation
> > b. create dns record
> > c. create ftfp file
> > d. create libvirt VM
> > e. wait for the provisioning the finish
> > f. update the ftfp to local boot
> >
> >
>
> my overall Goal is not to use dynflow, rather then to provide more
> functionality, robustness etc around provisioning, for example I want
> answers to the following questions:
>
> - can i provision via this hostgroup?
> - is my infrastructure ready to provision?
> - can i react to provisioning failures automatically?
> - can i know exactly in which state my provisioning is on?
>
> dynflow is most likely the right way forward to implement such features,
> but its not just about the orchestration part.
> we did start with a "hack" answering some of these questions via the
> rebuilt host action, but this was done without changing the host object,
> and only for the rebuilt action instead of the more general case.
>
> my point is, that regardless of implementation (dynflow or otherwise) I
> would like to reduce the scope of the host object, its overloaded and makes
> any new feature challenging because of its scope.
>
> I think shim started in the right approach to reduce the scope of the host
> object, by moving all of the provisioning related properties out of the
> host object, this to me sounds like it can happen prior to dynflow work?

That's what I meant with the step 4. below. The current proposal touches
the orchestration several times, and that's where I feel the risk of duplication
of efforts. Also, showing how the orchestration would look like in Dynflow might
help identifying what needs to be extracted out of the host to specific objects
and what can stay as part of the orchestration.

I'm not saying we can't do anything about the current state prior moving to Dynflow.
Let's just identify what improvements can be done without overlaps.

– Ivan

···

----- Original Message ----- > On Wed, Feb 25, 2015 at 4:18 PM, Ivan Necas wrote:

Ohad

review that, identifying the overlaps with the current proposal

identify the improvements required on Dynflow based on that review

identify things that fit outside of Dynflow/Foreman-tasks

It should be possible to do the step 1 in few days, so we could
do the review next week.

My main concern about the current proposal and the “without Dynflow first”
approach is the risk of the overlapping and doing some things twice. That
doesn’t mean only duplicate effort, but also twice as many migrations etc.
On the other hand, if there are things that the orchestration needs from
foreman-tasks/dynflow,
others will already benefit from the improvements.

One lesson learned from moving Katello on Dynflow was: we already had a
branch
with most of the things Dynflowised, while new updates were still being
made
in the old orchestration, which caused pains on both side: the dynflow
branch
needed to be rebased often with conflicts, not mentioning the pain to do
changes in the old orchestration in the meantime. So this time, I would
like
to take different approach and given we’re moving to Dynflow anyway,
counting on that from the beginning.

Even if it doesn’t show up as viable alternative to start with, it might
bring more light on the goal where (I hope) we would like to get.

On the foreman-tasks and Dynflow being “Ivan’s projects”, we can fix that
with more people starting working on that: if there are gaps to fill
(there are already some known ones) to support the host orchestration case,
I would be more than happy to work with others on implementing them.

– Ivan

----- Original Message -----

Here is a proposal for refactoring our provisioning orchestration system.
Please comment, I want to be sure I am not missing something big here.

Provisioning as an aspect

Current state:

The Host object contains a lot of information about the
provisioning
procedure.
This information, once used when the host is provisioned is not used
by
other subsystems
in Foreman.

The provisioning is performed by different disjoint components
(orchestration classes)
that are using a priority mechanism to define the correct order in
which
each component
should run. As a cosequence, there is no way to know in what state the
provisioning is.

The same provisioning system uses a non-persistent ActiveRecord
hooks
to tap into the work.

The proposal:

Create a separate object that will hold the information for the
provisioning.

Move the connection of a target to an aspect (concern). It will
make
possible to provision objects other than hosts, like NICs.

Each provision strategy will get its own class, each instance of
this
class will be the provisioning data of a single host.

Data models:
We are introducing two new objects to the system:

The provisioning relation object: This object is pretty simple - it’s
only responsibility is to connect the target to its provisioning.
Target model class name
Target ID
Provision strategy class name
Provision model ID
Provision state: New - in process - success - failure
State change timestamp

Provision instance state: The state saved by the selected strategy to
maintain the provisioning process. Each provision strategy will be able
to
save its own relevant state.
Examples for the provision strategies and their properties:
I will present a flat hierarchy, but it’s doesn’t (and won’t) be the
case -
strategies should inherit/use aspect concepts where it’s appropriate.

PXE provision
Provision interface: which interface should be used for provisioning
PXELinux template
Provision template
Finish template
Installation medium
iPXE provision
Provision interface: which interface should be used for provisioning
iPXELinux template
Provision template
Finish template
Installation medium

image-based provision
Provision interface
Image
Finish template

Advantages:
From user perspective:

No need to think about provisioning properties, if the host is not
provisioned

No need to think about properties that are not relevant for the
selected provision strategy

Better way to monitor the provision process (as long as the
strategy
is written the right way)

It would be possible to create a UI specific to each provisioning
system.

From developer perspective:

Cleaning up the Host object

Removing cross-concern dependency

Creating pluggable architecture for orchestrations - it will be
possible add another orchestrations via plugins

Creating a single object responsible for the orchestration process

no need to guess the dependencies
5. Moving the responsibilities of creating/modifying actual objects
(such as DNS records) to the models that describe them.
6. The ability to derive each property using a different strategy -
some
properties will be derived from the host/hostgroup hierarchy,
others (such as installation media) could be derived from the
organizations/locations hierarchy.

Backwards compatibility:
Since there are properties that are moved out of the host, it can break
extensions that were relying
on them. To handle it, a new concern will be created, that will delegate
all the relevant properties
to the orchestration subsystem with a deprecation warning.
The hooks plugin will be changed a bit to enable the old behavior

–
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.

–
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.

–
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.

Marek_Hulan · February 26, 2015, 9:24am

>
> > > DISCLAIMER: I'm as unbiased as a Dynflow developer can be
> > >
> > > First of all thanks for bringing this topic up. I'm really glad
> > > the about the focus on refactoring the orchestration, and I fully
> > > agree with problems you've stated in the "Current state part".
> > >
> > > To the proposal itself, to be honest, many of the features you've
> > > described
> > > here are already part of the Dynflow or foreman-tasks and Dynflow itself
> > > was designed
> > > in a way to support the Foreman's host orchestration, such as:
> > >
> > > * tracking the state of the process (including the progress)
> > > * storing the data about the provisioning in the action inputs
> > > * pluggable architecture through the subsciptions
> > > * connection between ActiveRecord resources and the task by the use of
> > > the
> > > locks
> > > * top-down approach for the orchestration
> > >
> > > Additionally, there are other features that come with Dynflow for free:
> > >
> > > * rescue strategies (pause/resume and skip are implemented now, more of
> > > the to come)
> > > * ability to make more complex orchestrations as composition of simpler
> > > ones
> > > * support for running independent steps concurrently
> > > * not limited just to provisioning
> > > * already integration in the CLI
> > > * heavily used Katello, Staypuf, some appearance also in docker, chef
> > > and
> > > others
> > > * testing helpers
> > > * extendability via middlewares
> > >
> > > I know moving to the Dynflow is the next step. However, since there is
> > > some overlap
> > > already in this proposal, I would like to suggest the following:
> > >
> > > 1. build the example host orchestration on Dynflow. The scenario would
be:
> > > a. create ip reservation
> > > b. create dns record
> > > c. create ftfp file
> > > d. create libvirt VM
> > > e. wait for the provisioning the finish
> > > f. update the ftfp to local boot
> >
> > my overall Goal is not to use dynflow, rather then to provide more
> > functionality, robustness etc around provisioning, for example I want
> > answers to the following questions:
> >
> > - can i provision via this hostgroup?
> > - is my infrastructure ready to provision?
> > - can i react to provisioning failures automatically?
> > - can i know exactly in which state my provisioning is on?
> >
> > dynflow is most likely the right way forward to implement such features,
> > but its not just about the orchestration part.
> > we did start with a "hack" answering some of these questions via the
> > rebuilt host action, but this was done without changing the host object,
> > and only for the rebuilt action instead of the more general case.
> >
> > my point is, that regardless of implementation (dynflow or otherwise) I
> > would like to reduce the scope of the host object, its overloaded and
> > makes
> > any new feature challenging because of its scope.
> >
> > I think shim started in the right approach to reduce the scope of the
> > host
> > object, by moving all of the provisioning related properties out of the
> > host object, this to me sounds like it can happen prior to dynflow work?
>
> That's what I meant with the step 4. below. The current proposal touches
> the orchestration several times, and that's where I feel the risk of
> duplication of efforts. Also, showing how the orchestration would look like
> in Dynflow might help identifying what needs to be extracted out of the
> host to specific objects and what can stay as part of the orchestration.
>
> I'm not saying we can't do anything about the current state prior moving to
> Dynflow. Let's just identify what improvements can be done without
> overlaps.

I think that the potential overlap won't be too big and I see the benefit of
extracting responsibilities from Host object but Ivan has a very good point
with creating PoC of simple orchestration using Dynflow, that would make
easier to think about what can be later reused from Dynflow, how it will be
possible to interact and also what are missing pieces in current Dynflow
version. Benefits I see - easier adoption of Dynflow in future and Dynflow
could be improved during provisioning extraction.

···

On Wednesday 25 of February 2015 11:28:03 Ivan Necas wrote: > ----- Original Message ----- > > On Wed, Feb 25, 2015 at 4:18 PM, Ivan Necas wrote:

–
Marek

– Ivan

Ohad

review that, identifying the overlaps with the current proposal

identify the improvements required on Dynflow based on that review

identify things that fit outside of Dynflow/Foreman-tasks

It should be possible to do the step 1 in few days, so we could
do the review next week.

My main concern about the current proposal and the “without Dynflow
first”
approach is the risk of the overlapping and doing some things twice.
That
doesn’t mean only duplicate effort, but also twice as many migrations
etc.
On the other hand, if there are things that the orchestration needs from
foreman-tasks/dynflow,
others will already benefit from the improvements.

One lesson learned from moving Katello on Dynflow was: we already had a
branch
with most of the things Dynflowised, while new updates were still being
made
in the old orchestration, which caused pains on both side: the dynflow
branch
needed to be rebased often with conflicts, not mentioning the pain to do
changes in the old orchestration in the meantime. So this time, I would
like
to take different approach and given we’re moving to Dynflow anyway,
counting on that from the beginning.

Even if it doesn’t show up as viable alternative to start with, it might
bring more light on the goal where (I hope) we would like to get.

On the foreman-tasks and Dynflow being “Ivan’s projects”, we can fix
that
with more people starting working on that: if there are gaps to fill
(there are already some known ones) to support the host orchestration
case,
I would be more than happy to work with others on implementing them.

– Ivan

----- Original Message -----

Here is a proposal for refactoring our provisioning orchestration
system.
Please comment, I want to be sure I am not missing something big here.

Provisioning as an aspect

Current state:

The Host object contains a lot of information about the

provisioning

procedure.
This information, once used when the host is provisioned is not
used

by

other subsystems
in Foreman.
2. The provisioning is performed by different disjoint components
(orchestration classes)
that are using a priority mechanism to define the correct order in

which

each component
should run. As a cosequence, there is no way to know in what state
the
provisioning is.
3. The same provisioning system uses a non-persistent ActiveRecord

hooks

to tap into the work.

The proposal:

Create a separate object that will hold the information for the
provisioning.

Move the connection of a target to an aspect (concern). It will

make

possible to provision objects other than hosts, like NICs.
3. Each provision strategy will get its own class, each instance of

this

class will be the provisioning data of a single host.

Data models:
We are introducing two new objects to the system:

The provisioning relation object: This object is pretty simple -
it’s
only responsibility is to connect the target to its provisioning.
Target model class name
Target ID
Provision strategy class name
Provision model ID
Provision state: New - in process - success - failure
State change timestamp

Provision instance state: The state saved by the selected strategy
to
maintain the provisioning process. Each provision strategy will be
able

to

save its own relevant state.
Examples for the provision strategies and their properties:
I will present a flat hierarchy, but it’s doesn’t (and won’t) be the

case -

strategies should inherit/use aspect concepts where it’s appropriate.

PXE provision
Provision interface: which interface should be used for provisioning
PXELinux template
Provision template
Finish template
Installation medium
iPXE provision
Provision interface: which interface should be used for provisioning
iPXELinux template
Provision template
Finish template
Installation medium

image-based provision
Provision interface
Image
Finish template

Advantages:

From user perspective:

No need to think about provisioning properties, if the host is
not
provisioned

No need to think about properties that are not relevant for the
selected provision strategy

Better way to monitor the provision process (as long as the

strategy

is written the right way)
4. It would be possible to create a UI specific to each
provisioning
system.

From developer perspective:

Cleaning up the Host object

Removing cross-concern dependency

Creating pluggable architecture for orchestrations - it will be
possible add another orchestrations via plugins

Creating a single object responsible for the orchestration
process

no need to guess the dependencies
5. Moving the responsibilities of creating/modifying actual objects
(such as DNS records) to the models that describe them.
6. The ability to derive each property using a different strategy -

some

properties will be derived from the host/hostgroup hierarchy,
others (such as installation media) could be derived from the
organizations/locations hierarchy.

Backwards compatibility:
Since there are properties that are moved out of the host, it can
break
extensions that were relying
on them. To handle it, a new concern will be created, that will
delegate
all the relevant properties
to the orchestration subsystem with a deprecation warning.
The hooks plugin will be changed a bit to enable the old behavior

–
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.

–
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.

–
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.

Gwmngilfen · March 2, 2015, 1:52pm

I'll not get involved about the technical merits of whether or not to
to go direct to the Dynflow endpoint, or use something intermediate

However, I will note this: changing the orchestration and getting it
wrong has the potential to not only destroy a user's install, but
their entire network infrastructure (eg removing all the DNS records
by accident, etc). It was something we were very aware of during the
networking rewrite for 1.8, and we went to a lot of effort to test it
before it was even opened as a PR.

In other words, changing this stuff is a risk. I agree orchestration
needs updating (oh boy, does it need doing…), but we should try to
minimize the risk, as well as the time spent. Rewriting orchestration
twice sounds like a bad idea from this viewpoint, at least to me. The
time invested to test it each time is essentially duplication.

dLobatog · March 16, 2015, 7:37am

My main concern about this are current users who have to deal with
migrating from Host groups to this new setup. Is there any plan to
automate that step? I can see it being quite annoying.

See inline comments below:

> > Hello
> >
> > We had a further discussion today about removing provision related objects
> > from host and hostgroup. I'll try to summarize outcomes and kindly ask for
> > inputs from others. All comments are welcome. I attached a quick diagram
> > illustrating the changes.
> >
> > Some entity names were changed so here's the mapping of previous names to
> > names used in the diagram:
> > Provisioning relation object -> Provisioning
> > Provisioning strategy -> Provisioning method
> > Provision instance state -> Provisioning snap
> >
> > We'd basically split Hostgroup into two parts. Everything related to
> > configuration would remain part of a Hostgroup (puppet classes, config groups,
> > Environment) while the rest which is related to provision would be extracted
> > to a new entity called ProvisionGroup (work name, suggestions appreciated).

Is this equivalent to simply moving environments to Config groups? At
the moment these hold all configuration options except for that.

It sounds to me like this would be functionally equivalent to:

Rename Host group to Provision group
Move environments to Config groups

> > When user build a new host he'd be able select one Hostgroup and one
> > ProvisionGroup. We'd also introduce a ProvisioningSnap which is a copy of all
> > required foreign keys of provisioning data, based on selected
> > ProvisioningMethod. ProvisioningMethod may be something like PXE, Image etc.
> > When we have a ProvisioningSnap and user selected a ProvisioningMethod, we can
> > start Provisioning - this represents the actual act.

+1, although I can't say I like giving the user more options (it's
already complicated to create a host). How about users with a few hosts,
who want to apply classes on hosts individually?
Would they have to create a Config group for each Host or Hosts can have
'individual' Puppet classes (like now)?
> >
> > The biggest difference between Hostgroup and ProvisionGroup (for me) is that
> > any change in Hostgroup associations are applied immediately (e.g. you assign
> > new puppet class, it's part of ENC output) while changes in ProvisionGroup do
> > affect only new provisionings. The pointers to the data are kept in
> > ProvisioningSnap so you can reprovision host in a same way it has been
> > provisioned before. If user changes the linked object, e.g. installation
> > medium URL, we can display a warning that there is a ProvisioningSnap that
> > refers to it, so the action would invalidate the snap. So users might add new
> > object rather than editing existing one.
> >
> > One small inconsistency in previous statement is that changes of puppet
> > parameter overrides assigned to OS would still apply immediately, even though
> > the OS was originally assigned through ProvisionGroup. I think we should keep
> > the OS association on Host object but keep the meaning of this relationship
> > only relevant for configuration, not provisioning. I think this relationship
> > is still useful on Foreman installations that are not used for provisioning.
> > The other way would be, that we should only look at facts, but it does not
> > look right to me.

We already look at uploaded facts to update the OS of the Host, so why
not…

···

On 03/15, Stephen Benjamin wrote: > On Sun, Mar 15, 2015 at 06:37:56PM +0200, Marek Hulan wrote: > > > > One thing we didn't agree on is whether the ProvisioningSnap should contain > > all available data, or just those required for particular ProvisioningMethod. > > Opinions are again very welcome. Provisioning snap could sometimes contain > > installation media (PXE based provisioning method) sometimes not (Image > > based). Or we could always store all data such as installation medium, even if > > they are not required for currently selected provisioning method. > > > > Thanks for your input. > > So the kinds of fields that are both on host groups and hosts will move > to only being on the HostGroup / ProvisionGroup objects? I.e. Puppet > master? Or will it still work the same where I can build a one-off host > without these objects? > > ProvisionSnap seems to introduce partial versioning of the information, > why not go whole hog? Many Katello users have expressed a desire > for managing host groups through a lifecycle like they do content, why > don't we adopt the same language and flow in Foreman instead of creating > something different? > > If I have some object I use to define a "widgets.com production web > server" - why not version this, and promote through named > environments like development, QA, production, etc. I want to be able > to play with objects in a development environment, and then apply those > changes to Production with a few clicks. How is that use case addressed > here? > > And one final thought, anything being done here should play nicely with > plugins, ideally via defined extension points, and we need to coordinate > the features to ensure continued comatability between Foreman develop > and Katello master. > > > > > > -- > > Marek > > > > On Tuesday 24 of February 2015 05:01:33 Shim Shtein wrote: > > > Here is a proposal for refactoring our provisioning orchestration system. > > > Please comment, I want to be sure I am not missing something big here. > > > > > > Provisioning as an aspect > > > > > > *Current state:* > > > > > > 1. The Host object contains a lot of information about the provisioning > > > procedure. > > > This information, once used when the host is provisioned is not used by > > > other subsystems > > > in Foreman. > > > 2. The provisioning is performed by different disjoint components > > > (orchestration classes) > > > that are using a priority mechanism to define the correct order in which > > > each component > > > should run. As a cosequence, there is no way to know in what state the > > > provisioning is. > > > 3. The same provisioning system uses a non-persistent ActiveRecord hooks > > > to tap into the work. > > > > > > > > > *The proposal*: > > > > > > 1. Create a separate object that will hold the information for the > > > provisioning. > > > 2. Move the connection of a target to an aspect (concern). It will make > > > possible to provision objects other than hosts, like NICs. > > > 3. Each provision strategy will get its own class, each instance of this > > > class will be the provisioning data of a single host. > > > > > > > > > *Data models*: > > > We are introducing two new objects to the system: > > > 1. The provisioning relation object: This object is pretty simple - it's > > > only responsibility is to connect the target to its provisioning. > > > Target model class name > > > Target ID > > > Provision strategy class name > > > Provision model ID > > > Provision state: New - in process - success - failure > > > State change timestamp > > > > > > 2. Provision instance state: The state saved by the selected strategy to > > > maintain the provisioning process. Each provision strategy will be able to > > > save its own relevant state. > > > Examples for the provision strategies and their properties: > > > I will present a flat hierarchy, but it's doesn't (and won't) be the case - > > > strategies should inherit/use aspect concepts where it's appropriate. > > > > > > PXE provision > > > Provision interface: which interface should be used for provisioning > > > PXELinux template > > > Provision template > > > Finish template > > > Installation medium > > > iPXE provision > > > Provision interface: which interface should be used for provisioning > > > iPXELinux template > > > Provision template > > > Finish template > > > Installation medium > > > > > > image-based provision > > > Provision interface > > > Image > > > Finish template > > > > > > *Advantages*: > > > From user perspective: > > > > > > 1. No need to think about provisioning properties, if the host is not > > > provisioned > > > 2. No need to think about properties that are not relevant for the > > > selected provision strategy > > > 3. Better way to monitor the provision process (as long as the strategy > > > is written the right way) > > > 4. It would be possible to create a UI specific to each provisioning > > > system. > > > > > > > > > From developer perspective: > > > > > > 1. Cleaning up the Host object > > > 2. Removing cross-concern dependency > > > 3. Creating pluggable architecture for orchestrations - it will be > > > possible add another orchestrations via plugins > > > 4. Creating a single object responsible for the orchestration process - > > > no need to guess the dependencies > > > 5. Moving the responsibilities of creating/modifying actual objects > > > (such as DNS records) to the models that describe them. > > > 6. The ability to derive each property using a different strategy - some > > > properties will be derived from the host/hostgroup hierarchy, > > > others (such as installation media) could be derived from the > > > organizations/locations hierarchy. > > > > > > > > > *Backwards compatibility:* > > > Since there are properties that are moved out of the host, it can break > > > extensions that were relying > > > on them. To handle it, a new concern will be created, that will delegate > > > all the relevant properties > > > to the orchestration subsystem with a deprecation warning. > > > The hooks plugin will be changed a bit to enable the old behavior > > > > -- > > Marek > > > > -- > > 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. > > > > -- > Best Regards, > > Stephen Benjamin > Red Hat Engineering > > -- > 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.

–
Daniel Lobato Garcia

@eLobatoss
blog.daniellobato.me
daniellobato.me

GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato

Marek_Hulan · March 16, 2015, 12:06pm

Ah Ok, that was meant as an abbreviation of snapshot. ProvisioningState works
for me, thanks.

···

On Sunday 15 of March 2015 21:25:43 Greg Sutcliffe wrote: > On 15 March 2015 at 16:37, Marek Hulan wrote: > > Provision instance state -> Provisioning snap > > I need to re-read the whole proposal for a better reaction, but just a > small thing that bugged me: -1 for using "snap". To me "snap" means > "broken" (as in "the branch snapped"). If you mean "provisioning > state" then call it that. > > Greg

–
Marek

Marek_Hulan · March 16, 2015, 12:27pm

Hi,

sending answers below

> > Hello
> >
> > We had a further discussion today about removing provision related objects
> > from host and hostgroup. I'll try to summarize outcomes and kindly ask for
> > inputs from others. All comments are welcome. I attached a quick diagram
> > illustrating the changes.
> >
> > Some entity names were changed so here's the mapping of previous names to
> > names used in the diagram:
> > Provisioning relation object -> Provisioning
> > Provisioning strategy -> Provisioning method
> > Provision instance state -> Provisioning snap
> >
> > We'd basically split Hostgroup into two parts. Everything related to
> > configuration would remain part of a Hostgroup (puppet classes, config
> > groups, Environment) while the rest which is related to provision would
> > be extracted to a new entity called ProvisionGroup (work name,
> > suggestions appreciated). When user build a new host he'd be able select
> > one Hostgroup and one ProvisionGroup. We'd also introduce a
> > ProvisioningSnap which is a copy of all required foreign keys of
> > provisioning data, based on selected
> > ProvisioningMethod. ProvisioningMethod may be something like PXE, Image
> > etc. When we have a ProvisioningSnap and user selected a
> > ProvisioningMethod, we can start Provisioning - this represents the
> > actual act.
> >
> > The biggest difference between Hostgroup and ProvisionGroup (for me) is
> > that any change in Hostgroup associations are applied immediately (e.g.
> > you assign new puppet class, it's part of ENC output) while changes in
> > ProvisionGroup do affect only new provisionings. The pointers to the data
> > are kept in ProvisioningSnap so you can reprovision host in a same way it
> > has been provisioned before. If user changes the linked object, e.g.
> > installation medium URL, we can display a warning that there is a
> > ProvisioningSnap that refers to it, so the action would invalidate the
> > snap. So users might add new object rather than editing existing one.
> >
> > One small inconsistency in previous statement is that changes of puppet
> > parameter overrides assigned to OS would still apply immediately, even
> > though the OS was originally assigned through ProvisionGroup. I think we
> > should keep the OS association on Host object but keep the meaning of
> > this relationship only relevant for configuration, not provisioning. I
> > think this relationship is still useful on Foreman installations that are
> > not used for provisioning. The other way would be, that we should only
> > look at facts, but it does not look right to me.
> >
> > One thing we didn't agree on is whether the ProvisioningSnap should
> > contain
> > all available data, or just those required for particular
> > ProvisioningMethod. Opinions are again very welcome. Provisioning snap
> > could sometimes contain installation media (PXE based provisioning
> > method) sometimes not (Image based). Or we could always store all data
> > such as installation medium, even if they are not required for currently
> > selected provisioning method.
> >
> > Thanks for your input.
>
> So the kinds of fields that are both on host groups and hosts will move
> to only being on the HostGroup / ProvisionGroup objects? I.e. Puppet
> master? Or will it still work the same where I can build a one-off host
> without these objects?

Shimon please correct me if I'm going out of planned direction.

I suppose everything related to configuration would remain as it is now, maybe
later we could extract it similarly. But things specific only for provisioning
should be removed from Host completely. There are object staying somewhere in
between - OS. OS is specific for orchestration but I can also imagine having
it set for Host if I used Foreman without provisioning, just as puppet ENC.
Then the question is whether have it as an explicit entity or use just fact
values to keep this (and to create fact value when creating a host). I still
think it would be better to keep OS as a separate entity as later user might
want to start using provisioning with all existing data.

> ProvisionSnap seems to introduce partial versioning of the information,
> why not go whole hog? Many Katello users have expressed a desire
> for managing host groups through a lifecycle like they do content, why
> don't we adopt the same language and flow in Foreman instead of creating
> something different?

I agree that versioning everything is attractive. But the lifecycle of
configuration and provisioning is independent on each other. Maybe you could
elaborate this a bit more. I think this does not prevent us to do what you
say, actually it prepares the base. Having snapshots (versions) of some data
which can be later associated to some ProvisionView that can be promoted seems
possible to me.

> If I have some object I use to define a "widgets.com production web
> server" - why not version this, and promote through named
> environments like development, QA, production, etc. I want to be able
> to play with objects in a development environment, and then apply those
> changes to Production with a few clicks. How is that use case addressed
> here?

The thing here is that you have overrides per environments, so if you test
something in development, it can behave completely different in production. So
I'm not sure promotion is here the same, unless you version the whole
environment. Or do you refer to Katello lifecycle environments? If so, when we
start to version the configuration, then we might introduce the same logic,
but I think configuration version is not related to provision version.

> And one final thought, anything being done here should play nicely with
> plugins, ideally via defined extension points, and we need to coordinate
> the features to ensure continued comatability between Foreman develop
> and Katello master.

Good point. When we have final design we must make sure there's an easy
migration path and stay backward compatible as much as possible.

···

On Sunday 15 of March 2015 21:56:55 Stephen Benjamin wrote: > On Sun, Mar 15, 2015 at 06:37:56PM +0200, Marek Hulan wrote:

–
Marek

On Tuesday 24 of February 2015 05:01:33 Shim Shtein wrote:

Here is a proposal for refactoring our provisioning orchestration
system.
Please comment, I want to be sure I am not missing something big here.

Provisioning as an aspect

Current state:

The Host object contains a lot of information about the
provisioning
procedure.
This information, once used when the host is provisioned is not used
by
other subsystems
in Foreman.

The provisioning is performed by different disjoint components
(orchestration classes)
that are using a priority mechanism to define the correct order in
which
each component
should run. As a cosequence, there is no way to know in what state
the
provisioning is.

The same provisioning system uses a non-persistent ActiveRecord
hooks
to tap into the work.

The proposal:

Create a separate object that will hold the information for the
provisioning.

Move the connection of a target to an aspect (concern). It will
make
possible to provision objects other than hosts, like NICs.

Each provision strategy will get its own class, each instance of
this
class will be the provisioning data of a single host.

Data models:
We are introducing two new objects to the system:

The provisioning relation object: This object is pretty simple - it’s
only responsibility is to connect the target to its provisioning.
Target model class name
Target ID
Provision strategy class name
Provision model ID
Provision state: New - in process - success - failure
State change timestamp

Provision instance state: The state saved by the selected strategy to
maintain the provisioning process. Each provision strategy will be able
to
save its own relevant state.
Examples for the provision strategies and their properties:
I will present a flat hierarchy, but it’s doesn’t (and won’t) be the
case -
strategies should inherit/use aspect concepts where it’s appropriate.

PXE provision
Provision interface: which interface should be used for provisioning
PXELinux template
Provision template
Finish template
Installation medium
iPXE provision
Provision interface: which interface should be used for provisioning
iPXELinux template
Provision template
Finish template
Installation medium

image-based provision
Provision interface
Image
Finish template

Advantages:

From user perspective:

No need to think about provisioning properties, if the host is not
provisioned

No need to think about properties that are not relevant for the
selected provision strategy

Better way to monitor the provision process (as long as the
strategy
is written the right way)

It would be possible to create a UI specific to each provisioning
system.

From developer perspective:

Cleaning up the Host object

Removing cross-concern dependency

Creating pluggable architecture for orchestrations - it will be
possible add another orchestrations via plugins

Creating a single object responsible for the orchestration process

no need to guess the dependencies
5. Moving the responsibilities of creating/modifying actual objects
(such as DNS records) to the models that describe them.
6. The ability to derive each property using a different strategy -
some
properties will be derived from the host/hostgroup hierarchy,
others (such as installation media) could be derived from the
organizations/locations hierarchy.

Backwards compatibility:
Since there are properties that are moved out of the host, it can break
extensions that were relying
on them. To handle it, a new concern will be created, that will delegate
all the relevant properties
to the orchestration subsystem with a deprecation warning.
The hooks plugin will be changed a bit to enable the old behavior

–
Marek

–
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.

–
Best Regards,

Stephen Benjamin
Red Hat Engineering

–
Marek

Marek_Hulan · March 16, 2015, 12:42pm

> > Hello
> >
> > We had a further discussion today about removing provision related objects
> > from host and hostgroup. I'll try to summarize outcomes and kindly ask for
> > inputs from others. All comments are welcome. I attached a quick diagram
> > illustrating the changes.
> >
> > Some entity names were changed so here's the mapping of previous names to
> > names used in the diagram:
> > Provisioning relation object -> Provisioning
> > Provisioning strategy -> Provisioning method
> > Provision instance state -> Provisioning snap
> >
> > We'd basically split Hostgroup into two parts. Everything related to
> > configuration would remain part of a Hostgroup (puppet classes, config
> > groups,
> > Environment) while the rest which is related to provision would be
> > extracted
> > to a new entity called ProvisionGroup (work name, suggestions
> > appreciated).
>
> os/provision profile ?

+1 for ProvisionProfile

>
> > When user build a new host he'd be able select one Hostgroup and one
> > ProvisionGroup. We'd also introduce a ProvisioningSnap which is a copy of
> > all
> > required foreign keys of provisioning data, based on selected
> > ProvisioningMethod. ProvisioningMethod may be something like PXE, Image
> > etc.
> > When we have a ProvisioningSnap and user selected a ProvisioningMethod, we
> > can
> > start Provisioning - this represents the actual act.
>
> The biggest difference between Hostgroup and ProvisionGroup (for me) is that
> > any change in Hostgroup associations are applied immediately (e.g. you
> > assign
> > new puppet class, it's part of ENC output) while changes in ProvisionGroup
> > do
> > affect only new provisionings. The pointers to the data are kept in
> > ProvisioningSnap so you can reprovision host in a same way it has been
> > provisioned before. If user changes the linked object, e.g. installation
> > medium URL, we can display a warning that there is a ProvisioningSnap that
> > refers to it, so the action would invalidate the snap. So users might add
> > new
> > object rather than editing existing one.
> >
> > when you split hostgroups, what happens to the host object? does it keeps
>
> all of the foreign keys in it (ptable_id, media_id etc) or rather it now
> refers to a provisioning snap?

I think these should be moved to ProvisioningSnap. If we need this in host, we
can delegate to last snap, but they should not be needed except backward
compatibility. Only exception I can think of is OperatingSystem that I think
should still be saved in host.

> > One small inconsistency in previous statement is that changes of puppet
> > parameter overrides assigned to OS would still apply immediately, even
> > though
> > the OS was originally assigned through ProvisionGroup. I think we should
> > keep
> > the OS association on Host object but keep the meaning of this
> > relationship
> > only relevant for configuration, not provisioning. I think this
> > relationship
> > is still useful on Foreman installations that are not used for
> > provisioning.
> > The other way would be, that we should only look at facts, but it does not
> > look right to me.
>
> right, that would cause inconsistency, see
> Bug #6006: OS facts should not overwrite the OS selected to provision with - Foreman

So I'd say we should keep both, not necessarily synchronized. If we don't have
OS in facts we can look at what was set by user.

> and there is an open question about when can some fields be edited, for
> example, do you want to allow to change the OS of a host in non build state?
> Feature #499: freeze certian host values after creation - Foreman

My feeling is that we should allow to change it as it's value that user want
to store there, he can always check facts for actual values.

> > One thing we didn't agree on is whether the ProvisioningSnap should
> > contain
> > all available data, or just those required for particular
> > ProvisioningMethod.
> > Opinions are again very welcome. Provisioning snap could sometimes contain
> > installation media (PXE based provisioning method) sometimes not (Image
> > based). Or we could always store all data such as installation medium,
> > even if
> > they are not required for currently selected provisioning method.
>
> whats the pro/con ?

Pros I see:
Same object interface everytime
Same snapshot can be used for reprovisioning with different strategy
The provisioning snap does not depend on provisioning method that would have
to somehow tell it which data it needs

Cons I see:
We store data that might not be needed and will never be used

Shimon could probably add more comments, obviously I see more pros, so I'm for
taking full snapshot.

···

On Monday 16 of March 2015 10:46:39 Ohad Levy wrote: > On Sun, Mar 15, 2015 at 6:37 PM, Marek Hulan wrote:

–
Marek

Thanks for your input.

–
Marek

On Tuesday 24 of February 2015 05:01:33 Shim Shtein wrote:

Here is a proposal for refactoring our provisioning orchestration
system.
Please comment, I want to be sure I am not missing something big here.

Provisioning as an aspect

Current state:

The Host object contains a lot of information about the

provisioning

procedure.
This information, once used when the host is provisioned is not used

by

other subsystems
in Foreman.
2. The provisioning is performed by different disjoint components
(orchestration classes)
that are using a priority mechanism to define the correct order in

which

each component
should run. As a cosequence, there is no way to know in what state
the
provisioning is.
3. The same provisioning system uses a non-persistent ActiveRecord

hooks

to tap into the work.

The proposal:

Create a separate object that will hold the information for the
provisioning.

Move the connection of a target to an aspect (concern). It will

make

possible to provision objects other than hosts, like NICs.
3. Each provision strategy will get its own class, each instance of

this

class will be the provisioning data of a single host.

Data models:
We are introducing two new objects to the system:

The provisioning relation object: This object is pretty simple - it’s
only responsibility is to connect the target to its provisioning.
Target model class name
Target ID
Provision strategy class name
Provision model ID
Provision state: New - in process - success - failure
State change timestamp

Provision instance state: The state saved by the selected strategy to
maintain the provisioning process. Each provision strategy will be able

to

save its own relevant state.
Examples for the provision strategies and their properties:
I will present a flat hierarchy, but it’s doesn’t (and won’t) be the

case -

strategies should inherit/use aspect concepts where it’s appropriate.

PXE provision
Provision interface: which interface should be used for provisioning
PXELinux template
Provision template
Finish template
Installation medium
iPXE provision
Provision interface: which interface should be used for provisioning
iPXELinux template
Provision template
Finish template
Installation medium

image-based provision
Provision interface
Image
Finish template

Advantages:

From user perspective:

No need to think about provisioning properties, if the host is not
provisioned

No need to think about properties that are not relevant for the
selected provision strategy

Better way to monitor the provision process (as long as the

strategy

is written the right way)
4. It would be possible to create a UI specific to each provisioning
system.

From developer perspective:

Cleaning up the Host object

Removing cross-concern dependency

Creating pluggable architecture for orchestrations - it will be
possible add another orchestrations via plugins

Creating a single object responsible for the orchestration process

no need to guess the dependencies
5. Moving the responsibilities of creating/modifying actual objects
(such as DNS records) to the models that describe them.
6. The ability to derive each property using a different strategy -

some

properties will be derived from the host/hostgroup hierarchy,
others (such as installation media) could be derived from the
organizations/locations hierarchy.

Backwards compatibility:
Since there are properties that are moved out of the host, it can break
extensions that were relying
on them. To handle it, a new concern will be created, that will delegate
all the relevant properties
to the orchestration subsystem with a deprecation warning.
The hooks plugin will be changed a bit to enable the old behavior

–
Marek

–
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.

–
Marek