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