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" <rybr...@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....@pnnl.gov
<mailto:kevin....@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
