> > The biggest concern seemed to be that we weren't sure whether Climate > makes sense as an independent project or not. We think it may make more > sense to integrate what Climate does today into Nova directly. More > generally, we think reservations of resources may best belong in the > APIs responsible for managing those resources, similar to how quota > management for resources lives in the resource APIs. > There is some expectation that this type of functionality will extend > beyond Nova, but for that we could look at creating a shared library of > code to ease implementing this sort of thing in each API that needs it.
Russel, sure. I guess we'll discuss that more carefully on summit, and I love see that feature implemented in the best way it should be done. I think in person discussion will help here much. I'm hoping to collect more feedback before summit to have multiple view on this problem. I truly agree with the fact that possibly users should not use a separate > API for reserving resources, but that would be worth duty for the project > itself (Nova, Cinder or even Heat). That said, we think that there is need > for having a global ordonancer managing resources and not siloing the > resources. Hence that's why we still think there is still a need for a > Climate Manager. > Once I said that, there are different ways to plug in with the Manager, > our proposal is to deliver a REST API and a python client so that there > could be still some operator access for managing the resources if needed. > The other way would be to only expose an RPC interface like the scheduler > does at the moment but as the move to Pecan/WSME is already close to be > done (reviews currently in progress), that's still a good opportunity for > leveraging the existing bits of code. Sylvain, I quite agree with you. -- Dina On Wed, Mar 12, 2014 at 8:14 PM, Sylvain Bauza <sylvain.ba...@gmail.com>wrote: > Hi Russell, > Thanks for replying, > > > 2014-03-12 16:46 GMT+01:00 Russell Bryant <rbry...@redhat.com>: > > On 03/12/2014 07:35 AM, Dina Belova wrote: >> > Thanks TC for spending time on Blazar (ex. Climate, in process of >> > renaming) discussion! >> > >> > It was decided that potentially reservation idea is interesting for OS >> > and it'll be great to have cross-project session on ongoing Atlanta >> > Summit and discuss future of reservation/scheduling management in >> OpenStack. >> > >> > Here is link to cross-project session proposal: >> > >> > http://summit.openstack.org/cfp/details/45 >> > >> > Thanks everyone and let's keep working on that idea. >> >> Yes, I do think it would be useful to discuss this in person. However, >> I don't think that was the most important feedback from the TC meeting. >> >> The biggest concern seemed to be that we weren't sure whether Climate >> makes sense as an independent project or not. We think it may make more >> sense to integrate what Climate does today into Nova directly. More >> generally, we think reservations of resources may best belong in the >> APIs responsible for managing those resources, similar to how quota >> management for resources lives in the resource APIs. >> >> There is some expectation that this type of functionality will extend >> beyond Nova, but for that we could look at creating a shared library of >> code to ease implementing this sort of thing in each API that needs it. >> > > > That's really a good question, so maybe I could give some feedback on how > we deal with the existing use-cases. > About the possible integration with Nova, that's already something we did > for the virtual instances use-case, thanks to an API extension responsible > for checking if a scheduler hint called 'reservation' was spent, and if so, > take use of the python-climateclient package to send a request to Climate. > > I truly agree with the fact that possibly users should not use a separate > API for reserving resources, but that would be worth duty for the project > itself (Nova, Cinder or even Heat). That said, we think that there is need > for having a global ordonancer managing resources and not siloing the > resources. Hence that's why we still think there is still a need for a > Climate Manager. > > Once I said that, there are different ways to plug in with the Manager, > our proposal is to deliver a REST API and a python client so that there > could be still some operator access for managing the resources if needed. > The other way would be to only expose an RPC interface like the scheduler > does at the moment but as the move to Pecan/WSME is already close to be > done (reviews currently in progress), that's still a good opportunity for > leveraging the existing bits of code. > > -Sylvain > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
