+1 to Dina on the workflow From: Dina Belova <dbel...@mirantis.com<mailto:dbel...@mirantis.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: martes, 25 de febrero de 2014 13:42 To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Climate] Lease by tenants feature design
Ok, so >>> I'm just asking why we should hack Keystone workflow by adding an hook, >>> like we did for Nova. From my POV, that's not worth it. Idea was about some extra specs, that will be processed by Climate anyway. Keystone will know nothing about reservations or smth. >>> I think it should be a Climate "policy" (be careful, the name is confusing) >>> : if admin wants to grant any new project for reservations, he should place >>> a call to Climate. That's up to Climate-Nova (ie. Nova extension) to query >>> Climate in order to see if project has been granted or not. Now I think that it'll be better, yes. I see some workflow like: 1) Mark project as reservable in Climate 2) When some resource is created (like Nova instance) it should be checked (in the API extensions, for example) via Climate if project is reservable. If is, and there is no special reservation flags passed, it should be used default_reservation stuff for this instance Sylvain, is that ira you're talking about? Dina On Tue, Feb 25, 2014 at 7:53 PM, Sylvain Bauza <sylvain.ba...@gmail.com<mailto:sylvain.ba...@gmail.com>> wrote: 2014-02-25 16:25 GMT+01:00 Dina Belova <dbel...@mirantis.com<mailto:dbel...@mirantis.com>>: Why should it require to be part of Keystone to hook up on Climate ? Sorry, can't get your point. I'm just asking why we should hack Keystone workflow by adding an hook, like we did for Nova. From my POV, that's not worth it. Provided we consider some projects as 'reservable', we could say this should be a Climate API endpoint like CRUD /project/ and up to the admin responsability to populate it. If we say that new projects should automatically be 'reservable', that's only policy from Climate to whiteboard these. So you propose to make some API requests to Climate (like for hosts) and mark some already existing projects as reserved. But how we'll automate process of some resource reservation belonging to that tenant? Or do you propose still to add some checkings to, for example, climate-nova extensions to check this somehow there? Thanks I think it should be a Climate "policy" (be careful, the name is confusing) : if admin wants to grant any new project for reservations, he should place a call to Climate. That's up to Climate-Nova (ie. Nova extension) to query Climate in order to see if project has been granted or not. Conceptually, this 'reservation' information is tied to Climate and should not be present within the projects. -Sylvain _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto: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
