| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-05 | |||
| 19:24:42 | dansmith | can I have rst? | |
| 19:24:43 | sdague | https://dague.net//testing/flow.rst | |
| 19:24:57 | sdague | I can also stick this in a throw away git repo if you want | |
| 19:24:59 | mriedem | sdague: i only see "POST /v2.0/ports.json" once | |
| 19:25:10 | sdague | mriedem: yeh, my bad, I glossed over | |
| 19:25:10 | dansmith | thanks, I'll try to trim it | |
| 19:25:21 | openstackgerrit | Eric Fried proposed openstack/nova master: nova.utils.get_service_url() https://review.openstack.org/458257 | |
| 19:25:28 | sdague | dansmith: how about I do an import into a git repo | |
| 19:25:50 | dansmith | sdague: that seems entirely overkill to me, but as you wish | |
| 19:25:52 | mriedem | i'm not sure what this is: May 05 14:12:54 os4 neutron-server[24158]: DEBUG neutron.api.v2.base [req-8b4ccea7-1462-43cc-9a21-f0013b797999 demo demo] Request body: {u'port': {u'network_id': u'8356212e | |
| 19:26:58 | mriedem | "neutron-server starts building that network:" isn't actually building a network | |
| 19:27:03 | mriedem | it's finding the available network for the project | |
| 19:27:06 | mriedem | on which to create the port | |
| 19:27:21 | mriedem | we'd only create a network if we use the auto-allocated-topology (get me a network) stuff | |
| 19:27:35 | dansmith | sounds like mriedem wants to trim it | |
| 19:27:43 | mriedem | i don't, | |
| 19:27:45 | mriedem | i just want to nit pick it | |
| 19:28:10 | mriedem | i'll go back to reading the thread about stable branch LTS and n-5 upgrade support | |
| 19:28:25 | sdague | dansmith: what's your github id again? | |
| 19:28:29 | dansmith | kk7ds | |
| 19:28:52 | sdague | https://github.com/sdague/nova-boot-flow | |
| 19:28:55 | sdague | you have commit | |
| 19:29:03 | sdague | mriedem: if you want so as well | |
| 19:29:40 | sdague | dansmith: I was trying to keep all the logs around, just build the summaries when appropriate, so if you go to trim, how about just getting rid of some summaries | |
| 19:33:10 | dansmith | sdague: yeah, I meant trim the summaries, not the log lines | |
| 19:33:12 | dansmith | trim and edit the summaries I mean | |
| 19:35:50 | sdague | dansmith: have at, you should have full write on that repo | |
| 19:36:43 | dansmith | sdague: okay, I'm still scrambling with other stuff but I'll try | |
| 19:36:48 | dansmith | I guess that would be easy to do on the plane | |
| 19:36:56 | sdague | dansmith: yep, being git and all | |
| 19:41:01 | cdent | mriedem: maybe you should throw some downgrade support hand grenades into that thread | |
| 19:44:51 | mriedem | jesus | |
| 19:44:58 | mriedem | the features vs stability thing drives me nuts | |
| 19:45:13 | mriedem | no one mentioned how we talked about non-feature bug fix only releases once | |
| 19:45:43 | mriedem | 'openstack doesn't / can't scale', ok we'll work on that, 'but you're working on it makes the transition hard and complex and that pisses me off' | |
| 19:46:18 | mriedem | it's just easier to not say anything at all in these threads because they pop up every 3-6 months and die on the vine anyway | |
| 19:46:53 | mriedem | i did see cells v2 and placement get run through the mud a few times though, that's fun | |
| 19:51:17 | mriedem | i guess on one replied to the request for input on the onboarding session in the ML | |
| 19:51:17 | sdague | yeh, my entire point on that thread at this point is going to be "show me a gratuitous feature" | |
| 19:51:18 | mriedem | oh well | |
| 19:51:34 | mriedem | sdague: cells v2 and placement were called out as causing pain with no benefit | |
| 19:51:47 | sdague | I guess I missed where placement was called out on that | |
| 19:51:48 | mriedem | not directly replying ot you | |
| 19:51:59 | sdague | I did just rejump in on the cellsv2 one | |
| 19:52:45 | sdague | so, I will agree that there were some more bumps than would have been nice there, but compared to cells v1, which people kept deploying and getting unfixable behavior... it was a much better path | |
| 19:54:40 | mriedem | cdent: an anecdote really http://lists.openstack.org/pipermail/openstack-dev/2017-May/116440.html | |
| 19:54:49 | mriedem | "nova placement API caused a bit of a headache for deployment tools..." | |
| 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 | |