Posted	Nick	Remark
#openstack-nova - 2017-05-05
19:55:00	cdent	mriedem: I think you mean sdague ?
19:55:07	mriedem	oh yeah
19:55:07	mriedem	sorry
19:55:11	cdent	s'alright
19:55:51	cdent	"but consider that "leadership" is always limiting for innovation."
19:57:56	cdent	I'm hopeful that the "everyone deploy with wsgi" will finally get people understanding that deploying with wsgi means "you can do whatever you want, easily, but you have to choose" instead of "that's different"
19:58:23	sdague	mriedem: ok, that's a pretty soft hit honestly
19:58:41	mriedem	sdague: yeah i said it was an anecdote on re-read
19:58:42	sdague	and, I would agree with it, the docs lagged
19:58:51	mriedem	which docs/
19:58:51	mriedem	?
19:58:58	mriedem	we had pretty solid in-tree docs by rc1
19:59:04	mriedem	the install guide was late
19:59:08	mriedem	for both placement and cells v2
19:59:09	sdague	the install guide
19:59:24	sdague	because that's the bit that people on the deploy side do need
19:59:42	sdague	and, I think that's fine critique of "yep, we need to do that better next time"
19:59:44	mriedem	sure, but when is the last time someone from nova was writing the install guide?
20:00:06	sdague	mriedem: yep, sure, a bunch of things changed since the last major service changes like this showed up
20:00:22	mriedem	isn't this like the thing in newton when matt kasawara wanted the install guide in nova so we'd own it, and we said no
20:00:44	sdague	mriedem: no, I think this was some collective falling through the cracks
20:01:29	sdague	where there was a lot of assumptions about who all owned things, that seemed to fall appart, because the last time a new service was rolled out was conductor, and the landscape was a lot different
20:01:39	sdague	and ... we kind of happened to have 2 hit at the same time
20:01:49	sdague	so, stuff happens
20:02:13	mriedem	i agree that not having a rushed clusterfck of a release in ocata would have been better :)
20:02:21	mriedem	and i think we retrospected on that
20:02:21	sdague	mriedem: right, also that
20:02:36	sdague	anyway
20:02:48	mriedem	but i will say i'm happy with the focus put on the in-tree docs for placement and cells v2 that a bunch of people worked on
20:03:04	mriedem	in years past our bar for documentation of features in tree was non-existent
20:03:11	mriedem	just like our bar for requiring testing
20:03:25	sdague	my point is, there is totally legit criticism on some things that were less than ideal for service / major feature rollout.
20:03:45	sdague	but that's very different than saying those are gratuitous features
20:03:47	mriedem	sure, i don't disagree, and i think we/i have been as critical
20:05:49	sdague	I'm just sick of "features trump stability/usability" where features are code for "stuff I don't like or understand" and "stability/usability" is code for "my personal priority". And don't want to let that one slide this time.
20:12:32	dansmith	I especially like "rearchitect the entire project ... in a branch"
20:17:52	sdague	yeh... I am sure the upgrade process would be very smooth there
20:28:27	cdent	Is "solid governance model" code for "not letting the devs decide"?
20:34:57	sdague	probably
20:35:19	sdague	or, more likely "put my distguished architect in charge"
20:35:57	sdague	ok... I'm saving to draft a response on that last oracle one. Because that's going to spiral out of control if I don't
20:36:04	sdague	I should make sure mordred sees it
20:36:38	sdague	because the "we need 12 months to integrate our value add".... is kind of trigger words
20:38:07	cdent	heh
20:38:37	cdent	I have a sort of point of order question, or something like that:
20:39:35	cdent	Why are people so worried about shit spiralling out of control? From a slightly different point of view that looks like people just avoiding the truth and putting more barriers in place to getting to the root causes of problems.
20:40:16	cdent	I know, as mriedem so eloquently puts it, there's a lot of bitter feelings, but that's a symptom of a greater disease, not the problem itself
20:40:20	mriedem	is it bad to pick a fight with what is probably an oracle exec?
20:41:14	cdent	I suppose there's a chance that disagreement on this stuff is just the nature of the universe, so keeping it in a pot is best, but that feels a bit dystopic.
20:41:19	sdague	cdent: because not everyone has your patience level for email fights
20:41:25	mriedem	"There needs to be more customer and vendor driven involvement to solidifying a core set of features that everyone can rely on working consistently across releases and upgrades."
20:41:29	mriedem	^ well no sh*t
20:41:40	mriedem	so pony up the leads here oracle
20:42:22	mriedem	sdague: oh heh, i just replied to that one
20:42:32	mriedem	i couldn't resist
20:42:35	cdent	please please sdague email _discussions_ ;)
20:42:42	sdague	many people find the random flaming basically too emotionally sapping to want to participate in discussions at all, so what happens is all the thoughtful middle gives up
20:42:42	cdent	why should you resist mriedem
20:42:50	mriedem	i'm glad i wasn't the only one that interpreted "we need you to do LTS because we have a hard time keeping up with our forks"
20:43:14	dansmith	at least oracle funds so many people working on stuff in the community
20:43:44	mriedem	to date, there is one person from oracle helping with multiattach
20:44:05	mriedem	i will give credit where credit is due
20:44:15	cdent	sdague: I guess I'm weird: I'm so conscious of the under- or un-expressed emotion that that is the thing that I find so sapping.
20:44:28	cdent	incredibly so
20:45:11	sdague	cdent: sure, that might be you. Lots of people basically end up ignoring the whole of the mailing list for some number of weeks after this because they see the mailing list as a place where loud people yell about things.
20:45:43	cdent	do you consider the current conversation to be yelling already or not quite there yet?
20:45:56	sdague	I think it is just about there
20:45:57	mriedem	stvnoyes: btw, let me thank you personally for helping out with the multiattach stuff
20:46:27	sdague	cdent: which is why I "save draft" on my last email
20:46:29	mriedem	stvnoyes: also gave you a tip in https://review.openstack.org/#/c/456877/6/nova/compute/manager.py
20:46:47	cdent	wow. I guess I spent too much time on usenet in the 90s
20:46:51	sdague	cdent: yep
20:47:35	cdent	to me this feel like polite but earnest dinner conversation
20:47:57	sdague	I think if you polled the audience you would not get that reaction
20:50:14	melwitt	mriedem: cool, I figured. since we're going to be at the summit anyway, we could chat briefly about it then
20:50:32	mriedem	melwitt: perhaps on thursday night
20:50:45	mriedem	which is the only night i'll get to enjoy the company of my fellow nova compatriots
20:52:00	melwitt	mriedem: k. bummer we only get to hang with you one evening
20:52:12	mriedem	and sunday night
20:52:13	mriedem	and friday morning
20:52:22	mriedem	and the 2 minutes in between sessions
20:52:29	efried	mriedem Would you mind pushing https://review.openstack.org/#/c/391288/ ? I'm getting merge conflicts up the chain, and would like to limit how much rebasing is needed.
20:53:23	mriedem	efried: don't you know i'm all riled up?
20:53:28	mriedem	:)
20:53:37	efried	mriedem Me too. The day I've had.
20:53:53	mriedem	just blame it on thorst_afk
20:53:57	efried	Always.
20:54:21	thorst_afk	he's always afk
20:54:38	melwitt	hah
20:56:16	efried	Honestly, I'm not sure how https://review.openstack.org/#/c/443189/ got a merge conflict but its predecessors didn't.
20:56:32	efried	It didn't touch any non-PowerVM files.
20:57:32	mriedem	melwitt: i'm suprised this doesn't result in a keyerror
20:57:32	mriedem	https://review.openstack.org/#/c/456877/7/nova/tests/unit/compute/test_compute.py@10260
20:57:36	mriedem	since it's not using a kwarg
20:57:58	mriedem	oh i know why
20:58:02	mriedem	it's using attachment_id as the message
20:58:55	melwitt	mriedem: yeah, that might match because of python named argument matching?
20:59:08	mriedem	def __init__(self, message=None, **kwargs):
20:59:08	mriedem	no i think it's because
20:59:12	mriedem	if not message:

Earlier   Later