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
