| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-19 | |||
| 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: :) | |
| 15:44:32 | _ix | Good morning folks. I'm having a heck of a time migrating a host after a hypervisor failure. | |
| 15:44:40 | mriedem | TheJulia: meaning you can do this with other volume types | |
| 15:44:42 | mriedem | like fibrechannel | |
| 15:44:43 | mriedem | right? | |
| 15:44:55 | _ix | Waiting some 30 minutes for a single migration only to find an unsatisfying 401 error in the logs. | |
| 15:45:04 | mriedem | TheJulia: i think when there is >1 supported type, we'll just drop the note from the support matrix | |
| 15:45:21 | mriedem | _ix: token timeout? | |
| 15:45:24 | mriedem | cold or live migration? | |
| 15:45:31 | _ix | Cold. | |
| 15:45:38 | mriedem | if it's a cold migration of a large image, then the token probably timed out | |
| 15:45:53 | mriedem | which you should find in the nova-compute logs | |
| 15:46:02 | TheJulia | mriedem: yes, I'll revise that patch then in the next little bit to pull out the fc support in the matrix | |
| 15:46:32 | mriedem | TheJulia: ok there were other issues in there i pointed out, like the versioning thing, but i assume you're on top of all that | |
| 15:46:45 | jaypipes | TheJulia: don't forget to take the red pill. | |
| 15:46:53 | mriedem | _ix: fyi https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/use-service-tokens.html | |
| 15:46:58 | _ix | mriedem: I'll take a look. Thanks for the direction! | |
| 15:46:59 | TheJulia | mriedem: in the reno? | |
| 15:46:59 | sean-k-mooney | jaypipes: jangutter i think https://review.openstack.org/#/c/485125 is the last patch that is needed before we can make the os-vif release | |
| 15:47:12 | mriedem | _ix: in ocata, you could configure nova to provide a service token for long-running tasks that involved cinder or neutron, | |
| 15:47:12 | jaypipes | sean-k-mooney: yup, got that up in gertty now. | |
| 15:47:15 | mriedem | that was expanded to glance in pike | |
| 15:47:24 | TheJulia | jaypipes: I took the red pill a long time ago. | |
| 15:47:29 | jaypipes | :) | |
| 15:47:30 | _ix | mriedem: This is... Juno. | |
| 15:47:40 | mriedem | _ix: well then you're f'ed :) | |
| 15:47:44 | _ix | Ha! | |
| 15:47:49 | mriedem | _ix: increase the token timeout i guess? | |
| 15:47:51 | mriedem | idk | |
| 15:47:59 | _ix | Is that in the nova.conf of the losing host? | |