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

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.ba...@gmail.com<mailto:sylvain.ba...@gmail.com>> wrote:



2014-02-25 15:38 GMT+01:00 Dina Belova 
<dbel...@mirantis.com<mailto:dbel...@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@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

Reply via email to