Open Stack

On Wed, 2019-02-20 at 10:24 -0500, Mohammed Naser wrote:
> Hi Chris,
> 
> Thanks for kicking this off.  I've added my replies in-line.
> 
> Thank you for your past term as well.
> 
> Regards,
> Mohammed
> 
> On Wed, Feb 20, 2019 at 9:49 AM Chris Dent <cdent+os at anticdent.org> wrote:
> > 
> > 
> > It's the Campaigning slot of the TC election process, where members
> > of the community (including the candidates) are encouraged to ask
> > the candidates questions and witness some debate. I have some
> > questions.
> > 
> > First off, I'd like to thank all the candidates for running and
> > being willing to commit some of their time. I'd also like to that
> > group as a whole for being large enough to force an election. A
> > representative body that is not the result of an election would not
> > be very representing nor have much of a mandate.
> > 
> > The questions follow. Don't feel obliged to answer all of these. The
> > point here is to inspire some conversation that flows to many
> > places. I hope other people will ask in the areas I've chosen to
> > skip. If you have a lot to say, it might make sense to create a
> > different message for each response. Beware, you might be judged on
> > your email etiquette and attention to good email technique!
> > 
> > * How do you account for the low number of candidates? Do you
> >    consider this a problem? Why or why not?
> 
> Just for context, I wanted to share the following numbers to formulate my
> response:
> 
> Ocata candidates: 21
> Pike candidates: 14
> Queens candidates: 16
> Rocky candidates: 10
> 
> We're indeed seeing the numbers grow cycle over cycle.  However, a lot
> of the candidates are people that most seem to have ran once and upon
> not being elected, they didn't take a chance to go again.  I think perhaps we
> should encourage reaching out to those previous candidates, especially those
> who are still parts of the community still to nominate themselves again.
> 
> I do however think that with the fact that our software is becoming more stable
> and having less overall contributors than before, it might be a good time to
> evaluate the size of the TC, but that could be a really interesting challenge
> to deal with and I'm not quite so sure yet about how we can approach that.
> 
> I don't think it's a problem, we had a really quiet start but then a
> lot of people
> put their names in.  I think if the first candidate had come in a bit
> earlier, we
> would have seen more candidates because I get this feeling no one wants to
> go "first".
> 
> > * Compare and contrast the role of the TC now to 4 years ago. If you
> >    weren't around 4 years ago, comment on the changes you've seen
> >    over the time you have been around. In either case: What do you
> >    think the TC role should be now?
> 
> 4 years ago, we were probably around the Kilo release cycle at that
> time and things were a lot different in the ecosystem.  At the time, I think
> the TC had more of a role of governing as the projects had plenty of
> traction and things were moving.
> 
> As OpenStack seems to come closer to delivering most of the value
> that you need, without needing as much effort, I think it's important
> for us to try and envision how we can better place OpenStack in the
> overall infrastructure ecosystem and focus on marketing it.
> 
> I speak a lot to users and deployers daily and I find out a lot of things
> about current impressions of OpenStack, once I explain it to them,
> they are all super impressed by it so I think we need to do a better job
> at educating people.
> 
> Also, I think the APAC region is one that is a big growing user and
> community of OpenStack that we usually don't put as much thought
> into.  We need to make sure that we invest more time into the community
> there.
> 
> > * What, to you, is the single most important thing the OpenStack
> >    community needs to do to ensure that packagers, deployers, and
> >    hobbyist users of OpenStack are willing to consistently upstream
> >    their fixes and have a positive experience when they do? What is
> >    the TC's role in helping make that "important thing" happen?
> 
> I think our tooling is hard to use.  I really love it, but it's really not
> straightforward for most new comers.
> 
> The majority of users are familiar with the GitHub workflow, the
> Gerrit one is definitely one that needs a bit of a learning curve. I think
> this introduces a really weird situation where if I'm not familiar with
> all of that and I want to submit a patch that's a simple change, it will
> take me more work to get setup on Gerrit than it does to make the
> fix.
> 
> I think most people give up and just don't want to bother at that point,
> perhaps a few more might be more inclined to get through it but it's
> really a lot of work to allow pushing a simple patch.
> 
> > * If you had a magic wand and could inspire and make a single
> >    sweeping architectural or software change across the services,
> >    what would it be? For now, ignore legacy or upgrade concerns.
> >    What role should the TC have in inspiring and driving such
> >    changes?
> 
> Oh.
> 
> - Stop using RabbitMQ as an RPC, it's the worst most painful component
>   to run in an entire OpenStack deployment.  It's always broken.  Switch
>   into something that uses HTTP + service registration to find endpoints.
    as an on looker i have mixed feeling about this statement.
    RabbitMQ can have issue at scale but it morstly works when its not on fire.
    Would you be advocating building a openstack specific RPC layer perhaps
    using keystone as the service registry and a custom http mechanism or adopting
    an existing technology like grpc?

    investigating an alternative RPC backend has come up in the past (zeromq and qupid)
    and i think it has merit but im not sure as a comunity creating a new RPC framework is
    a project wide effort that openstack need to solve. that said zaqar is a thing
    https://docs.openstack.org/zaqar/latest/ if it is good enough for our endusers to consume
    perhaps it would be up to the task of being openstack rpc transport layer.
   
    anyway my main question was would you advocate adoption of an exisiting technology
    or creating our own solution if we were to work on this goal as a community.

> 
> - Use Keystone as an authoritative service catalog, stop having to configure
>    URLs for services inside configuration files.  It's confusing and unreliable
>   and causes a lot of breakages often.
> 
> - SSL first.  For most services, the overhead is so small, I don't see why we
>   wouldn't ever have all services to run SSL only.
> 
> - Single unified client, we're already moving towards this with the OpenStack
>   client but it's probably been one of our biggest weaknesses that have not
>   been completed and fully cleared out.
> 
> Those are a few that come to mind right now, I'm sure I could come up with
> so much more.
> 
> > * What can the TC do to make sure that the community (in its many
> >    dimensions) is informed of and engaged in the discussions and
> >    decisions of the TC?
> 
> We need to follow the mailing lists and keep up to date at what users are
> trying to use OpenStack for.  There's emerging use cases such as using it
> for edge deployments, the increase of bare-metal deployments (ironic) and
> thinking about how it can benefit end users, all of this can be seen by
> following mailing list discussions, Twitter-verse, and other avenues.
> 
> I've also found amazing value in being part of WeChat communities which
> bring a lot of insight from the APAC region.
> 
> > * How do you counter people who assert the TC is not relevant?
> >    (Presumably you think it is, otherwise you would not have run. If
> >    you don't, why did you run?)
> 
> This is a tough one.  That's something we need to work and change, I think
> that historically the involvement of the TC and projects have been very
> hands-off because of the velocity that projects moved at.
> 
> Now that we're a bit slower, I think that having the TC involved in the projects
> can be very interesting.  It provides access to a group of diverse and highly
> technical individuals from different backgrounds (operators, developers -- but
> maybe not as much users) to chime in on certain directions of the projects.
> 
> > That's probably more than enough. Thanks for your attention.
> 
> Thank you for starting this.
> 
> > --
> > Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
> > freenode: cdent                                         tw: @anticdent
> 
> 
>