So, nova's worried about having to be in the boat many of us have been in where they depend on another project not recognizing their important use cases? heh...
ok, so, yeah. that is a legitimate concern. You need someone like the TC to be able to step in, in those cases to help sort that kind of issue out. In the past, the TC was not willing to do so. My gut feeling though is that is finally changing. This is a bigger problem then just Nova, so getting a proper procedure in place to handle this is really important for OpenStack in general. Lets solve that rather then one offing a solution by keeping placement under Nova's control. How do I say this nicely.... Better to talk about it instead of continuing to ignore the hard issues I guess. Nova has been very self centered compared to other projects in the tent. This thread feels like more of the same. If OpenStack as a whole is to get healthier, we need to stop having selfish projects and encourage ones that help each other. I think splitting out placement from Nova's control has at least two benefits 1. Nova has complained a lot about having too much code so they can't take other projects requests. This reduces Nova's code base so they can focus on their core functionality, and more importantly, their users use cases. This will make OpenStack as a whole, healthier. 2. It reduces Nova's special project status leveling the playing field a bit. Nova can help influence the TC to solving difficult cross project problems along with the rest of us rather then going off and doing things on their own. Thanks, Kevin ________________________________________ From: Matt Riedemann [mriede...@gmail.com] Sent: Monday, August 20, 2018 6:23 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction? On 8/20/2018 8:08 PM, Matt Riedemann wrote: > On 8/20/2018 6:42 PM, Ed Leafe wrote: >> It was said in the #openstack-tc discussions, but for those on the >> mailing list, the biggest concern among the Nova core developers is >> that the consensus among Placement cores will certainly not align with >> the needs of Nova. I personally think that's ridiculous, and, as one >> of the very opinionated people involved, a bit insulting. No one wants >> to see either Nova or Placement to fail. > > I believe you're paraphrasing what I said, and I never said I was > speaking for all nova core developers. I don't think anyone working on > placement would intentionally block things nova needs or try to see nova > fail. Here is an example of the concern. In Sydney we talked about adding types to the consumers resource in placement so that nova could use placement for counting quotas [1]. Chris considered it a weird hack but it's pretty straight-forward from a nova consumption point of view. So if placement were separately governed with let's say Chris as PTL, would something like that become a holy war type issue because it's "weird" and convolutes the desire for a minimalist API? I think Chris' stance on this particular item has softened over time as more of a "meh" but it's a worry about extracting with a separate team that is against changes because they are not ideal for Placement yet are needed for a consumer of Placement. I understand this is likely selfish on the part of the nova people that want this (including myself) and maybe close-minded to alternative solutions to the problem (I'm not sure if it's all been thought out end-to-end yet, Mel would likely know the latest on this item). Anyway, I like to have examples when I'm stating something to gain understanding, so that's what I'm trying to do here - explain, with an example, what I said in the tc channel discussion today. [1] Line 55 https://etherpad.openstack.org/p/SYD-forum-nova-placement-update -- Thanks, Matt __________________________________________________________________________ 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
