| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-19 | |||
| 14:57:08 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add Open vSwitch patch port https://review.openstack.org/485228 | |
| 15:02:03 | sdague | sfinucan: confused on https://review.openstack.org/#/c/428241 - because I thought we were going the other direction | |
| 15:03:24 | stephenfin | sdague: Oh, I wasn't aware of that | |
| 15:03:26 | stephenfin | That changes things | |
| 15:03:46 | sdague | see efried's work there | |
| 15:03:54 | stephenfin | will do | |
| 15:12:17 | mriedem | bauzas: ok https://review.openstack.org/#/c/484828/ | |
| 15:12:27 | mriedem | aller! | |
| 15:12:48 | bauzas | mriedem: so, I was thinking about accepting custom drivers if they use the placement API | |
| 15:13:09 | bauzas | mriedem: I mean, if all our drivers are given a list of hosts by the placement API | |
| 15:13:35 | bauzas | mriedem: the problem with the FilterScheduler driver is that it will call filters N times when you have N hosts | |
| 15:14:00 | bauzas | mriedem: so I think some operators would like to just call once a 3rd-party system | |
| 15:14:37 | bauzas | mriedem: if we do that, I think it would not be an interop problem given we'll be sure that any destination would be accepted by placement API | |
| 15:14:40 | openstackgerrit | Feodor Tersin proposed openstack/nova master: libvirt: Straighten resize condition in Image.cache https://review.openstack.org/485236 | |
| 15:15:14 | bauzas | of course, like I said, it means that all the drivers would be calling placement for both getting hosts to verify, and would also claim the allocation too | |
| 15:15:31 | bauzas | thoughts about that? | |
| 15:15:35 | mriedem | bauzas: i'm not sure what that has to do with the bug fix at hand | |
| 15:15:47 | mriedem | which needs to go back to ocata where the custom scheduler driver loading was broken | |
| 15:15:58 | bauzas | mriedem: so, about that | |
| 15:16:01 | bauzas | mriedem: for the bug | |
| 15:16:14 | bauzas | mriedem: just adding the new choice would be okay I think | |
| 15:16:28 | bauzas | mriedem: but not saying it would be deprecated by Queens IMHO | |
| 15:16:32 | sean-k-mooney | bauzas: it would not be transparent on upgrade | |
| 15:16:49 | bauzas | sean-k-mooney: not sure I understand why | |
| 15:17:14 | bauzas | I wouldn't deprecate a choice | |
| 15:17:18 | bauzas | just adding a new one | |
| 15:17:24 | sean-k-mooney | bauzas: there was nothing that requried them to call the custom_driver custom_driver in the setup.cfg entrypoint before | |
| 15:17:30 | bauzas | the problem with upgrades is when you stop to use an opt | |
| 15:17:45 | mriedem | bauzas: adding choices is not ok | |
| 15:17:49 | mriedem | it's not backward compatible | |
| 15:17:55 | mriedem | when upgrading *to* ocata | |
| 15:18:24 | mriedem | we have to drop 'choices', | |
| 15:18:31 | bauzas | mriedem: not only then | |
| 15:18:42 | mriedem | and when loading up the entry point in the scheduler manager, if it's not in our whitelist of 'choices' that we support today, then we log a warning | |
| 15:19:02 | bauzas | mriedem: because if you upgrade from Newton, then you need to modify your nova.conf because the value wouldn't be the same | |
| 15:19:17 | bauzas | mriedem: in Newton, you needed to pass a python path | |
| 15:19:39 | sean-k-mooney | bauzas: you could not use the alis form stevador? | |
| 15:19:43 | bauzas | mriedem: in Ocata, you need to pass just a name for an existing entrypoint | |
| 15:21:17 | sean-k-mooney | bauzas: i guess the point still stands if we keep the choices field we would need a config change on upgrade and a change to the python module that exports the driver to export it as custom_driver | |
| 15:21:29 | mriedem | bauzas: i don't think that's right | |
| 15:21:55 | mriedem | in mitaka we deprecated the ability to classload and removed that in ocata | |
| 15:22:00 | mriedem | and replaced with stevedore entrypoint aliases | |
| 15:22:14 | mriedem | but still allows you to add your own stevedore entrypoint to load from | |
| 15:22:22 | mriedem | that was until we added that choices kwarg and broke everything | |
| 15:22:31 | mriedem | i can do some git history diving | |
| 15:23:02 | mriedem | https://github.com/openstack/nova/commit/fe3d6dba3d1db8f97dab4baffcc11dda56368096 | |
| 15:23:17 | sean-k-mooney | stevedore also allows you to skip using the alais and use the class path it points to transparently so if the code was not moved the old config options would have worked | |
| 15:23:26 | bauzas | mmm | |
| 15:24:01 | mriedem | that merged on sept 22 | |
| 15:24:14 | mriedem | https://review.openstack.org/#/c/349666/ introduced the choices kwarg which broke it | |
| 15:24:22 | mriedem | that merged on sept 30 | |
| 15:24:30 | bauzas | mriedem: so, to make it clear, if you were newton | |
| 15:24:41 | bauzas | mriedem: and you didn't use the default value | |
| 15:24:56 | bauzas | mriedem: you were passing a python path for knowing which module to use, right? | |
| 15:25:36 | mriedem | not necessarily | |
| 15:25:42 | mriedem | you could have already been using a stevedore entry | |
| 15:25:53 | mriedem | https://review.openstack.org/#/c/339760/8/nova/scheduler/manager.py | |
| 15:26:01 | TheJulia | mriedem: apologies for the minor interrupt, but I and dtantsur replied to https://review.openstack.org/#/c/215385/ which hopefully will clear up the confusion. | |
| 15:26:08 | mriedem | ^ before that change, it would attempt to load from stevedore and failing that, try to load from classpath | |
| 15:27:41 | bauzas | mriedem: ah-ha, nevermind my comment because https://github.com/openstack/nova/blob/fe3d6dba3d1db8f97dab4baffcc11dda56368096/releasenotes/notes/sched_remove_classpath_import-5d0f48eb388e6948.yaml | |
| 15:28:01 | bauzas | mriedem: which is Newton | |
| 15:28:11 | bauzas | mriedem: so I was wrong and you were right | |
| 15:28:23 | bauzas | mriedem: okay, I'll then just remove the choices kwarg | |
| 15:28:45 | bauzas | mriedem: the big question being whether we want to deprecate the possibility to use a custom scheduler by queens | |
| 15:28:47 | sdague | bauzas / cdent - there a race with setting up placement/scheduler fixture it seems - http://logs.openstack.org/27/479027/1/gate/gate-nova-tox-functional-py35-ubuntu-xenial/0a995a0/console.html#_2017-07-19_14_33_46_324724 | |
| 15:28:55 | sdague | which gives us novalid host on some functional tests | |
| 15:29:46 | bauzas | arf, I have a meeting to run | |
| 15:30:18 | cdent | sdague: there’s been quite a bit of kerfuffle with the compute api and the placement api fixtures not playing well together in the same tests. for a while there was some thought that it was eventlet related, but I’m not sure where that landed. mriedem may have more info? | |
| 15:30:55 | mriedem | bauzas: https://github.com/openstack/nova/blob/fe3d6dba3d1db8f97dab4baffcc11dda56368096/releasenotes/notes/sched_remove_classpath_import-5d0f48eb388e6948.yaml is not newton | |
| 15:31:01 | mriedem | https://review.openstack.org/#/c/339760/ | |
| 15:31:07 | mriedem | Branches master, stable/ocata Tags 15.0.0, 15.0.0.0b1, 15.0.0.0b2, 15.0.0.0b3, 15.0.0.0rc1, 15.0.0.0rc2, 15.0.1, 15.0.2, 15.0.3, 15.0.4, 15.0.5, 15.0.6, 16.0.0.0b1, 16.0.0.0b2 | |
| 15:31:12 | sdague | cdent: for things like that we could probably make super fake placement that says "thumbs up", given that we're running 1 compute | |
| 15:32:07 | mriedem | yes i've seen the timeout exception holding the lock in the compute update_available_resource | |
| 15:32:07 | cdent | yeah, that’s probably a good idea | |
| 15:32:09 | bauzas | mriedem: it's ocata, so anyway you have to change that | |
| 15:32:25 | mriedem | the PlacementFixture was turned on relatively global for functional tests recently | |
| 15:32:34 | mriedem | so it's running in a lot more functional tests, whether we need it to or not | |
| 15:32:57 | mriedem | sdague: semi related we also did this globally https://review.openstack.org/#/c/483972/ | |
| 15:33:25 | mriedem | we didn't have a fingerprint for it, but it seems to have helped a little bit from anecdotal evidence, meaning me not having to recheck on weird wsgi errors as much | |
| 15:33:55 | sdague | mriedem: yeh, I think I'd stop doing placement globally, that seems like a lot of complexity when you don't need it | |
| 15:35:52 | mriedem | TheJulia: does a 'vendor driver' in ironic mean an out of tree driver? | |
| 15:36:34 | mriedem | if the limitation is on fibrechannel support, then why not just say, iscsi is currently the only supported volume type | |
| 15:37:45 | ftersin | mdbooth: hi. could you please review that (https://review.openstack.org/#/c/407440/) again? i addressed your comments and wait for new ones. | |
| 15:39:15 | openstackgerrit | John Haan proposed openstack/nova-specs master: Support volume_type with BDM paramter https://review.openstack.org/466595 | |
| 15:40:46 | TheJulia | mriedem: anything produced by a vendor, so it could be in or out of tree, in the terms I wrote, I meant in-tree vendor drivers. | |
| 15:41:15 | mriedem | ok, not sure why 'vendor' is even a distinction then | |
| 15:41:19 | TheJulia | mriedem: I'd prefer to just drop the tag completely due to confusion at this point | |
| 15:41:19 | mriedem | what's a non-vendor driver in ironic? | |
| 15:41:36 | mriedem | the ironic coop driver :) | |
| 15:41:43 | TheJulia | mriedem: agent_ipmitool, pxe_ipmitool, or the ipmi, redfish hardware types | |
| 15:41:47 | mriedem | bm traded for hemp | |
| 15:41:50 | mriedem | ok | |
| 15:41:52 | TheJulia | lol | |
| 15:42:31 | mriedem | ok, so if the iscsi volume type is the only one that's currently supported, that's what i'd clarify in the support matrix and release note | |
| 15:42:37 | jaypipes | jangutter: 483921 approved. | |
| 15:42:50 | TheJulia | mriedem: those are the drivers we're able to test in the gate since we can emulate the BMC of baremetal hardware in those cases. | |
| 15:43:41 | TheJulia | mriedem: okay, I just want to make sure or at least hopefully make sure nobody freaks out when we ask to amend the support matrix later without putting code in nova :) | |
| 15:44:07 | jangutter | jaypipes, sean-k-mooney: the people in the office just looked at me really oddly. I don't think they expected that kind of sound emitting from human vocal cords. | |
| 15:44:17 | TheJulia | mriedem: that being, when we have that support in place in our reference drivers | |
| 15:44:21 | jaypipes | jangutter: :) | |