Open Stack

+1000 to what Matt said.

Another point worth considering is that "operations"-type projects are
often in a fast-follow mode.  All of areas of interest (logging, packaging,
monitoring, etc.) are effectively out of band from anything OpenStack
proper.  We should be able to release these at our own cadence, and in
response to changes made in OpenStack projects as well as those in
third-party projects (Nagios, Sensu, ELK, etc).

This type of work is already happening in the Puppet and Chef projects
under Stackforge.  And, I am all for extending this work with additional
operations-focused Stackforge repos.

While it would be nice if this work was recognized with things like ATC
status, I really do not think that is the goal here.


On Sat, Nov 8, 2014 at 10:08 AM, Fischer, Matt <matthew.fischer at twcable.com>
wrote:

> On 11/8/14, 9:10 AM, "Jeremy Stanley" <fungi at yuggoth.org> wrote:
>
> >On 2014-11-07 22:25:49 +0100 (+0100), Jonathan Proulx wrote:
> >[...]
> >> An "Ops Project" feels weird to me.
> >[...]
> >
> >To me as well. Perhaps this is the "operator community" coming to
> >the realization that they don't need to be separate from the
> >"developer community." I've never really quite understood the
> >distinction myself... I spent pretty much all my career before now
> >as a sysadmin and network administrator, and I help write software
> >to automate systems/network administration tasks. I don't get why
> >some people feel it's necessary to grasp for a distinction between
> >those, and furthering that identity crisis merely underscores the
> >artificial dichotomy imposed by corporate management organization
> >charts.
>
> I come from a software development background, so in my mind, the idea of
> a this project has nothing to do with organizational, role, or job title
> distinctions, nor is it about having a PTL and ATCs. This is mainly about
> the fact that operators share the same set of challenges and tasks. We
> have realized that we¹re all spending a large part of our time repeating
> the same things and solving the same problems. Most of us are forced to be
> generalists trying to burn down our OpenStack deployment tech debt, when
> many would love to have some time to solve more interesting problems. If
> someone can share a package building solution, a set of Icinga scripts,
> and etc, it allows me to move on to something else with more focus and
> more value to my org.
>
> As of now, I don¹t really see a place for what we¹ve discussed on Friday
> in existing projects. Perhaps some of the code fits in some places as
> previously mentioned on the list, but the issue is that none of those
> projects really focus on operations. The projects are inevitably developer
> focused, despite the best attempts to get operator feedback.
>
> I also don¹t consider this a rush to incubation, just the start of a
> discussion. So let¹s keep it going.
>
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141108/b6ce8171/attachment.html>