Open Stack

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?

I guess that even with this approach, the reservation creation process will still check for the existence of ‘lease’ information in the project, and create the lease accordingly.


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 12:25
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

Why should it require to be part of Keystone to hook up on Climate ?

Sorry, can't get your point.

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


On Tue, Feb 25, 2014 at 6:48 PM, Sylvain Bauza <sylvain.bauza at gmail.com<mailto:sylvain.bauza at gmail.com>> wrote:



2014-02-25 15:38 GMT+01:00 Dina Belova <dbelova at mirantis.com<mailto:dbelova at mirantis.com>>:

I guess that's simple and that's why nice solution for this problem.

So you propose to implement that feature in following way:
1) mark project as 'reservable' during its creation in extras specs
2) add some more logic to reservable resources creation/reservation. Like adding one more checking in instance creation request. Currently we're checking hints in request, you propose to check project extra info and if project is 'reservable' you'll use smth like default_reservation stuff for instances

Although it looks ok (because of no changes to Keystone/Nova/etc. core code), I have some question about this solution:
- info about project should be given only to admins, really. But all these VMs will be booted by simple users, am I right? In this case you'll have no possibility to get info about project and to process checking.

Do you have some ideas about how to solve this problem?

Dina



Why should it require to be part of Keystone to hook up on Climate ?
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.

Provided a VM is booted by a single end-user, that would still be Climate's responsability to verify that the user's tenant has been previously granted.

-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.