You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltacloud.apache.org by Carl Trieloff <cc...@redhat.com> on 2010/12/17 15:22:52 UTC
Initial boot / post boot Matahari cloud agent and Deltacloud interactions
Based on some discussion I have worked up an additional agent with ted (some
input on qmfv2) for Matahari to be able to generically deal with
injecting configuration
into an instance in a public or private cloud.
I'm interested in this so that we use a generic boot image and then
provide a
piece of CDL 'Content discription Language' and specialize this generic
image
to represent my application deployment.
The generic mechanism does not type the configuration for CDL, anything from
foobar to CDL to Puppet Script could be passed. First I'll discribe the
mechanics
and then I'll discussed the requirement from this which I have on
DeltaCloud API.
I've implemented a mechanism that can be used/ deployed in one of the
following ways.
a.) Federated, using an instance in the cloud as a rendezvous point,
With explicit instance
selection. Does not require inbound connections to source
b.) Federated or non Federated without an instance in the cloud, With
explicit instance
selection.. Requires in-bound connections to source
c.) I have also created non explicit instance selection / for the above
two deployment
patterns.
Let me explain the details of each:
The flow of events in (a & b) are as follows.
Setup:
- Instantiate a cache on-premise, or in my service.
- Start one or more instances in the cloud (EC2) for example as a local
cache proxy.
- Federate the two caches
(b) skips the last two steps...
Operation
- On Instance start request provide
- a config uuid
- the CDL / configuration for the node for post boot.
- a secrete & the IP of cache is auto prefilled
- This function does two things
1.) Start the instance passing uuid:IP:secrete as a boot
param to the image for the post boot daemon.
2.) Calls pre_register() on the cache with
- uuid
- CDL
- secrete.
- The instance now starts, and the Manatahi config daemon takes the IP,
connects to
the rendezvous point looks up the pre_registered object from the cache
and downloads
the CDL/ conf.
- After configuring itself and completing the boot, it then calls
update_cache() passing the
uuid, secrete, para_map, ip and status.
- The origin service can now retrieve the IP of the booted node, any
param it set from the map
and the instance status.
- It is also possible to provide updates of config/ CDL to the running
instance if required.
(These two deployment options require that a boot string be passed into
the cloud with the
following information uuid:IP:secrete ) via the Delta cloud API. The
DeltaCloud API does
not need to care about the format, rather just pass a small string onto
the instance.
.....................
For flow (c). interface is build however the implementation is not fully
coded as I don't think
the use case is so strong.
In this case, we don't want to pass anything to the cloud via the API,
or the cloud does not
support that and we need another option (eg GoGrid)
In this case, the booting instance has no uuid. The IP's of the
rendezvous points need to be
included in the starter image.
The flow is as follows.
- call pre_register on the cache, but mark the cache element as dynamic
- start instance in cloud
- instance in cloud contacts rendezvous point
- The cache will now hand out the uuid and config to the booting
instances on a first come
first serve basis.
- The instance then updates the cache info as before.
- It is possible to have dynamic and non dynamic elements in the cache
at the same time
This flow requires nothing to be passed via the deltacloudAPI (or the
cloud does not support it),
it also means however that it is not really possible to map differing
machine profiles to specific
configurations unless artificial constraints are used like building a
different starter image for
each profile of machine and tagging the starter image.
Personally I prefer the flow of (a & b) but thought I would provide both.
It is implemented with QMF from the Qpid project. I will post the patch
of the initial implementation
to the Matahari list.
Here is the schema for the service:
<!-- boot config /config & param registory-->
<class name="Config">
<property name="uuid" type="sstr" access="RO" desc="Host UUID"
index="y" />
<property name="config_xml" type="lstr" access="RO" desc="Host
configuration XML" />
<property name="my_conf_addr" type="sstr" access="RW" desc="Address for
this machine config" />
<property name="status" type="sstr" access="RW" desc="Status of
Instance" />
<property name="parameter_map" type="map" access="RW" desc="Host
configuration metadata" />
<property name="config_hosts" type="list" access="RW" desc="List of my
Configuration hosts" />
<property name="dymanic" type="bool" access="RO" desc="Dynamically
assign this instance" />
</class>
<class name="ConfigHelper">
<method name="pre_register" desc="Associate a configuration with a
UUID">
<arg name="uuid" dir="I" type="sstr" />
<arg name="config_xml" dir="I" type="lstr" />
<arg name="domain" dir="I" type="sstr" />
</method>
<method name="update_cache" desc="Update the instance fields in the cache">
<arg name="uuid" dir="I" type="sstr" />
<arg name="my_conf_addr" dir="I" type="sstr" />
<arg name="parameter_map" dir="I" type="map" />
<arg name="status" dir="I" type="sstr" />
<arg name="trust_key" dir="I" type="sstr" />
</method>
<method name="remove" desc="Delate configuartion for UUID">
<arg name="uuid" dir="I" type="sstr" />
</method>
<method name="remove_stale" desc="Delate stale configuartions">
<arg name="timeout" dir="I" type="uint32" />
<arg name="removed" dir="O" type="uint32" />
</method>
<method name="assign_dynamic" desc="Assign dynamic instance">
<arg name="uuid" dir="O" type="sstr" />
</method>
</class>
Re: Initial boot / post boot Matahari cloud agent and Deltacloud
interactions
Posted by David Lutterkort <lu...@redhat.com>.
On Fri, 2010-12-17 at 09:22 -0500, Carl Trieloff wrote:
> (These two deployment options require that a boot string be passed into
> the cloud with the
> following information uuid:IP:secrete ) via the Delta cloud API. The
> DeltaCloud API does
> not need to care about the format, rather just pass a small string onto
> the instance.
For EC2, we already support passing in user data (which winds up on the
special internal web server that EC2 provides at 169.254.169.254) For
Rackspace, we need to add including filenames and contents for those
files in the create instance request. If there are other clouds that
support data injection that are not covered by these two mechanisms, I'd
like to hear about it.
You'll also need some (fairly simple) script to extract that information
regardless of the cloud that you include with your instances. That
script will have to know exactly how the information is passed in, even
though Deltacloud doesn't care.
David
Re: Initial boot / post boot Matahari cloud agent and Deltacloud
interactions
Posted by Carl Trieloff <cc...@redhat.com>.
Copied both lists, as FYI for deltacloud to serve as use case for
passing small
opaque data to an instance being requested to be started.
Carl.
On 12/17/2010 12:11 PM, Benjamin Browning wrote:
> This is the first time I've seen anything about Matahari come up on the Deltacloud list. Was this sent to the wrong list or is there some prior conversation about Matahari and Deltacloud that I'm missing?
>
> Ben
>
> On Dec 17, 2010, at 9:22 AM, Carl Trieloff wrote:
>
>> Based on some discussion I have worked up an additional agent with ted (some
>> input on qmfv2) for Matahari to be able to generically deal with injecting configuration
>> into an instance in a public or private cloud.
>>
>> I'm interested in this so that we use a generic boot image and then provide a
>> piece of CDL 'Content discription Language' and specialize this generic image
>> to represent my application deployment.
>>
>> The generic mechanism does not type the configuration for CDL, anything from
>> foobar to CDL to Puppet Script could be passed. First I'll discribe the mechanics
>> and then I'll discussed the requirement from this which I have on DeltaCloud API.
>>
>>
>> I've implemented a mechanism that can be used/ deployed in one of the following ways.
>>
>> a.) Federated, using an instance in the cloud as a rendezvous point, With explicit instance
>> selection. Does not require inbound connections to source
>> b.) Federated or non Federated without an instance in the cloud, With explicit instance
>> selection.. Requires in-bound connections to source
>> c.) I have also created non explicit instance selection / for the above two deployment
>> patterns.
>>
>>
>> Let me explain the details of each:
>>
>> The flow of events in (a& b) are as follows.
>>
>> Setup:
>> - Instantiate a cache on-premise, or in my service.
>> - Start one or more instances in the cloud (EC2) for example as a local cache proxy.
>> - Federate the two caches
>> (b) skips the last two steps...
>>
>> Operation
>> - On Instance start request provide
>> - a config uuid
>> - the CDL / configuration for the node for post boot.
>> - a secrete& the IP of cache is auto prefilled
>> - This function does two things
>> 1.) Start the instance passing uuid:IP:secrete as a boot param to the image for the post boot daemon.
>> 2.) Calls pre_register() on the cache with
>> - uuid
>> - CDL
>> - secrete.
>>
>> - The instance now starts, and the Manatahi config daemon takes the IP, connects to
>> the rendezvous point looks up the pre_registered object from the cache and downloads
>> the CDL/ conf.
>>
>> - After configuring itself and completing the boot, it then calls update_cache() passing the
>> uuid, secrete, para_map, ip and status.
>>
>> - The origin service can now retrieve the IP of the booted node, any param it set from the map
>> and the instance status.
>>
>> - It is also possible to provide updates of config/ CDL to the running instance if required.
>>
>> (These two deployment options require that a boot string be passed into the cloud with the
>> following information uuid:IP:secrete ) via the Delta cloud API. The DeltaCloud API does
>> not need to care about the format, rather just pass a small string onto the instance.
>>
>> .....................
>>
>> For flow (c). interface is build however the implementation is not fully coded as I don't think
>> the use case is so strong.
>>
>> In this case, we don't want to pass anything to the cloud via the API, or the cloud does not
>> support that and we need another option (eg GoGrid)
>>
>> In this case, the booting instance has no uuid. The IP's of the rendezvous points need to be
>> included in the starter image.
>>
>> The flow is as follows.
>> - call pre_register on the cache, but mark the cache element as dynamic
>> - start instance in cloud
>> - instance in cloud contacts rendezvous point
>> - The cache will now hand out the uuid and config to the booting instances on a first come
>> first serve basis.
>> - The instance then updates the cache info as before.
>>
>> - It is possible to have dynamic and non dynamic elements in the cache at the same time
>>
>> This flow requires nothing to be passed via the deltacloudAPI (or the cloud does not support it),
>> it also means however that it is not really possible to map differing machine profiles to specific
>> configurations unless artificial constraints are used like building a different starter image for
>> each profile of machine and tagging the starter image.
>>
>>
>>
>> Personally I prefer the flow of (a& b) but thought I would provide both.
>>
>>
>> It is implemented with QMF from the Qpid project. I will post the patch of the initial implementation
>> to the Matahari list.
>>
>> Here is the schema for the service:
>>
>> <!-- boot config /config& param registory-->
>> <class name="Config">
>> <property name="uuid" type="sstr" access="RO" desc="Host UUID" index="y" />
>> <property name="config_xml" type="lstr" access="RO" desc="Host configuration XML" />
>> <property name="my_conf_addr" type="sstr" access="RW" desc="Address for this machine config" />
>> <property name="status" type="sstr" access="RW" desc="Status of Instance" />
>> <property name="parameter_map" type="map" access="RW" desc="Host configuration metadata" />
>> <property name="config_hosts" type="list" access="RW" desc="List of my Configuration hosts" />
>> <property name="dymanic" type="bool" access="RO" desc="Dynamically assign this instance" />
>> </class>
>>
>> <class name="ConfigHelper">
>> <method name="pre_register" desc="Associate a configuration with a UUID">
>> <arg name="uuid" dir="I" type="sstr" />
>> <arg name="config_xml" dir="I" type="lstr" />
>> <arg name="domain" dir="I" type="sstr" />
>> </method>
>>
>> <method name="update_cache" desc="Update the instance fields in the cache">
>> <arg name="uuid" dir="I" type="sstr" />
>> <arg name="my_conf_addr" dir="I" type="sstr" />
>> <arg name="parameter_map" dir="I" type="map" />
>> <arg name="status" dir="I" type="sstr" />
>> <arg name="trust_key" dir="I" type="sstr" />
>> </method>
>>
>> <method name="remove" desc="Delate configuartion for UUID">
>> <arg name="uuid" dir="I" type="sstr" />
>> </method>
>>
>> <method name="remove_stale" desc="Delate stale configuartions">
>> <arg name="timeout" dir="I" type="uint32" />
>> <arg name="removed" dir="O" type="uint32" />
>> </method>
>>
>> <method name="assign_dynamic" desc="Assign dynamic instance">
>> <arg name="uuid" dir="O" type="sstr" />
>> </method>
>>
>> </class>
>>
>>
>>
Re: Initial boot / post boot Matahari cloud agent and Deltacloud interactions
Posted by Benjamin Browning <bb...@redhat.com>.
This is the first time I've seen anything about Matahari come up on the Deltacloud list. Was this sent to the wrong list or is there some prior conversation about Matahari and Deltacloud that I'm missing?
Ben
On Dec 17, 2010, at 9:22 AM, Carl Trieloff wrote:
>
> Based on some discussion I have worked up an additional agent with ted (some
> input on qmfv2) for Matahari to be able to generically deal with injecting configuration
> into an instance in a public or private cloud.
>
> I'm interested in this so that we use a generic boot image and then provide a
> piece of CDL 'Content discription Language' and specialize this generic image
> to represent my application deployment.
>
> The generic mechanism does not type the configuration for CDL, anything from
> foobar to CDL to Puppet Script could be passed. First I'll discribe the mechanics
> and then I'll discussed the requirement from this which I have on DeltaCloud API.
>
>
> I've implemented a mechanism that can be used/ deployed in one of the following ways.
>
> a.) Federated, using an instance in the cloud as a rendezvous point, With explicit instance
> selection. Does not require inbound connections to source
> b.) Federated or non Federated without an instance in the cloud, With explicit instance
> selection.. Requires in-bound connections to source
> c.) I have also created non explicit instance selection / for the above two deployment
> patterns.
>
>
> Let me explain the details of each:
>
> The flow of events in (a & b) are as follows.
>
> Setup:
> - Instantiate a cache on-premise, or in my service.
> - Start one or more instances in the cloud (EC2) for example as a local cache proxy.
> - Federate the two caches
> (b) skips the last two steps...
>
> Operation
> - On Instance start request provide
> - a config uuid
> - the CDL / configuration for the node for post boot.
> - a secrete & the IP of cache is auto prefilled
> - This function does two things
> 1.) Start the instance passing uuid:IP:secrete as a boot param to the image for the post boot daemon.
> 2.) Calls pre_register() on the cache with
> - uuid
> - CDL
> - secrete.
>
> - The instance now starts, and the Manatahi config daemon takes the IP, connects to
> the rendezvous point looks up the pre_registered object from the cache and downloads
> the CDL/ conf.
>
> - After configuring itself and completing the boot, it then calls update_cache() passing the
> uuid, secrete, para_map, ip and status.
>
> - The origin service can now retrieve the IP of the booted node, any param it set from the map
> and the instance status.
>
> - It is also possible to provide updates of config/ CDL to the running instance if required.
>
> (These two deployment options require that a boot string be passed into the cloud with the
> following information uuid:IP:secrete ) via the Delta cloud API. The DeltaCloud API does
> not need to care about the format, rather just pass a small string onto the instance.
>
> .....................
>
> For flow (c). interface is build however the implementation is not fully coded as I don't think
> the use case is so strong.
>
> In this case, we don't want to pass anything to the cloud via the API, or the cloud does not
> support that and we need another option (eg GoGrid)
>
> In this case, the booting instance has no uuid. The IP's of the rendezvous points need to be
> included in the starter image.
>
> The flow is as follows.
> - call pre_register on the cache, but mark the cache element as dynamic
> - start instance in cloud
> - instance in cloud contacts rendezvous point
> - The cache will now hand out the uuid and config to the booting instances on a first come
> first serve basis.
> - The instance then updates the cache info as before.
>
> - It is possible to have dynamic and non dynamic elements in the cache at the same time
>
> This flow requires nothing to be passed via the deltacloudAPI (or the cloud does not support it),
> it also means however that it is not really possible to map differing machine profiles to specific
> configurations unless artificial constraints are used like building a different starter image for
> each profile of machine and tagging the starter image.
>
>
>
> Personally I prefer the flow of (a & b) but thought I would provide both.
>
>
> It is implemented with QMF from the Qpid project. I will post the patch of the initial implementation
> to the Matahari list.
>
> Here is the schema for the service:
>
> <!-- boot config /config & param registory-->
> <class name="Config">
> <property name="uuid" type="sstr" access="RO" desc="Host UUID" index="y" />
> <property name="config_xml" type="lstr" access="RO" desc="Host configuration XML" />
> <property name="my_conf_addr" type="sstr" access="RW" desc="Address for this machine config" />
> <property name="status" type="sstr" access="RW" desc="Status of Instance" />
> <property name="parameter_map" type="map" access="RW" desc="Host configuration metadata" />
> <property name="config_hosts" type="list" access="RW" desc="List of my Configuration hosts" />
> <property name="dymanic" type="bool" access="RO" desc="Dynamically assign this instance" />
> </class>
>
> <class name="ConfigHelper">
> <method name="pre_register" desc="Associate a configuration with a UUID">
> <arg name="uuid" dir="I" type="sstr" />
> <arg name="config_xml" dir="I" type="lstr" />
> <arg name="domain" dir="I" type="sstr" />
> </method>
>
> <method name="update_cache" desc="Update the instance fields in the cache">
> <arg name="uuid" dir="I" type="sstr" />
> <arg name="my_conf_addr" dir="I" type="sstr" />
> <arg name="parameter_map" dir="I" type="map" />
> <arg name="status" dir="I" type="sstr" />
> <arg name="trust_key" dir="I" type="sstr" />
> </method>
>
> <method name="remove" desc="Delate configuartion for UUID">
> <arg name="uuid" dir="I" type="sstr" />
> </method>
>
> <method name="remove_stale" desc="Delate stale configuartions">
> <arg name="timeout" dir="I" type="uint32" />
> <arg name="removed" dir="O" type="uint32" />
> </method>
>
> <method name="assign_dynamic" desc="Assign dynamic instance">
> <arg name="uuid" dir="O" type="sstr" />
> </method>
>
> </class>
>
>
>
Re: Initial boot / post boot Matahari cloud agent and Deltacloud
interactions
Posted by Dmitri Pal <dp...@redhat.com>.
Carl Trieloff wrote:
> On 12/17/2010 11:29 AM, Dmitri Pal wrote:
>> I hope you are not planning to build everything around OAuth.
>>
>
> no, just on the identification back to the cache element. It is not a
> substitute for kerb, just a second safety on the cache update.
>
> Carl.
If it is not a substitution the identifier should be a kerberos
principal name and secret should be an OTP.
The kerberos will provide authentication and the identifier will be used
in the policy decisions by cache server.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
Re: Initial boot / post boot Matahari cloud agent and Deltacloud
interactions
Posted by Carl Trieloff <cc...@redhat.com>.
On 12/17/2010 11:29 AM, Dmitri Pal wrote:
> I hope you are not planning to build everything around OAuth.
>
no, just on the identification back to the cache element. It is not a
substitute for kerb, just a second safety on the cache update.
Carl.
Re: Initial boot / post boot Matahari cloud agent and Deltacloud
interactions
Posted by Dmitri Pal <dp...@redhat.com>.
Carl Trieloff wrote:
> On 12/17/2010 09:57 AM, Dmitri Pal wrote:
>
>> > On the a) and b) cases the sequence will probably eventually be more
>> > complex. The secret passed on the image launch will be used to
>> identify
>> > the system and authenticate to the rendezvous point. I see it bing an
>> > OTP that would allow the machine to acquire keytab and authenticate
>> > against the cloud infrastructure auth server (IPA). This
>> authentication
>> > in turn would allow Matahari to connect and get CDL. I do not
>> think it
>> > is wise to allow anyone to get CDL without authentication but for the
>> > proto the simplified approach will do. I also think that it makes
>> sense
>> > to run a special instance of IPA for the VMs in the publick cloud to
>> > have a better separation of duties between the IPA that will serve
>> the
>> > bootstraping of the VMs in the public cloud and the IPA that will be
>> > serving identities for the cloud infrastructure. The CDL
>> downloaded by
>> > Matahari will have another secret that would allow the machine to
>> get on
>> > the VPN and connect to the corporate environment. At this moment
>> > Matahari will reinitialize itself and connect to the internal
>> > infrastructure . We can also add some VPN remediation work later
>> on to
>> > handle patching and security audit of the machine connecting to the
>> > network but this can be viewed as a separate task and can be
>> deferred.
> Multiple levels of security can be configured here. First we can
> secure the
> communication and the domain, with AMQP. The reason for the secrete
> is to prevent someone compromising one machine and updating the
> status of the remote cache. This way they only have w access to one item
> in the cache based on the secrete. Following OAuth 2 way that bk
> forwarded
> to me.
I hope you are not planning to build everything around OAuth.
>
> I believe securing the initial channel needs some discussion, as there
> are a
> few options but I see that separate but related to this process.
>
>
>
>> > As for c) I really think we should just ask the cloud vendor to
>> fix the
>> > interface to allow passing data to the image at launch time. By
>> the time
>> > we are ready they might already fix it. Not having a way to pass
>> > information at launch time is the limitation that not only us
>> would be
>> > complaining about. For a time being we can create a different starter
>> > image dynamically by seeding it with appropriate information but I do
>> > not think we should spend a lot of time trying to solve this use
>> case.
>> > Have we already logged an RFE with GoGrid?
> Agree, that is why I stopped on the impl of this option.
>
> Carl.
>
>
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
Re: Initial boot / post boot Matahari cloud agent and Deltacloud
interactions
Posted by Carl Trieloff <cc...@redhat.com>.
On 12/17/2010 09:57 AM, Dmitri Pal wrote:
> > On the a) and b) cases the sequence will probably eventually be more
> > complex. The secret passed on the image launch will be used to identify
> > the system and authenticate to the rendezvous point. I see it bing an
> > OTP that would allow the machine to acquire keytab and authenticate
> > against the cloud infrastructure auth server (IPA). This authentication
> > in turn would allow Matahari to connect and get CDL. I do not think it
> > is wise to allow anyone to get CDL without authentication but for the
> > proto the simplified approach will do. I also think that it makes sense
> > to run a special instance of IPA for the VMs in the publick cloud to
> > have a better separation of duties between the IPA that will serve the
> > bootstraping of the VMs in the public cloud and the IPA that will be
> > serving identities for the cloud infrastructure. The CDL downloaded by
> > Matahari will have another secret that would allow the machine to get on
> > the VPN and connect to the corporate environment. At this moment
> > Matahari will reinitialize itself and connect to the internal
> > infrastructure . We can also add some VPN remediation work later on to
> > handle patching and security audit of the machine connecting to the
> > network but this can be viewed as a separate task and can be deferred.
Multiple levels of security can be configured here. First we can secure the
communication and the domain, with AMQP. The reason for the secrete
is to prevent someone compromising one machine and updating the
status of the remote cache. This way they only have w access to one item
in the cache based on the secrete. Following OAuth 2 way that bk forwarded
to me.
I believe securing the initial channel needs some discussion, as there
are a
few options but I see that separate but related to this process.
> > As for c) I really think we should just ask the cloud vendor to fix the
> > interface to allow passing data to the image at launch time. By the time
> > we are ready they might already fix it. Not having a way to pass
> > information at launch time is the limitation that not only us would be
> > complaining about. For a time being we can create a different starter
> > image dynamically by seeding it with appropriate information but I do
> > not think we should spend a lot of time trying to solve this use case.
> > Have we already logged an RFE with GoGrid?
Agree, that is why I stopped on the impl of this option.
Carl.
Re: Initial boot / post boot Matahari cloud agent and Deltacloud
interactions
Posted by Dmitri Pal <dp...@redhat.com>.
Carl Trieloff wrote:
>
> Based on some discussion I have worked up an additional agent with ted
> (some
> input on qmfv2) for Matahari to be able to generically deal with
> injecting configuration
> into an instance in a public or private cloud.
>
> I'm interested in this so that we use a generic boot image and then
> provide a
> piece of CDL 'Content discription Language' and specialize this
> generic image
> to represent my application deployment.
>
> The generic mechanism does not type the configuration for CDL,
> anything from
> foobar to CDL to Puppet Script could be passed. First I'll discribe
> the mechanics
> and then I'll discussed the requirement from this which I have on
> DeltaCloud API.
>
>
> I've implemented a mechanism that can be used/ deployed in one of the
> following ways.
>
> a.) Federated, using an instance in the cloud as a rendezvous point,
> With explicit instance
> selection. Does not require inbound connections to source
> b.) Federated or non Federated without an instance in the cloud, With
> explicit instance
> selection.. Requires in-bound connections to source
> c.) I have also created non explicit instance selection / for the
> above two deployment
> patterns.
>
>
> Let me explain the details of each:
>
> The flow of events in (a & b) are as follows.
>
> Setup:
> - Instantiate a cache on-premise, or in my service.
> - Start one or more instances in the cloud (EC2) for example as a
> local cache proxy.
> - Federate the two caches
> (b) skips the last two steps...
>
> Operation
> - On Instance start request provide
> - a config uuid
> - the CDL / configuration for the node for post boot.
> - a secrete & the IP of cache is auto prefilled
> - This function does two things
> 1.) Start the instance passing uuid:IP:secrete as a boot
> param to the image for the post boot daemon.
> 2.) Calls pre_register() on the cache with
> - uuid
> - CDL
> - secrete.
>
> - The instance now starts, and the Manatahi config daemon takes the
> IP, connects to
> the rendezvous point looks up the pre_registered object from the cache
> and downloads
> the CDL/ conf.
>
> - After configuring itself and completing the boot, it then calls
> update_cache() passing the
> uuid, secrete, para_map, ip and status.
>
> - The origin service can now retrieve the IP of the booted node, any
> param it set from the map
> and the instance status.
>
> - It is also possible to provide updates of config/ CDL to the running
> instance if required.
>
> (These two deployment options require that a boot string be passed
> into the cloud with the
> following information uuid:IP:secrete ) via the Delta cloud API. The
> DeltaCloud API does
> not need to care about the format, rather just pass a small string
> onto the instance.
>
> .....................
>
> For flow (c). interface is build however the implementation is not
> fully coded as I don't think
> the use case is so strong.
>
> In this case, we don't want to pass anything to the cloud via the API,
> or the cloud does not
> support that and we need another option (eg GoGrid)
>
> In this case, the booting instance has no uuid. The IP's of the
> rendezvous points need to be
> included in the starter image.
>
> The flow is as follows.
> - call pre_register on the cache, but mark the cache element as dynamic
> - start instance in cloud
> - instance in cloud contacts rendezvous point
> - The cache will now hand out the uuid and config to the booting
> instances on a first come
> first serve basis.
> - The instance then updates the cache info as before.
>
> - It is possible to have dynamic and non dynamic elements in the cache
> at the same time
>
> This flow requires nothing to be passed via the deltacloudAPI (or the
> cloud does not support it),
> it also means however that it is not really possible to map differing
> machine profiles to specific
> configurations unless artificial constraints are used like building a
> different starter image for
> each profile of machine and tagging the starter image.
>
>
>
> Personally I prefer the flow of (a & b) but thought I would provide both.
>
>
> It is implemented with QMF from the Qpid project. I will post the
> patch of the initial implementation
> to the Matahari list.
>
> Here is the schema for the service:
>
> <!-- boot config /config & param registory-->
> <class name="Config">
> <property name="uuid" type="sstr" access="RO" desc="Host
> UUID" index="y" />
> <property name="config_xml" type="lstr" access="RO" desc="Host
> configuration XML" />
> <property name="my_conf_addr" type="sstr" access="RW" desc="Address
> for this machine config" />
> <property name="status" type="sstr" access="RW" desc="Status of
> Instance" />
> <property name="parameter_map" type="map" access="RW" desc="Host
> configuration metadata" />
> <property name="config_hosts" type="list" access="RW" desc="List of
> my Configuration hosts" />
> <property name="dymanic" type="bool" access="RO"
> desc="Dynamically assign this instance" />
> </class>
>
> <class name="ConfigHelper">
> <method name="pre_register" desc="Associate a configuration with
> a UUID">
> <arg name="uuid" dir="I" type="sstr" />
> <arg name="config_xml" dir="I" type="lstr" />
> <arg name="domain" dir="I" type="sstr" />
> </method>
>
> <method name="update_cache" desc="Update the instance fields in the
> cache">
> <arg name="uuid" dir="I" type="sstr" />
> <arg name="my_conf_addr" dir="I" type="sstr" />
> <arg name="parameter_map" dir="I" type="map" />
> <arg name="status" dir="I" type="sstr" />
> <arg name="trust_key" dir="I" type="sstr" />
> </method>
>
> <method name="remove" desc="Delate configuartion for UUID">
> <arg name="uuid" dir="I" type="sstr" />
> </method>
>
> <method name="remove_stale" desc="Delate stale configuartions">
> <arg name="timeout" dir="I" type="uint32" />
> <arg name="removed" dir="O" type="uint32" />
> </method>
>
> <method name="assign_dynamic" desc="Assign dynamic instance">
> <arg name="uuid" dir="O" type="sstr" />
> </method>
>
> </class>
>
>
>
On the a) and b) cases the sequence will probably eventually be more
complex. The secret passed on the image launch will be used to identify
the system and authenticate to the rendezvous point. I see it bing an
OTP that would allow the machine to acquire keytab and authenticate
against the cloud infrastructure auth server (IPA). This authentication
in turn would allow Matahari to connect and get CDL. I do not think it
is wise to allow anyone to get CDL without authentication but for the
proto the simplified approach will do. I also think that it makes sense
to run a special instance of IPA for the VMs in the publick cloud to
have a better separation of duties between the IPA that will serve the
bootstraping of the VMs in the public cloud and the IPA that will be
serving identities for the cloud infrastructure. The CDL downloaded by
Matahari will have another secret that would allow the machine to get on
the VPN and connect to the corporate environment. At this moment
Matahari will reinitialize itself and connect to the internal
infrastructure . We can also add some VPN remediation work later on to
handle patching and security audit of the machine connecting to the
network but this can be viewed as a separate task and can be deferred.
As for c) I really think we should just ask the cloud vendor to fix the
interface to allow passing data to the image at launch time. By the time
we are ready they might already fix it. Not having a way to pass
information at launch time is the limitation that not only us would be
complaining about. For a time being we can create a different starter
image dynamically by seeding it with appropriate information but I do
not think we should spend a lot of time trying to solve this use case.
Have we already logged an RFE with GoGrid?
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/