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