Open Stack

Le 17/11/2014 16:58, Jay Pipes a écrit :
> Good morning Stackers,
>
> At the summit in Paris, we put together a plan for work on the Nova 
> resource tracker and scheduler in the Kilo timeframe. A large number 
> of contributors across many companies are all working on this 
> particular part of the Nova code base, so it's important that we keep 
> coordinated and updated on the overall efforts. I'll work together 
> with Don Dugger this cycle to make sure we make steady, measured 
> progress. If you are involved in this effort, please do be sure to 
> attend the weekly scheduler IRC meetings [1] (Tuesdays @ 1500UTC on 
> #openstack-meeting).
>
> == Decisions from Summit ==
>
> The following decisions were made at the summit session [2]:
>
> 1) The patch series for virt CPU pinning [3] and huge page support [4] 
> shall not be approved until nova/virt/hardware.py is modified to use 
> nova.objects as its serialization/domain object model. Jay is 
> responsible for the conversion patches, and this patch series should 
> be fully proposed by end of this week.
>
> 2) We agreed on the concepts introduced by the resource-objects 
> blueprint [5], with a caveat that child object versioning be discussed 
> in greater depth with Jay, Paul, and Dan Smith.
>
> 3) We agreed on all concepts and implementation from the 2 
> isolate-scheduler-db blueprints: aggregates [6] and instance groups [7]
>

Well, this is no longer needed to implement [7] as a previous merge 
fixed the problem by moving the instance group setup to the conductor 
layer. I was on PTO while this spec was created so I had no time to say 
it was not necessary, my bad.

> 4) We agreed on implementation and need for separating compute node 
> object from the service object [8]
>
> 5) We agreed on concept and implementation for converting the request 
> spec from a dict to a versioned object [9] as well as converting 
> select_destinations() to use said object [10]
>
> [6] We agreed on the need for returning a proper object from the virt 
> driver's get_available_resource() method [11] but AFAICR, we did not 
> say that this object needed to use nova/objects because this is an 
> interface internal to the virt layer and resource tracker, and the 
> ComputeNode nova.object will handle the setting of resource-related 
> fields properly.
>
> [7] We agreed the unit tests for the resource tracker were, well, 
> crappy, and are a real source of pain in making changes to the 
> resource tracker itself. So, we resolved to fix them up in early Kilo-1
>
> [8] We are not interested in adding any additional functionality to 
> the scheduler outside already-agreed NUMA blueprint functionality in 
> Kilo. The goal is to get the scheduler fully independent of the Nova 
> database, and communicating with nova-conductor and nova-compute via 
> fully versioned interfaces by the end of Kilo, so that a split of the 
> scheduler can occur at the start of the L release cycle.
>
> == Action Items ==
>
> 1) Jay to propose patches that objectify the domain objects in 
> nova/virt/hardware.py by EOB November 21
>
> 2) Paul Murray, Jay, and Alexis Lee to work on refactoring of the unit 
> tests around the resource tracker in early Kilo-1
>
> 3) Dan Smith, Paul Murray, and Jay to discuss the issues with child 
> object versioning
>
> 4) Ed Leafe to work on separating the compute node from the service 
> object in Kilo-1
>

That's actually managed by my own, you can find both spec and 
implementation in the patch series, waiting for reviews [13]


> 5) Sylvain Bauza to work on the request spec and select_destinations() 
> to use request spec blueprints to be completed for Kilo-2
>
> 6) Paul Murray, Sylvain Bauza to work on the isolate-scheduler-db 
> aggregate and instance groups blueprints to be completed by Kilo-3
>
As said above, there is only one spec to validate ie. [6]

> 7) Jay to complete the resource-objects blueprint work by Kilo-2
>
> 8) Dan Berrange, Sahid, and Nikola Dipanov to work on completing the 
> CPU pinning, huge page support, and get_available_resources() 
> blueprints in Kilo-1
>
> == Open Items ==
>
> 1) We need to figure out who is working on the objectification of the 
> PCI tracker stuff (Yunjong maybe or Robert Li?)
>
> 2) The child object version thing needs to be thoroughly vetted. 
> Basically, the nova.objects.compute_node.ComputeNode object will have 
> a series of sub objects for resources (NUMA, PCI, other stuff) and 
> Paul Murray has some questions on how to handle the child object 
> versioning properly.
>
> 3) Need to coordinate with Steve Gordon, Adrian Hoban, and Ian Wells  
> on NUMA hardware in an external testing lab that the NFV subteam is 
> working on getting up and running [12]. We need functional tests 
> (Tempest+Nova) written for all NUMA-related functionality in the RT 
> and scheduler by end of Kilo-3, but have yet to divvy up the work to 
> make this a reality.
>
> == Conclusion ==
>
> Please everyone read the above thoroughly and respond if I have missed 
> anything or left anyone out of the conversation. Really appreciate 
> everyone coming together to get this work done over the next 4-5 months.
>
> Best,
> -jay
>
> [1] 
> https://wiki.openstack.org/wiki/Meetings#Gantt_.28Scheduler.29_team_meeting
> [2] https://etherpad.openstack.org/p/kilo-nova-scheduler-rt
> [3] https://review.openstack.org/#/c/129606/
> [4] https://review.openstack.org/#/c/129608/
> [5] https://review.openstack.org/#/c/127609/
> [6] https://review.openstack.org/#/c/89893/
> [7] https://review.openstack.org/#/c/131553/
> [8] https://review.openstack.org/#/c/126895/
> [9] https://review.openstack.org/#/c/127610/
> [10] https://review.openstack.org/#/c/127612/
> [11] https://review.openstack.org/#/c/133728/
> [12] 
> http://lists.openstack.org/pipermail/openstack-dev/2014-November/050306.html
>

[13] 
https://review.openstack.org/#/q/status:open+branch:master+topic:bp/detach-service-from-computenode,n,z
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev