Date: Mon, 6 Feb 2017 17:42:01 +0000
From: Jeremy Stanley email@example.com
Subject: Re: [Openstack-operators] [LCOO] Intro to Large Contributing
OpenStack Operators working group
Content-Type: text/plain; charset="utf-8"
On 2017-02-03 21:50:25 +0000 (+0000), MCCABE, JAMEY A wrote:
The LCOO is a group of Multi-cloud Operators who are also
development contributors (read we have staff who are project
members and desire to jointly increase our participation in the
It's unclear to me what definition of "operators" is being used
there. As far as I'm aware our other working groups are made up of
individuals, not organizations, so are the individual members of
this group systems administrators who also write features and fixes
for the upstream OpenStack software as developers? Or are you saying
that you're sysadmins who have the ear of some particular upstream
developers? Or is it that you're mostly in nontechnical roles but
have close relationships with some sysadmins and upstream
Hi Jeremy. I'm the mysterious "AndyU" who was chatting with you about a year ago in IRC with questions about how to go about donating hosted cloud resources for use by the Infra team. It's nice to bump into you again! ;-) That idea is still stirring btw, but has been much slower moving than I'd hoped. I'm a member of LCOO and I co-chair our "Roadmap Team" along with Aditya Mani. I talked with Jamey McCabe and we agreed that I should respond to your questions.
I've been having a pretty lengthy conversation with jay Pipes regarding similar questions. You can catch up on that in the thread below this one.
LCOO is unlike any other working groups that I'm familiar with in some significant ways. You zero'd in on one of those in your statements above about companies joining as opposed to individuals. In that regard, LCOO is similar to an entity like OSIC.org as opposed to a traditional working group. A second way in which LCOO is similar to something like OSIC is that the member companies all have dedicated people contributing in the OpenStack Community. A third way is that each of the LCOO members agrees to commit some resources (theoretically at least; we haven't done anything like this yet) to collaborating together on common initiatives. However, in other ways LCOO is like a typical working group. For example, it's a forum for members to share information and raise awareness around pain points and priorities. One of the important things that we've been working towards and beginning to actively collaborate on shared priorities. LCOO is new in more ways than just that we've only existed for about 6 months. As I've noted, we're also a very different kind of working group altogether. That said, we've been gradually finding our feet and our identity. Part of that has been what we mean by "Large Operators". We've had discussions about that on and off and various points of view have found their way into wiki pages and such over time. At this point, I would say that perhaps we should have said large "Users" instead of large "Operators" as such. I think "Users" better characterizes the focus which is broader than ops/sysadmins. Also, the active members in LCOO range from people in largely non-technical more business oriented roles including executives, to very hands on highly technical people and in between. That said, we've been laying the groundwork to begin collaborating together more deeply. That collaboration could be thought of in different levels. For example:
1) Discussions and general information sharing.
2) Raising awareness about what each company is doing in the community and seeking feedback and support.
3) Mutually defining requirements and or coding on some work items.
4) Mutually taking on and driving a significant cross-project initiative of some kind (via the PWG's "Story" Process)
So far, we've done 1 and 2 and a little bit of 3. We're beginning to discuss making the jump to #4 (wile also increasing the others). There is no desire to do any of this in a vacuum. We are all community members and want to cooperate in the best possible way with all the other community members. The kinds of collaboration described above in some cases would involve pulling in various specialists from our companies and in other cases, the usual faces would handle it. But at the very least, our core of usual faces would coordinate things.
I'm interpreting it as the last one, but just want to be clear as to
the balance you're striking between direct involvement (implementing
what you need yourself) and indirection (compelling others, perhaps
in your employ, to implement what you need). The difference may seem
subtle, but it can have a significant impact on the amount of
influence you'll manifest or the degree to which your efforts might
be met with indifference and perhaps even resistance. Many coming
from large corporate environments are used to "top-down"
organization, while free software is very much a "bottom-up"
environment where those doing the work to implement fixes and new
features hold most of the community influence and are the ones who
ultimately need convincing.
I wholeheartedly agree. I think that the process the PWG has established strikes a good balance and that the framework we envision ourselves within should we take on any significant initiatives.
It assures that all stakeholders are engaged throughout.
We don?t' have prescriptive rules for who will join LCOO and
probably can't and really not looking to group our members that
tightly. Anyone who thinks they fit the pattern and looking to
join to help drive it along is welcome.
That's reassuring. https://wiki.openstack.org/wiki/LCOO#How_to_Join
is a bit hard to follow as, again, it seems to conflate people with
organizations. It implies that the individuals who make up the
working group are systems administrators and contributors to our
software, but then it says "with at least 4 FTEs" so are these FTEs
the actual working group members? Or someone "representing" those
engineers participates in working group meetings on their behalf?
In its current state, the document is also far more restrictive
about who is allowed to join than your comment above would seem to
indicate. Maybe it could use a bit of rewording.
Yes, that's confusing. It's really a company that is joining, or you could think of it as individuals when they join do so with the understanding that they are representing their company and there's an expectation around that. Also, it's expected that the company is committed to contributing to the community and to collaborating together with the other members. On that last point we're still working through discussions about just what that means for practical purposes. It's all evolving.
Under the Governance section, it even uses the phrase "member
companies" which is a concept I find strange and confusing in such
context. Companies are made up of individual people, and it's these
people who should be involved and accountable for their own opinions
and actions within the scope of a working group.
we've identified the Atlassian toolset (Confluence and
Jira) as promising tools to help us accomplish that upfront
process. It's pretty exciting and once we are running well we'll
be interested to share if other WG are interested. We are
following patterns we see at OPNFV and in OSIC
I'll refrain from restating the usual "free software needs free
tools" ideology here, but if you want to provide feedback to the
OpenStack community as to what the shortcomings were with the
available free tools we use it would be much appreciated. I also
find it interesting that you looked to OPNFV and OSIC instead of
OpenStack for patterns to follow; so again if you have any details
as to what was lacking in our community workflows and governance,
that might help us understand where to focus on improving so we can
better serve your needs in the future.
I discussed this at length in my thread with Jay Pipes below and others. It really comes down to this. We're not using Jira INSTEAD of any community tools. We're using it IN ADDITION TO the community tools. We plan to use it to assist with planning and status tracking. But all the actual work people are doing in the community would still be done in the usual community way using the normal community tools. Jira provides Kanban boards that can serve as a kind of dashboard allowing us to visualize activity and current status of Community activity. But that activity is still happening in Launchpad, Gerrit, etc. By basically equating a Story in Jira to a blueprint, we can copy a link to the related community activity (bp, commits, reviews, etherpads, etc.) into the jira story. The jira story has a simple lifecycle that steps through ideation > bp/spec > coding > commit/Review > Merged and done. When one of those milestones is reached in the community tools, the Story gets moved to the new status. That's the basic idea, and it's extremely helpful for streamlining the challenges of planning and status tracking, especially when rolled up across multiple stories/bp's and multiple projects. Automating the status updating is something I've begun to discuss within the PWG's "Story Tracker" team. We have the same challenge there. There's no plan at present to leverage Jira but it may offer a good solution, or we may prefer other options. Time will tell. It's really only a small sub-set of the community that has any need to or interest in this kind of portfolio-like planning/tracking in any case.
BTW, Atlassian has always made their tools free for use by open source projects. Also, although they're commercial products they do provide the source code and allow users to modify it freely which makes them much more open-source-ish than most. And another nice thing is that anyone can write app-like extensions for Jira and either distribute them freely or sell them via Atlassian's app store http://marketplace.atlassian.com. All functionality is exposed through API's and there are also command line tools. It's pretty easy to trigger scripts from events. All that adds up to it being a good candidate for building automation around and avoid trying to custom code Kanban boards, dashboards, etc. Full disclosure: I own some of their stock but I have made a dime. :-/
I hope that helps to clear things up and relieve any concerns :)
Date: Mon, 6 Feb 2017 13:19:18 -0500
From: Jay Pipes firstname.lastname@example.org
Subject: Re: [Openstack-operators] [openstack-dev] Large Contributing
OpenStack Operators working group?
Content-Type: text/plain; charset=utf-8; format=flowed
Thanks for the response, Andrew! Some replies inline.
On 02/03/2017 06:47 PM, UKASICK, ANDREW wrote:
It seems like I blinked and 10 more emails flew by since last night.
No worries, happens all the time :)
One of the difficulties for people like myself, and I think most of
the LCOO participants are like me, is that I have full-time internal
commitments with my employer that significantly limit the amount of
time I can spend on things like Community email list. Frankly, that's
at the heart of why we've been having conference calls when we
meeting and using Slack. We're just not able to be in IRC rooms
through the day like the people we have committed to full-time
community development work can.
Completely understand. That said, the advantage of IRC channels is that
they're logged and recorded automatically if managed under the OpenStack
infrastructure and therefore give you the benefit of auto-recording and
publishing the meeting minutes.
True. But actual verbal conversation I hard to beat. I think that if this LCOO idea really catches on, we'll end up with a mix of both. We'd probably continue to have our main meetings in the same format, but I could see sub-teams focused on different initiatives meeting independently and using IRC. Time will tell.
However, I do understand it can sometimes be difficult to follow IRC
conversations with lots of participants. Definitely has trade-offs.
From: Jay Pipes [mailto:email@example.com]
Sent: Friday, February 03, 2017 11:32 AM
To: UKASICK, ANDREW firstname.lastname@example.org >; Edgar Magana email@example.com >; firstname.lastname@example.org; email@example.com
Cc: MCCABE, JAMEY A firstname.lastname@example.org >
Subject: Re: [Openstack-operators] [openstack-dev] Large Contributing OpenStack Operators working group?
Hi Andy, thanks very much for your response. I appreciate it. Comments and questions inline.
On 02/02/2017 09:44 PM, UKASICK, ANDREW wrote:
It's already getting late here and I still have to do my farm chores
but I want to acknowledge your request. I think you've developed quite
a wrong impression of things and clearly some of that is on us because
in the early stages of forming the LCOO working group, we were all
still trying to find our feet and in an effort to just get started, we
wrote some things that in hind sight we would probably change today.
Our group has been maturing and evolving as we have been discussing
our shared purpose and also as a result of our collaboration with
other working groups. The UC, EWG and PWG are all represented in LCOO
and vice versa.
That is comforting to hear, thank you Andy. I am still curious what the LCOO's purpose is, though, in relation to those working groups and committees. Please forgive me for being thick-headed! I just don't understand whether the LCOO is intended to be a driver of contribution
within those existing working groups, or whether the LCOO is intended to be a separate driver of contribution that would pick efforts/blueprints/use cases from those existing working groups and have contributors work on those? Or is the idea to have LCOO be a sort of aggregator of use cases for Telcos and operate more as a status and roadmap tracking body? Or something else entirely?
Frankly, that's what we've been asking ourselves too from our first meeting. We had a "vision" of sorts, but none of us really knew if it was the right vision or how to make it work. At first we spent a lot of time just getting to know each other, sharing information, etc. One thing we definitely are is a forum in which large operators can discuss their challenges and share helpful information. For example, nearly all members are on old OpenStack releases like Juno, Kilo (or older). Upgrading is a HUGE pain point. New releases bring major improvements but we can't get to those releases. How do I deal with a challenge in Kilo is a different kind of discussion that how do I drive a desired enhancement in Pike or Queens. Most of us are not in purely technical roles in our companies. Many of us would perhaps better be described as product managers and also bring more of a business perspective.
But we wanted the group to do more. We did not want to just be self-serving. We wanted to make a real contribution to the Community. We've only been meeting for an hour (sometimes 2) a week so it has taken a few months for this to play out but I think we're finding our niche. We've been developing a close relationship with the Product Working Group and our LCOO group seems to be a great fit for helping to make their "Story Process" successful. Some of the Members like NTT and Intel have already been doing that. I guess the rest of us are finally catching up. Obviously, we need to take on "Stories" that resonate with the business needs of our various companies because without that we would not be able to draw out the technical resources to drive it. But that said, there are a lot of pain points and no shortage of business needs. I don't think anyone really cares where a need originally surfaced in the community or by whom. We have limited resources, but if the Story needs an owner and we have the means to take it on, it's a candidate. Beyond that it's a matter of prioritizing. We're only going to be discussing the first such story next week. It's all still evolving.
OK, that's interesting. Do you envision the LCOO essentially being a
"sponsorship group" and that the Product Working Group (and other
working groups like LDT, Telco/NFV WG, Enterprise WG, etc) being the
groups that create the specs and "sell" the use cases/ideas? In other
words, LCOO would be more of a group that gets together and agrees on a
set of higher-level objectives for telcos and works with the business
internal stakeholders to identify resources the company is willing to
contribute to a particular effort. But the spec-writing and use case
fleshing-out would still be done by the existing working groups?
Yes and no. If we're focused on something that another working group is actually working on, then I'd think the sensible thing to do would be to just join them and assist them in what they're doing. But if no one is working on it, then I'd think that we'd want to try and take the lead and drive it ourselves. But do so in a way that invites engagement from any other interested stakeholders.
Much of what you mention from the
Confluence site, which we've only been using for about a month, is I
think also being taken out of context. You called it "closed" but just
as you were able to quickly and easily create an account, get access,
and browse around, so can anyone else.
Sorry, when I said "closed" I meant that Atlassian products are not open-source. Atlassian owns the code and owns the content, which is why OpenStack teams don't use Jira and Confluence for work tracking.
AH! I misunderstood. You're right that Atlassian is not open-source, but let me say this for them, they're about as close as you can get and still be commercial. It doesn't seem to be well known, but Atlassian has long (always?) made their products available for free to open-source projects.
I actually don't equate open source with "no cost" :) A closed platform
is one which cannot be modified by the customer, which is something that
is important to our community. That said, hey I'm definitely familiar
with Jira and other Atlassian products. Mirantis uses them every day. I
just brought up point about being a closed platform because of the LCOO
wiki page's assertion about aligning with the OpenStack Foundation. Hope
That's probably why they're so widely used. They also give you a copy
of the complete source code and license to modify it without breaking
Oh? I was not aware of that. This would certainly change my mind about
using Atlassian products...
Furthermore JIRA, Confluence, etc, are built with a plugin
architecture that works so well that they have their own app store (the
Atlassian marketplace). It works like the apps for your phone. Anyone
can develop extensions and give them away for free or sell them through
the app store. Some will add truly major enhancements, major changes to
the gui etc., yet they can be deployed or upgraded live and in
production with a mouse click. I used to administer a 20,000 user
instance several years ago and it was already working that well back
then. They're also very extensible in other ways with very robust and
stable API's and command line tools through which virtually all
functionality is exposed. Events can be made to trigger scripts and so
forth. It's pretty nice. As you observed OPNFV uses it and so do many
OpenStack Community members including OSIC and your own Mirantis. I know
because I used to have an account in their JIRA instance. ;-)
Atlassian gave our LCOO group cloud instances of JIRA, JIRA Portfolio manager, Confluence, Confluence Questions (kinda like stack overflow), a really useful Calendar add-on and individual and group video chat (hip chat) for free with a 2,000 user license. They'd give us more tools as well, but we didn't need them. We're still not even using Hip Chat.
It's important to note that we only use JIRA for planning & tracking purposes. It does not take the place of any community tools. All dev work is done as usual. But people in more of a portfolio management type role often will use JIRA to create epics and stories. Then you have a story workflow that matches the community flow like BP > Spec > Committed > Merged. The story describes the work item and contains links to the related bits and pieces in Launchpad, gerrit, etherpads, etc. When a story goes from Committed to merged for example, the developer just drags it over to the Merged column in the JIRA Kanban board. Very simple and it meets a vital need. Using JIRA and building in automation to do all the tracking is a possibility we've been giving some thought to in the PWG Story Tracker sub-team. Don't know if that will be pursued or not.
Understood. This is a question/issue that we can have separately from
the "what's the purpose/plan of the LCOO compared to the existing
working groups" question that was really the heart of my initial email.
Consider this a full stop about the closed/open collaboration platform
question for this particular ML thread, cool? We can discuss that in a
followup email or thread so as to keep this thread focused on the
Works for me.
In fact you also had
the complete ability to create your own pages, read and comment on the
pages, edit or even delete the pages, put things on the calendar,
whatever. The pages work like etherpads allowing simultaneous editing
but with much more powerful tools and the convenience of a wiki
format. And hey, it was free. The site is completely open except for
one small section and that is explained if you stumbled across it.
Other working groups routinely put things in secured Google docs and
such. I don't think we're out of line but just this morning we
discussed ways to be more open. We were not publishing all our
meetings in the User Committee email list which was an oversight that
we're correcting. I'd encourage you to just reach out to us with any
questions or concerns before taking what certainly feels like a
confrontational posture in such a broadly public forum.
I recognize that I have a tendency to be ideological and rigid in certain of my viewpoints, and I am sorry to have offended. Please accept my apologies, Andy. I sincerely wish to see open and productive collaboration between contributors and users of OpenStack.
No offense taken! I tried to be on my best behavior but I know I snuck in a few subtle digs. Please accept my apologies as well. I feel the same way that you do.\
community members and we're exploring how best to make a significant,
positive contribution. That is what everyone wants to do.
Cheers to that.
I'm not a co-chair of LCOO, but I am a co-chair of a sub-team that we
recently formed to begin laying the groundwork for what we hope will
eventually become some significant contributions from a working group
perspective. I don't speak for the group, I'm just telling you my
opinion. First of all I cannot understand why the community would not
want to welcome people who want to contribute?
Two points here.
Firstly, I certainly do not represent the entire OpenStack community :) I am but one (sometimes blunt, certainly emotional, but often wrong) opinion out of many. Please don't equate my questions with the broader OpenStack community not being welcoming.
Secondly, I absolutely do want to welcome people who want to contribute! And I'm not just talking about development contributions. I value documentation, bug reporting, spec writing, use case development, architectural research, marketing and all sorts of other contributions.
My goal is not to put up walls to contribution. Instead, my goal is to ensure that the avenues by which the OpenStack community gathers contributions (of all forms) don't overlap, since such overlap inevitably leads to missed opportunities and duplicated efforts.
Understood. We want to be smart about this. We've been learning a lot (me especially since I probably started out as the most clueless one). The mistakes we've made are not for lack of desire to do our best; we're just learning.
A secondary goal of mine is to reduce bureaucracy in our governance and ensure that we have as unimpeded a pipeline as possible between the folks describing work that needs done, and the folks that are doing that work. Please take my questions as an effort to examine whether the additional process and structure of the LCOO is indeed warranted in order to accomplish the goals the LCOO member companies have.
Understood. One thing I've learned is that the UC and the working groups I've become involved with all want that as well. There have been a lot of challenges but I think they're all moving things in a very good direction. Solid, mutually beneficial partnerships between "the folks describing work that needs done, and the folks that are doing that work" (as you say) I think will really be the key.
Because the companies participating in LCOO are contributing on both
ends, I'm hopeful that we may be able to help with that.
Cool. Again, I sincerely hope to see a productive and efficient driver
of customer use cases in OpenStack (and the broader cloud ecosystem).
Just want to make sure things that overlap/duplicate are done so for a
specific reason and not because of a lack of knowledge about those
I agree. Of course, speaking for myself it's hard to know what I don't know! But we have members of the Product, Enterprise, Telco/NFV and LDT working groups and members of the User Committee all actively participating in LCOO. I know that people are keeping an eye on the Massively Dist Cloud group too. There are a lot of cross-connections that should help to avoid any redundant efforts. But again... we're still getting started. We haven't as the LCOO, contributed much of anything yet. Yes, the companies we represent have, but LCOO has not been the catalyst. However, I think that we're now finally poised to begin to take on some of these collaborative efforts and I hope that will steadily increase over time. We've been meeting weekly with good participation. That in itself seems to be kind of rare among many working groups and I take it as a good sign. ;-)
I don't think that we
deserve to be called about and have our right to exist challenged.
You all work alongside the companies that have come together under
LCOO every day. We're all community members. There is nothing
nefarious going on, no hidden agenda, no secret bid for power or any
other such thing.
Yes, I do work alongside the member companies of the LCOO every day. I'm close colleagues and friends with a number of folks in the LCOO.
However, I am not questioning anyone's right to existence. I am merely questioning whether the LCOO is set up in a way to ensure the success of its member companies' roadmaps.
Fair enough. Sorry I was getting defensive. It was late and I had not gotten any supper yet... makes me grumpy.
LOL, you and I share the hangry gene I see :)
There is no need for fear and anyone is welcome to
attend meetings, view agendas and minutes, comment on and add to them.
IMO, our identity could be best characterized as large operators whose
companies are also committed to being significant contributors to the
development effort. That brings some unique character to LCOO. We
wanted to avoid creating a forum where everyone comes with their
complaints, demands and wish lists. We wanted to create a group in
which everyone has real skin in the game. In which everyone is a
contributor. Our identity is also as USERS of openstack.
I think all of the above is awesome! That said, I don't think there are things about the existing OpenStack contributor ecosystem that have
prevented any of the LCOO member company's contributors from actively participating in the development of OpenStack projects. If there are things about the contributor ecosystem that have inhibited participation from Intel, Orange, AT&T, Reliance, NTT, etc, then let us address those issues directly. I personally would be pleased to have a discussion on those topics, as I'm sure the User Committee would as well.
Personally I was able to attend my first Summit in Austen. It was jaw dropping and awesome. I have always been a big fan and support of open-source from the start. I actually managed to get the first open-source tool approved as "Standard" at ATT years ago (CVS).
As a former AT&T employee, I understand just how much work that was! :)
Haha. Yes, your name still tops the charts for AT&T in Stackalytics too.
My experience with OpenStack has been nothing but positive in every
way. I LOVE the way that open-source empowers the little guy. I'm very
happy to have gotten the opportunity to become a part of this in my
professional life. It's ALL GOOD!
Another aspect of what we've been doing is providing a forum in which
participants can discuss the challenges they're experiencing from a
USER perspective. Share information, solutions, help one another. For
example we had some meetings where AT&T presented about Gluon which
you seem to have keyed in on. But the Gluon project is not being
managed from within LCOO meetings. Gluon is a project that AT&T
initiated, but as you saw, it's being managed separately. LCOO does
not have an OPNFV jira instance. We do have an LCOO Jira instance,
but we're still getting it ready to begin using it. You could have
jumped right into it when you were in our Confluence site. They're
integrated. We also dedicated many sessions to sharing what each
other is working on in the community. But none of that work has been
planned or driven from within LCOO thus far and that is not our
focus. We want to be aware of one another's efforts, offer feedback
and support, but LCOO is not the BORG. That said though, we are
hoping to take on a small number of efforts for the Community of the
nature I described earlier under the PWG Process linked above. I'm
optimistic that we may be able to do that in time to (if all goes
smoothly) see actual development underway in Queens. That's something
that we'll need JIRA for, to help with the planning and tracking
across the broad openstack portfolio. That's the same way that many
others in the community use JIRA, including OSIC who we recently had
meetings with to explore how they were using it.
Personally I resent having our right to form a working group like
this challenged at all. But I hope I've been able to lay some of your
concerns to rest. The bottom line is that we're all in this together.
Politics be damned, let's pull together and do all that we can to
make OpenStack as great as it can be and make the world a better
place along the way.
Trust me, politics was the last thing I had in mind when I wrote my
questions about the LCOO!
Here in the USA where I live, I find myself
rather disgusted with politics right now. Let's move forward.
You and me both, Andy. And I'm happy to move the conversation forward
with you, constructively.
Do you like beer? I DO! Let's meetup in Boston and get to know each other better. :-)
Yes, beer and me go way back. Let's definitely meet in person in Boston
(or sooner, depending on events)
You're on! See you there!
And if you can, please come and meet with our LCOO folks while you're there. We'll be on the schedule so you can find us.
That goes for everyone! ;-)
That would be great! :)
-Andy > >
From: Jay Pipes [mailto:email@example.com]
Sent: Thursday, February 02, 2017 7:23 PM
To: Edgar Magana firstname.lastname@example.org >; email@example.com; firstname.lastname@example.org
Cc: MCCABE, JAMEY A email@example.com >; UKASICK, ANDREW firstname.lastname@example.org >
Subject: Re: [Openstack-operators] [openstack-dev] Large Contributing OpenStack Operators working group?
On 02/02/2017 05:02 PM, Edgar Magana wrote:
I am including the WG chairs to make sure they answers your questions and addresses your concerns.
In Barcelona the UC asked exactly the same questions and recommended to the co-chairs of the LCOO WG to work with the existing WG to identify overlapping activities and either to work together or go ahead with the WG if there were not overlapping on goals and deliverables.
Was there any follow-on from that request from the UC?
I will let the co-chairs to follow up yours questions. BTW. I do not think this topic should be posted in the openstack-dev mailing list. So, I will BCC it.
Sure, no problem.
Andrew and Jamey,
Please, address these questions. Let?s work all together to make sure that we have all groups aligned and coordinated.
Thanks, Edgar, appreciated. Andrew and Jamey, please do let me know if you would like me to rephrase or elaborate on any questions. Happy to do so. I genuinely want to see alignment with other groups in this effort.
On 2/2/17, 12:14 PM, "Jay Pipes" email@example.com > wrote:
I was told about this group today. I have a few questions. Hopefully
someone from this team can illuminate me with some answers.
1) What is the purpose of this group? The wiki states that the team
"aims to define the use cases and identify and prioritise the
requirements which are needed to deploy, manage, and run services on top
of OpenStack. This work includes identifying functional gaps, creating
blueprints, submitting and reviewing patches to the relevant OpenStack
projects, contributing to working those items, tracking their completion."
What is the difference between the LCOO and the following existing
* Large Deployment Team
* Massively Distributed Team
* Product Working Group
* Telco/NFV Working Group
2) According to the wiki page, only companies that are "Multi-Cloud
Operator[s] and/or Network Service Provider[s]" are welcome in this
team. Why is the team called "Large Contributing OpenStack Operators" if
it's only for Telcos? Further, if this is truly only for Telcos, why
isn't the Telco/NFV working group appropriate?
3) Under the "Guiding principles" section of the above wiki, the top
principle is "Align with the OpenStack Foundation". If this is the case,
why did the group move its content to the closed Atlassian Confuence
platform? Why does the group have a set of separate Slack channels
instead of using the OpenStack mailing lists and IRC channels? Why is
the OPNFV Jira used for tracking work items for the LCOO agenda?
See https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openstack.org_wiki_Gluon_Tasks-2DOcata&d=DwICAg&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ&m=haOSpIhsa6KyDvuhRFigFVTLrTJxJ1Zv3kfm0JwTTtY&s=kntt00JEwpizTxQus4U9FhnwF_7WicJ7oRncGmkYPGc&e= for examples.
4) I see a lot of agenda items around projects like Gluon, Craton,
Watcher, and Blazar. I don't see any concrete ideas about talking with
the developers of the key infrastructure services that OpenStack is
built around. How does the LCOO plan on reaching out to the developers
of the long-standing OpenStack projects like Nova, Neutron, Cinder, and
Keystone to drive their shared agenda?
Thanks for reading and (hopefully) answering.
OpenStack Development Mailing List (not for usage questions)
OpenStack-operators mailing list
OpenStack-operators mailing list