Open Stack

Very exciting to see this happening. Structured state management is sorely
needed. I also like the plan of attack, tackling creation of an instance
first is a good way to feel this one out.

-Mike


On Fri, Apr 26, 2013 at 9:21 AM, Senhua Huang (senhuang) <senhuang at cisco.com
> wrote:

>  +1 on the great work on initiating the design and implementation of a
> more structured and "manageable" provision manager.
> +1 on the documentation.
>
>  Having a state management separated from resource selection is very
> helpful for group scheduling, cross compute/storage/network scheduling, as
> well as improved migration solution. It makes Nova more modular, easier to
> track and reasoning about errors, and easier to scale.
>
>  Thanks,
> Senhua
>
>   From: <Karajgi>, Rohit <Rohit.Karajgi at nttdata.com>
> Reply-To: OpenStack Development Mailing List <
> openstack-dev at lists.openstack.org>
> Date: Thursday, April 25, 2013 11:07 PM
> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
>
> Subject: Re: [openstack-dev] Nova workflow management update
>
>   +1x on the really well written plan and wikis.****
>
> ** **
>
> It just goes to show how important having a Structured State management is
> to Nova ****
>
> for making it highly reliable and resilient across all APIs.****
>
> ** **
>
> We would eventually want to see Nova become *Super*Nova!! J****
>
> ** **
>
> Regards,****
>
> Rohit****
>
> ** **
>
> ** **
>
> *From:* Adrian Otto [mailto:adrian.otto at rackspace.com<adrian.otto at rackspace.com>]
>
> *Sent:* Friday, April 26, 2013 9:28 AM
> *To:* OpenStack Development Mailing List
> *Cc:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] Nova workflow management update****
>
> ** **
>
> Joshua,****
>
> ** **
>
> I'm one of the Rackers helping to add development resources to Convection.
> I also work on the OASIS CAMP TC as an editor. I want to help create a
> reusable task system that helps Nova, Heat, and many other OpenStack
> projects. I am happy to see this progressing. The recent collaboration
> among the Nova and Heat/Convection teams is very encouraging. Thanks for
> all your efforts to form a sensible written plan.****
>
> ** **
>
> I'd like to take an editorial pass through the StructuredStateManagement
> wiki, and help tighten up the definitions a bit. Some wording changes may
> avoid some of the more overloaded technical terms (but there are
> practically no pure ones left). I'm planning to make a few edits to the
> wiki page (so there will be diffs), but if another approach is preferred,
> I'm open to that too. Please advise.****
>
> ** **
>
> Thanks,****
>
> ** **
>
> Adrian****
>
>
> On Apr 25, 2013, at 5:16 PM, "Joshua Harlow" <harlowja at yahoo-inc.com>
> wrote:****
>
>  Since I wanted to make sure everyone was aware of this, since some of
> you might have missed the summit session and I'd like discussions so we can
> land code in havana.****
>
> ** **
>
> For those that missed the session & associated material.****
>
> ** **
>
> - https://etherpad.openstack.org/the-future-of-orch (session details +
> discussion …)****
>
> ** **
>
> The summary of what I am trying to do is to move nova away from having
> ad-hoc tasks and move it toward having a central entity (not a single
> entity, but a central one, one that can be horizontally scalable) which can
> execute these tasks on-behalf of nova-compute. This central entity (a new
> orchestrator or conductor…) would centrally manage the workflow that nova
> goes through when completing an API request and would do so in a organized,
> controlled and resumable manner (it would also support rollbacks and
> more…). The reasons why what exists currently may not be optimal/good are
> listed in that etherpad, so I won't repeat them here.****
>
> ** **
>
> For example this is a possible diagram for the run_instance 'workflow'
> under this new scheme: http://imgur.com/sYOVz5X****
>
> ** **
>
> Nttdata and y! have been pursuing how to refactor this in a well thought
> out design, and even have prototype code @
> https://github.com/Yahoo/NovaOrc which has some of these changes (see the
> last 4-10 commits). The prototype was shown in the session but feel free to
> check out the code, if you setup with that code – its based on
> stable/grizzly, it should run (note that no external api changes occurred).
> ****
>
> ** **
>
> Some of the outcomes of that meeting I received that are relevant here:***
> *
>
> ** **
>
> - HEAT may have a convection library (WIP -
> https://wiki.openstack.org/wiki/Convection) that this workflow
> restructuring can use. ****
>
> --- Note: If this code is created quickly (creating a solid core) then it
> seems like we can use this code in nova itself and start restructuring nova
> into using this code. This of course then allows HEAT to use said library
> also, and nova as well (and likely creates future capabilities for
> something like http://aws.amazon.com/swf). The talk about this I think is
> just being started, but it seems like a solid core can be created in a week
> or two.****
>
> --- The documentation for my attempt at what I would like this central
> library to do where put @ https://etherpad.openstack.org/task-system (thx
> for the heat team for starting that pad)****
>
> - There was an ask to document more the overall design and how to
> accomplish it. I have started this @
> https://wiki.openstack.org/wiki/StructuredStateManagement (input is
> welcome) ****
>
> --- More details are at
> https://wiki.openstack.org/wiki/StructuredStateManagementDetails (WIP)
> since I didn't want to clutter the main page up…****
>
> --- Other thoughts of mine at
> http://lists.openstack.org/pipermail/openstack-dev/2013-April/007881.html (with
> other code associated with it)****
>
> - There was an ask on how conductor fits into this picture, this is still
> being worked out and discussed (thoughts welcome!)****
>
> - There was talk about how live migration/resizing can take advantage of
> such a workflow like system to become more secure (details on another email)
> ****
>
> --- This one involves planning, where imho i would like nova/heat groups
> to focus on this core library, and when adjusting the live migration/resize
> path they should use said core library. If not a core library then the
> prototype code I have created above (along with nttdata) can be altered to
> focus on those paths instead of the initial prototype path of
> 'run_instance'. ****
>
> - More blueprints – I have started a few @
> https://wiki.openstack.org/wiki/StructuredStateManagement#Blueprints ****
>
> - Make a plan on how to get this into mainline, started this @
> https://wiki.openstack.org/wiki/StructuredStateManagement#Plan_of_record *
> ***
>
> ** **
>
> Discussion is always welcome! I believe we can make this happen (and in
> all honesty *must* make it happen).****
>
> ** **
>
> I know there are others interested in this idea/solution, so if they want
> to chime in that would be wonderful :-)****
>
> ** **
>
> -Josh****
>
> ** **
>
>  _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev****
>
>
> ______________________________________________________________________
> Disclaimer:This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130426/d870c72d/attachment.html>