Open Stack

I'm used to seeing 'provision' in the context of creating/configuring networking resources such as servers, which Barbican won't typically be doing for secret management (auto provisioning of SSL certs in the future notwithstanding). Also, a common practice with REST calls is to use the plural of resources in the URI...so 'provisions' in this case, which seems a bit awkward to me.

Thanks,
John

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



________________________________________
From: Bhandaru, Malini K [malini.k.bhandaru at intel.com]
Sent: Thursday, May 09, 2013 3:37 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [barbican] Other names for 'orders' resource (from 'CloudKeep API - Updates')

Smiles -- not particularly fond of "task" or workflow.
How about "provision" ? It is more like order but does not carry with it any overtimes of
Temporal or spacial ordering.
Malini

-----Original Message-----
From: John Wood [mailto:john.wood at RACKSPACE.COM]
Sent: Thursday, May 09, 2013 12:44 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [barbican] Other names for 'orders' resource (from 'CloudKeep API - Updates')

I like Jay's 'tasks' resource, to replace the current 'orders' resource....it fits well with the worker/tasks approach taken by the API now to process asynchronous requests.

If there are no objections, I say we rename the 'orders' resource to 'tasks'.

Thanks,
John

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



________________________________________
From: Jay Pipes [jaypipes at gmail.com]
Sent: Wednesday, May 08, 2013 8:20 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [barbican] CloudKeep API - Updates

On 05/07/2013 08:31 PM, John Wood wrote:
> Thanks for the input Nate.  Some comments below please:
>
> [
>> We propose changing from 'orders' to 'requests'...so to request that
>> Barbican create a new secret (or start a process to generate a
>> secret) clients would issue a 'request'. This seems more natural, and
>> a bit less overused than 'orders'.
>
> I think request sounds more overused than orders. I was not that
> thrilled with orders, but I do like it more than request. What about
> something like secretfactory, secretgenerator, or something else along
> those lines? I'm not too picky either way with whatever you pick.
> ]
>
> This interface will also be used to start the automated SSL cert generation process in the not too far off future. This will kick off a process that involves interacting with the CA to eventually generate an SSL cert, that will be stored in Barbican as a secret.
>
> This SSL cert generation process can be a long-running async process, so we were looking for terms that implied the secret generation would not necessary happen quickly, and instead have a state machine that could be long lived.  So 'order' probably fits this mode of operation the best.
>
> When I think of a 'factory' I'm expecting an instance to be created right then and there, which doesn't seem to fit the long-running nature of some secret creation processes.
>
> 'Request' is seem between these two modes to me, and maybe overused as you point out, esp. in the context of http interactions.
>
> So it seems 'orders' is more appropriate here.  Thoughts though?

Jobs or Tasks?

-jay

_______________________________________________
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

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