Open Stack

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

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
community)

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.

Tim


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
>>too.
>
>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
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev