[openstack-dev] [Climate] Lease by tenants feature design

Sanchez, Cristian A cristian.a.sanchez at intel.com
Tue Feb 25 17:35:39 UTC 2014


+1 to Dina on the workflow

From: Dina Belova <dbelova at mirantis.com<mailto:dbelova at mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: martes, 25 de febrero de 2014 13:42
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at 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.bauza at gmail.com<mailto:sylvain.bauza at gmail.com>> wrote:



2014-02-25 16:25 GMT+01:00 Dina Belova <dbelova at mirantis.com<mailto:dbelova at 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 at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.



More information about the OpenStack-dev mailing list