On 02/24/2014 08:41 AM, Dina Belova wrote:
Cristian, hello

I believe that should not be done in such direct way, really.
Why not using project.extra field in DB to store this info? Is that not appropriate for your ideas or there will be problems with there implementing using extras?

It would not make sense to enforce on something that was not queryable directly in the database. Please don't use extra. I'd like to see it removed. It certainly should not be used for core behavior.

I think start/end datetimes make sense, and could be part of the project itself. Please write up the blueprint.

Thanks,
Dina


On Mon, Feb 24, 2014 at 5:25 PM, Sanchez, Cristian A <cristian.a.sanc...@intel.com <mailto:cristian.a.sanc...@intel.com>> wrote:

    Hi,
    I'm thinking about creating a blueprint to allow the creating of
    tenants defining start-date and end-date of that tenant. These
    dates will define a time window in which the tenant is considered
    'enabled' and auth tokens will be given only when current time is
    between those dates.
    This can be particularly useful for projects like Climate where
    resources are reserved. And any resource (like VMs) created for a
    tenant will have the same expiration dates as the tenant.

    Do you think this is something that can be added to Keystone?

    Thanks

    Cristian

    _______________________________________________
    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

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to