| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-18 | |||
| 12:55:04 | jaypipes | morning supernovas. | |
| 13:00:02 | efried | jaypipes Is that a greeting or a weather bulletin? | |
| 13:01:26 | jaypipes | efried: :) | |
| 13:03:02 | jaypipes | gibi: looking into your placement troubles now.. | |
| 13:03:31 | jaypipes | gibi: MAGIC! The (Non)Gathering | |
| 13:04:05 | gibi | jaypipes: thanks for the help | |
| 13:25:28 | openstackgerrit | Alex Szarka proposed openstack/nova master: Transform instance-evacuate notification https://review.openstack.org/482148 | |
| 13:29:22 | jaypipes | sean-k-mooney, moshele, jangutter: can you all do a google hangout now to discuss the "refctor hw_veb get config" patch? (yes, moshele, "refactor" is still misspelled in your commit summary :P ) | |
| 13:29:57 | jangutter | jaypipes: I'm available. | |
| 13:30:47 | sean-k-mooney | jaypipes: sure i can join | |
| 13:41:52 | jaypipes | gibi: good afternoon sir. wanted to introduce you to bhagyashris. | |
| 13:42:08 | jaypipes | gibi: both of you are currently working on testing scenarios for the same thing (shared resource providers) | |
| 13:42:21 | bhagyashris | gibi: Hi, | |
| 13:42:25 | jaypipes | gibi: I pointed bhagyashris to the ML thread we're currently talking about this. | |
| 13:46:00 | gmann_ | mriedem: stephenfin alex_xu can you check this, this can be last patch for policy-doc BP - https://review.openstack.org/#/c/484646/ | |
| 13:46:05 | gibi | bhagyashris: hi! | |
| 13:46:58 | gibi | bhagyashris: do you have a patch/ML thread where your work is describe? | |
| 13:48:11 | mriedem | gmann_: done | |
| 13:49:18 | gmann_ | mriedem: thanks. | |
| 13:49:40 | bhagyashris | bhagyashris: no not right now, | |
| 13:49:58 | bhagyashris | gibi: no not right now. | |
| 13:49:59 | mriedem | dansmith: melwitt: top o the morning - one thing i was thinking about at 3am - should we be including build requests in our instance count? we aren't currently, but i'd think that plays a part in checking quota in the API before casting to conductor | |
| 13:50:04 | jaypipes | gibi: I pointed bhagyashris to your ML thread. he's reading it now. | |
| 13:50:11 | jaypipes | as am I :) | |
| 13:50:42 | bhagyashris | gibi: Yeah, | |
| 13:50:55 | gibi | bhagyashris: OK. let me know if I can help you with something related to custom resource | |
| 13:51:24 | gibi | bhagyashris: I'm looking at that from user perspective, I'm not familiar with the implementation yet | |
| 13:51:44 | bhagyashris | gibi: Yeah thank you. In case of any doubts i will ping you. | |
| 13:52:10 | stephenfin | gmann_: Sure | |
| 13:52:42 | gibi | bhagyashris, jaypipes: I will be away soon for an hour but I will be still back today | |
| 13:52:59 | jaypipes | gibi: k. I'm pouring over these logs and script outputs. | |
| 13:53:02 | bhagyashris | gibi: same I am also not fully aware about the implementation yet but trying to get it. | |
| 13:53:04 | mamandle | alex_xu: bauzas: can you please take a look at the updated changes for https://review.openstack.org/#/c/483911/ , thanks. | |
| 13:53:06 | dansmith | mriedem: aren't we checking it at the point of instance creation? | |
| 13:53:07 | stephenfin | gmann_: Ah, mriedem got to it. We should fix that in oslo.policy upstream. It's silly that we have to wrap manually wrap things like that | |
| 13:53:11 | jaypipes | gibi: haven't seen anything out of order yet | |
| 13:53:44 | gibi | jaypipes: logs looks clean to me, but somehow placement only like the allocation_candidate request if both providers has the traits | |
| 13:53:50 | stephenfin | jaypipes, mriedem: Am I allowed to remove nova-network features so long as they don't break gate jobs? | |
| 13:54:12 | stephenfin | Referring to jangutter's comments here https://review.openstack.org/#/c/483030/2/nova/network/linux_net.py | |
| 13:54:45 | mriedem | if it's used by CONF.linuxnet_interface_driver and CONF.linuxnet_interface_driver isn't removed, then no | |
| 13:55:01 | dansmith | mriedem: meaning I think we're still gating on actually creating the instance, which means we're fine.. if we included buildrequests we might be able to fail on quota before scheduling I guess, but we'd do more db traffic and be maybe too conservative on some of the checks I think | |
| 13:55:04 | jaypipes | stephenfin: I'd say yes (especially considering all that linked code has been cleaned up and moved into os-vif), but it's mriedem's call. | |
| 13:55:47 | mriedem | dansmith: the instance is created in conductor, i'm thinking more about when we're still in the api | |
| 13:55:50 | mriedem | in _provision_instances | |
| 13:56:00 | bhagyashris | jaypipes, gibi: I working in the IST time zone so now my time is over. but yeah I will check it tomorrow. Thank you :) | |
| 13:56:02 | mriedem | if we fail to create in conductor, the instances go to ERROR state and are put into cell0 | |
| 13:56:08 | jangutter | stephenfin: wow, LinuxOVSInterfaceDriver dates from 6 years back. | |
| 13:56:19 | stephenfin | jangutter: yuuup | |
| 13:56:42 | stephenfin | and it's loaded using importlib so it's tough to even figure out where it's used, whether there's coverage etc. | |
| 13:56:51 | dansmith | mriedem: so you're just saying if we check in api and count instances+buildrequests we can fail earlier if they're over quota yes? | |
| 13:56:53 | stephenfin | I despise that pattern | |
| 13:56:55 | gibi | bhagyashris: have a good afternoon | |
| 13:56:58 | mriedem | dansmith: i was just thinking about how the UX is before and after - before we'd create a reservation and fail early in API if we are over quota, but now we only check the instance count in the cells but that's ignoring build requests | |
| 13:56:59 | jaypipes | bhagyashris: your watch has ended? :) | |
| 13:57:08 | gibi | bhagyashris: I'm in UTC+2 so still a bit of workday left | |
| 13:57:11 | mriedem | dansmith: yes i think that's what i'm saying | |
| 13:57:33 | mriedem | so now, we might pass api and get to conductor and fail, and then you've got 20 ERROR instances to cleanup | |
| 13:57:36 | mriedem | if you're bursting | |
| 13:57:46 | bauzas | mriedem: FWIW, I left a comment for https://bugs.launchpad.net/nova/+bug/1704788 | |
| 13:57:47 | openstack | Launchpad bug 1704788 in OpenStack Compute (nova) "Hardcoded choices for nova scheduler driver" [Undecided,Confirmed] | |
| 13:58:02 | dansmith | mriedem: because sometimes the instance and build request exist together for a second, you would end up racing to consume your last instance if you're doing a lot of builds, but maybe that's better I dunno | |
| 13:58:38 | mriedem | bauzas: where was "because that would mean we would go against the consensus we had in Ocata." documented? | |
| 13:58:39 | dansmith | mriedem: my head is in something else atm, so let us chat with melwitt when she's around | |
| 13:58:53 | bhagyashris | jaypipes, gibi: yeah now it's 7:30 pm here | |
| 13:58:59 | mriedem | dansmith: sure, and i'm not liking the idea of adding more complexity to this pile | |
| 13:58:59 | jangutter | stephenfin: somewhere, someone still has linuxnet_interface_driver = nova.network.linux_net.LinuxOVSInterfaceDriver set in a production config, and they are planning to use it in Queens. | |
| 13:59:05 | mriedem | just got thinking about it though | |
| 13:59:16 | bauzas | mriedem: I don't remember exactly when we discussed that, but AFAIR we said that having custom drivers was not something good | |
| 13:59:26 | jaypipes | gibi: in your script, after line 157, can you call GET /allocation_candidates?resources=CUSTOM_MAGIC:512 and tell me what is returned please? | |
| 14:00:19 | mriedem | bauzas: regardless i think we scrooged the pooch, as the french would say, when it came to that choices restriction being put in since we didn't have a deprecation period on non-standard drivers | |
| 14:00:21 | dansmith | mriedem: yeah, kindof a big thing to change at this point | |
| 14:00:27 | mriedem | *screwed the pooch | |
| 14:00:28 | mriedem | wow | |
| 14:00:44 | stephenfin | jangutter: Possibly, but if they do then they're using nova-net and we won't/can't support them anymore because it's deprecated | |
| 14:00:55 | bauzas | mriedem: possibly | |
| 14:01:14 | openstackgerrit | Alex Szarka proposed openstack/nova master: Refactor create_delete_server_with_instance_update https://review.openstack.org/466296 | |
| 14:01:17 | mriedem | jangutter: stephenfin: to be clear, we don't have to add feature parity or support for any new features for nova-net at this point | |
| 14:01:19 | mriedem | if that's a question | |
| 14:01:54 | stephenfin | mriedem: Not quite. The question is can we remove nova-net stuff if it doesn't break the cells v1 jobs | |
| 14:02:04 | bauzas | mriedem: so, in that case, should we just accept strings and asking to operators to modify setup.cfg ? | |
| 14:02:15 | stephenfin | untested nova-net stuff, I might add | |
| 14:02:28 | mriedem | stephenfin: can't make that assumption - the cellsv1 job is just one config | |
| 14:02:49 | mriedem | bauzas: that's the way it worked prior to the choices restriction | |
| 14:02:56 | stephenfin | drat | |
| 14:03:02 | stephenfin | looks like it's to stay, jangutter | |
| 14:03:06 | stephenfin | *got to | |
| 14:03:11 | mriedem | bauzas: i'm not advocating supporting out of tree scheduler drivers | |
| 14:03:26 | jangutter | stephenfin: here's to 6 more years! | |
| 14:03:35 | mriedem | bauzas: so what i'm proposing is we enable that ability, along with immediately deprecating it, and backport that to ocata | |
| 14:03:37 | mriedem | and remove in queens | |
| 14:03:38 | bauzas | mriedem: not really | |
| 14:03:47 | mriedem | jangutter: stephenfin: tbc, i'm also not sure what the context is here | |
| 14:03:48 | bauzas | mriedem: previously, we were not using strings | |
| 14:03:59 | bauzas | mriedem: rather, we asked for the package | |
| 14:04:03 | mriedem | bauzas: the scheduler driver config option could be an entry point | |
| 14:04:07 | mriedem | in setup.cfg | |
| 14:04:11 | mriedem | and we'd load it with stevedore | |
| 14:04:12 | mriedem | i know | |
| 14:04:15 | bauzas | mriedem: correct | |
| 14:04:25 | mriedem | i'm saying i think we have to go back to supporting that, | |