Hello Robert,

In the etherpad, I mention that any of the plugin calls (including the 
initiate_order() one) could result in the certificate being generated. 

As for handling the certificate order synchronously vs asynchronously however, 
we are striving to minimize the amount of 3rd party interaction required on the 
synchronous/API side to improve availability, deferring to the async worker 
processes to handle such traffic. 

So all orders resource requests are handled this way currently. IMHO, handling 
some orders synchronously would seem inconsistent and awkward, but perhaps a 
new resource (like 'quick_orders') could be introduced to handle such requests?


From: Clark, Robert Graham [robert.cl...@hp.com]
Sent: Thursday, July 17, 2014 5:52 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: barbi...@lists.rackspace.com List
Subject: Re: [openstack-dev] [barbican] Etherpad discussion related to ssl 
certificate workflow CR

We’ve been looking into CA’s that give you an instant response on a certificate 
signing request (based on various conditions) - I’m not sure that we can easily 
make this work with the state structures described?

Our basic flow is
Client —[https|somecreds|some <https://somecreds|some>csr]--> CA
Client <—[https|certificate/error400]—CA

The CA does a lot of stuff in the backend but for the purposes of this the 
decision about making the cert is instant, there’s no ‘queue’ to wait on. It’s 
not immediately clear to me if there’s some option to shortcut the states laid 
out to make a plugin work nicely with our prototype CA…


From: John Wood <john.w...@rackspace.com<mailto:john.w...@rackspace.com>>
Reply-To: OpenStack List 
Date: Thursday, 17 July 2014 15:37
To: OpenStack List 
Cc: "barbi...@lists.rackspace.com<mailto:barbi...@lists.rackspace.com>" 
Subject: [openstack-dev] [barbican] Etherpad discussion related to ssl 
certificate workflow CR

Hello folks,

Ade raised concerns about the approach taken in the SSL cert CR here: 

In short, he suggests that a state machine approach that gives plugins a lot of 
control over workflow is not needed, and could lead to plugin developers having 
more difficulty creating new plugins. I think he has valid points, so I created 
an etherpad that details a 'generic' workflow approach, and an approach that 
simplifies what the plugins need to do (offloading logic to Barbican): 

Please take a look at the etherpad and weigh in if you can.


OpenStack-dev mailing list

Reply via email to