Open Stack

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



On Tue, Feb 25, 2014 at 6:22 PM, Martinez, Christian <
christian.martinez at intel.com> wrote:

> Yeah.. That could be a good approach.
> Just add some extra info to the tenant creation.. Then, on climate nova,
> when a resource is created, check by the tenant id if that tenant has a
> "lease param" (or smth like that). If it does, then act accordingly..
> Is that make sense? Dina, Sylvain ??
>
>
> -----Original Message-----
> From: Sanchez, Cristian A [mailto:cristian.a.sanchez at intel.com]
> Sent: Thursday, February 20, 2014 4:19 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Climate] Lease by tenants feature design
>
> I agree with Bauza that the main purpose of Climate is to reserve
> resources, and in the case of keystone it should reserve tenant, users,
> domains, etc.
>
> So, it could be possible that climate is not the module in which the
> tenant "lease" information should be saved. As stated in the use case, the
> only purpose of this BP is to allow the creation of tenants with start and
> end dates. Then when creating resources in that tenant (like VMs) climate
> could take "lease" information from the tenant itself and create actual
> leases for the VMs.
>
> Any thoughts of this?
>
> From: Sylvain Bauza <sylvain.bauza at gmail.com<mailto:
> sylvain.bauza at gmail.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: jueves, 20 de febrero de 2014 15:57
> 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
>
>
>
>
> 2014-02-20 19:32 GMT+01:00 Dina Belova <dbelova at mirantis.com<mailto:
> dbelova at mirantis.com>>:
> Sylvain, as I understand in BP description, Christian is about not exactly
> reserving tenants itself like we actually do with VMs/hosts - it's just
> naming for that. I think he is about two moments:
>
> 1) mark some tenants as "needed to be reserved" - speaking about resources
> assigned to it
> 2) reserve these resources via Climate (VMs for first approximation)
>
>
> Well, I understood your BP, that's Christian's message which was a bit
> misunderstanding.
> Speaking of marking a tenant as "reserved" would then mean that it does
> have kind of priority vs. another tenant. But again, at said, how could you
> ensure at the marking (ie. at lease creation) that Climate can honor
> contracts with resources that haven't been explicitely defined ?
>
> I suppose Christian is speaking now about hacking tenants creation process
> to mark them as "needed to be reserved" (1st step).
>
>
> Again, a lease is mutually and exclusively linked with explicit resources.
> If you say "create a lease, for the love" without speaking of what, I don't
> see the interest in Climate, unless I missed something obvious.
>
> -Sylvain
> Christian, correct me if I'm wrong, please Waiting for your comments
>
>
> On Thu, Feb 20, 2014 at 10:06 PM, Sylvain Bauza <sylvain.bauza at gmail.com
> <mailto:sylvain.bauza at gmail.com>> wrote:
> Hi Christian,
>
> 2014-02-20 18:10 GMT+01:00 Martinez, Christian <
> christian.martinez at intel.com<mailto:christian.martinez at intel.com>>:
>
> Hello all,
> I'm working in the following BP:
> https://blueprints.launchpad.net/climate/+spec/tenant-reservation-concept,
> in which the idea is to have the possibility to create "special" tenants
> that have a lease for all of its associated resources.
>
> The BP is in discussing phase and we were having conversations on IRC
> about what approach should we follow.
>
>
> Before speaking about implementation,  I would definitely know the
> usecases you want to design.
> What kind of resources do you want to provision using Climate ? The basic
> thing is, what is the rationale thinking about hooking tenant creation ?
> Could you please be more explicit ?
>
> At the tenant creation, Climate wouldn't have no information in terms of
> calculating the resources asked, because the resources wouldn't have been
> allocated before. So, generating a lease on top of this would be like a
> non-formal contract in between Climate and the user, accounting nothing.
>
> The main reason behind Climate is to provide SLAs for either user requests
> or projects requests, meaning that's duty of Climate to guarantee that the
> desired associated resource with the lease will be created in the future.
> Speaking of Keystone, the Keystone objects are tenants, users or domains.
> In that case, if Climate would be hooking Keystone, that would say that
> Climate ensures that the cloud will have enough capacity for creating these
> resources in the future.
>
> IMHO, that's not worth implementing it.
>
>
> First of all, we need to add some "parameters or flags" during the tenant
> creation so we can know that the associated resources need to have a lease.
> Does anyone know if Keystone has similar functionality to Nova in relation
> with Hooks/API extensions (something like the stuff mentioned on
> http://docs.openstack.org/developer/nova/devref/hooks.html ) ? My first
> idea is to intercept the tenant creation call (as it's being done with
> climate-nova) and use that information to associate a lease quota to the
> resources assigned to that tenant.
>
>
> Keystone has no way to know which resources are associated within a
> tenant, see how the middleware authentication is done here [1] Regarding
> the BP, the motivation is to possibly 'leasify' all the VMs from one single
> tenant. IIRC, that should still be duty of Nova to handle that workflow and
> send the requests to Climate.
>
> -Sylvain
>
> [1] :
> http://docs.openstack.org/developer/keystone/middlewarearchitecture.html
>
>
>
> _______________________________________________
> 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.
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140225/c025c953/attachment.html>