Open Stack

Agreed that its going to be a hot area very soon, has there been any
designs/wikis/blueprints... on how nova-conductor could be altered to do
this kind of workflow tasks?

In its current usage, as a db-mq-proxy (which is useful) I don't currently
see how it can transform into something doing said orchestration/workflows
(especially with things like local-mode). Maybe u have thoughts there, I'd
like to hear them if possible so I can plan with them (instead of trying
to guess). 

Since I'm trying to form
https://wiki.openstack.org/wiki/StructuredStateManagement the conductor is
a part of my solution, but without knowing how its part of your/others
solution for the higher-level problem it makes it hard to understand where
it fits. Personally I see it as a very useful db-mq-proxy, one that the
orchestration entity will make 'virtual' resource requests on behalf of
vms 'to-be' (so it can remove said vms 'to-be' if something fails) which
works in the model of the db-mq-proxy design. But maybe u have different
ideas on where its going and could share them?

-Josh

On 4/25/13 1:19 PM, "Russell Bryant" <rbryant at redhat.com> wrote:

>On 04/25/2013 04:01 PM, Joshua Harlow wrote:
>> I just wanted to ensure that this doesn't get lost so am cc'ing others
>> for more details.
>> 
>> I remember in either the mothballing session or the host migrate session
>> that there was talk about how to do live migration and resizing in a way
>> that does not involve shared ssh keys.
>> 
>> I'd like to start a wiki at least to catch the ideas that were talked
>> about, since at y! its a big issue (we can't use live migration/resizing
>> if we have to allow unlimited hypervisor<->hypervisor connectivity). I
>> can go into the reasons as to why that is the case, if that¹s useful but
>> some of this was mentioned in one of those sessions.
>> 
>> I remember there being talk about possible solutions, something along
>> the lines of a external entity (orchestration/conductorŠ whatever)
>> creating a session key for said hypervisors, then allowing communication
>> between those hypervisors to perform said operation for a limited period
>> of time. That¹s one approach, said orchestration/conductor could also
>> open a secure tunnel and tell the hypervisors to use said channel (and
>> then said orchestration/conductor thingy could close that channel
>> automaticallyŠ) for communication.
>> 
>> This is a very interesting change, so more feedback is always welcome
>>:-)
>
>Yes, it is quite an important issue that we need to resolve.  You
>roughly captured the ideas discussed.  The next step is that someone
>needs to step up to document a design and implement it.
>
>However, this is a bit of a hot area of the code right now.  One of the
>things that I'm hoping will start early in the cycle is refactoring the
>code paths for migrate/live-migrate/resize/evacuate.  Much of the
>handling of all of these things can be shared in a single code path, but
>that's not the case right now.  Since this will be rather invasive, it
>needs to happen before other efforts in the same area, such as the one
>you're mentioning here.
>
>I think part of this refactoring will be pulling it up a layer to be
>more managed by nova-conductor, as opposed to compute nodes managing
>each other.  Once we have this refactoring in place, fixing this
>security issue will become much easier to do.
>
>-- 
>Russell Bryant
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev