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
