Open Stack

On 22/04/15 06:58, Tim Bell wrote:
> 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.
>
Agreed, and I've just proposed a cross-project track session to discuss 
how user-facing projects like OpenStackClient, Horizon and Heat can 
define and assign tags for the services they support.

>
>
> 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
>
> __________________________________________________________________________
> 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