[openstack-dev] [Zaqar] Call for adoption (or exclusion?)

Tim Bell Tim.Bell at cern.ch
Tue Apr 21 18:58:09 UTC 2015

This touches on many of the aspects of the Ops tagging to be discussed in

What are the criteria for

- An operator to consider a PoC for a new function ? We look for RDO
packaging, Puppet configuration and ops/end user documentation.
- An operator offering function to their end users in test (I.e. This
works well enough to see if there is an end user benefit to justify the
operations cost) ?
- An operator to offer this in production (I.e. The operator deploys the
code and makes it available to the end users) ? This implies scaling,
upgradability, etc. and commits to a sustainable roadmap (with the

I really appreciate the reflections going on here since the worst case
scenario for us is that the end users of the cloud become dependent on a
component and finding that the community is not self sustaining.

Tagging allows the operator to make an informed decision given their user
community and assess the risk vs benefit.


On 4/21/15, 2:51 PM, "Ryan Brown" <rybrown at redhat.com> wrote:

>On 04/20/2015 07:12 PM, Steve Baker wrote:
>> On 21/04/15 11:01, Angus Salkeld wrote:
>>> On Tue, Apr 21, 2015 at 8:38 AM, Fox, Kevin M <Kevin.Fox at pnnl.gov
>>> <mailto:Kevin.Fox at pnnl.gov>> wrote:
>>>     As an Op, a few things that come to mind in that category are:
>>>      * RDO packaging (stated earlier). If its not easy to install, its
>>>     not going to be deployed as much. I haven't installed it yet,
>>>     because I haven't had time to do much other then yum install it...
>>>      * Horizon UI
>>>      * Heat Resources. (Some basic stuff like create/delete queue to
>>>     go along with the stack. also link #1 below)
>>> Here you go:
>>> https://github.com/openstack/heat/tree/master/contrib/heat_zaqar
>> One thing we need to do in Vancouver is come up with criteria for moving
>> resources from contrib into the main tree. Previously this was whether
>> the project was integrated. As a starter I would suggest something like:
>> 1. project is in the openstack git namespace
>> 2. the client library is synced with global-requirements.txt
>> 3. the resources are complete enough to be useful in template authoring
>> We need to think about potential for integration testing in the gate
>I think scenario/functional tests should be table stakes to graduate a
>resource from contrib/ .
>>>     Horizon has a discovery aspect to it. If users don't know a
>>>     service is available, its hard for them to use it. Even with the
>>>     most simple UI of Create/Delete/List queues, discovery is handled.
>Absolutely agreed. Especially in a service like Zaqar where the vast
>majority of usage isn't by humans in a web interface, the horizon bit
>becomes mostly a dashboard/auditing/testing destination instead of a
>primary interface.
>>> [snip]
>Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list