| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-06 | |||
| 13:31:02 | sean-k-mooney | sahid: i have +w https://review.openstack.org/#/c/546588/1. i confirmed that both osp and the ubuntu cloud archive ship ovs 2.6 for ocata i would find it strange if other did not also as it was required for the contrack firewall driver, vhost-user reconnect and the netive python bindings for ovs which where three of the big feature in ocata for ovs | |
| 13:32:01 | sean-k-mooney | sahid: technicall if its not a security bug it has to be easily provale to not have any sidefects and is at the sole descretion of the stable maintainer. generally that means docs changes | |
| 13:32:51 | stephenfin | sean-k-mooney: Excellent. Good to get that closed off 🎉 | |
| 13:33:09 | sahid | sean-k-mooney: i don't want add functional change to a backport | |
| 13:33:26 | sahid | so if we want ot backport it for ocata we want it as it is | |
| 13:33:55 | sahid | if not so distribution will do some downstream only backport | |
| 13:34:40 | stephenfin | sahid: Yeah, my suggestion was to add the check to the current patch and then immediately remove it on master. This would let us backport the first patch all the way back | |
| 13:34:42 | sean-k-mooney | sahid: i think an downstream only backport would be best for ocata if required but i dont think may distros shipped 2.5 with ocata if any | |
| 13:35:01 | stephenfin | I think that might have got lost in translation :) | |
| 13:35:01 | sahid | sean-k-mooney: seems reasonable | |
| 13:35:15 | stephenfin | However, downstream only seems the way to go with Ocata and previous | |
| 13:35:17 | sahid | let have it backported for queens and pike so | |
| 13:36:16 | stephenfin | sahid: +1 | |
| 13:37:20 | openstackgerrit | Merged openstack/os-vif master: ovs: do not delete port if already exists https://review.openstack.org/546588 | |
| 13:37:48 | openstackgerrit | sahid proposed openstack/os-vif stable/queens: ovs: do not delete port if already exists https://review.openstack.org/550079 | |
| 13:38:17 | openstackgerrit | sahid proposed openstack/os-vif stable/pike: ovs: do not delete port if already exists https://review.openstack.org/550080 | |
| 13:39:43 | sean-k-mooney | sahid sound good to me. stephen and i are not in the nova-stable-maint group so i suggest you ping sylvain and perhaps matt to review for the backports | |
| 13:42:11 | lvdombrkr89 | hello folks | |
| 13:42:12 | lvdombrkr89 | when try to create instance with multiatach volume get error: Multiattach volumes are only supported starting with compute API version 2.60. (HTTP 400) (Request-ID: req-8babdaa8-29d9-4fd2-b3c4-9129ae3ad0db) | |
| 13:42:18 | lvdombrkr89 | any ideas why? | |
| 13:42:54 | sean-k-mooney | lvdombrkr89: are you using an old nova client that dose not default to the 2.60+ microversion | |
| 13:43:11 | stephenfin | sean-k-mooney, sahid: lyarwood too. I'm sure I could trade a review of the stable patch for this https://review.openstack.org/#/c/550046/ :) | |
| 13:43:31 | lvdombrkr89 | sean-k-mooney : i use dashboard to launch instance | |
| 13:43:33 | lvdombrkr89 | not client | |
| 13:44:49 | sean-k-mooney | lvdombrkr89: i assume you are using queens release of horizon? multi attace lanned very late in queens if i remember correctly so perhaps horizon has not been updated with that micro version | |
| 13:45:49 | lvdombrkr89 | sean-k-mooney: yes i use queens. ok thanks so i would try to use client | |
| 13:46:23 | stephenfin | sean-k-mooney: Does Horizon support microversions? I recall someone saying it did not | |
| 13:46:53 | bauzas | no, I don't think so | |
| 13:47:04 | bauzas | like OSC | |
| 13:47:14 | sean-k-mooney | stephenfin: not sure but if it did not it would default to whatever was the nova clint default correct? | |
| 13:47:21 | sean-k-mooney | or just latest? | |
| 13:47:55 | stephenfin | sean-k-mooney: Not a clue :) I don't tend to use Horizon at all | |
| 13:52:13 | bauzas | stephenfin: sean-k-mooney: sec, see https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/nova.py#L62 | |
| 13:54:20 | sean-k-mooney | bauzas: from that it should cache the micro virsion range supported. | |
| 13:54:44 | sean-k-mooney | lvdombrkr89: did you upgrade your nova depoloyment without restarting horizon by any chance? | |
| 13:55:11 | sean-k-mooney | lvdombrkr89: if you did then perhaps horizon is still cacheing the old microversion | |
| 13:56:59 | lvdombrkr89 | sean-k-mooney: i was deploying queens from the scratch not upgrading | |
| 13:59:07 | sean-k-mooney | lvdombrkr89: that is strang. i only took a passing glance over the multi attach patch sets. my advice would be try to replicate using osc. if you cannot this is a horizon bug if you can reporduce then you should check what micro version is being retrun by the nova api. | |
| 14:01:30 | lvdombrkr89 | sean-k-mooney: okey i will try, will give feedback soon | |
| 14:27:30 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Add disabled column/field to cell_mappings table/object https://review.openstack.org/550090 | |
| 14:29:02 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: [WIP] Add disabled column/field to cell_mappings table/object https://review.openstack.org/550090 | |
| 14:38:12 | stephenfin | I'm seeing logs from the nova-novncproxy service but I can't figure out what module/package is throwing them. Anyone know if it's possible to modify the output of the 'logging' module on a global basis? | |
| 14:41:58 | gibi | stephenfin: global on what level? you can change the logging config via the nova.conf | |
| 14:42:27 | stephenfin | gibi: Global in the context of a service (nova-novncproxy) and its dependent modules | |
| 14:42:57 | stephenfin | I'm thinking it's the websockify package throwing the INFO log but grep isn't helping me much, heh | |
| 14:44:04 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: Detach volumes when VM creation fails https://review.openstack.org/544144 | |
| 14:44:40 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: Ensure the JSON-Schema covers the legacy v2 API https://review.openstack.org/543490 | |
| 14:45:01 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: Allow force-delete even if task_state is not None https://review.openstack.org/543343 | |
| 14:45:36 | gibi | stephenfin: have you tried changing default_log_levels https://docs.openstack.org/oslo.log/latest/configuration/index.html#DEFAULT.default_log_levels | |
| 14:46:14 | stephenfin | gibi: That's _exactly_ what I was looking for :) | |
| 14:46:55 | gibi | stephenfin: cool :) | |
| 14:48:54 | gibi | sahid: thanks for updating the rxt/tx spec. I left some questions inline https://review.openstack.org/#/c/539605/ | |
| 14:49:21 | stephenfin | gibi: Got the bugger (it was websockify). Ta :) | |
| 14:49:47 | gibi | stephenfin: :) | |
| 14:50:19 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Add extra-specs to the flavor show and detail API calls https://review.openstack.org/544158 | |
| 14:54:11 | mriedem | sahid: i wonder if you'd have any ideas about this bug https://bugs.launchpad.net/cinder/+bug/1753394 | |
| 14:54:12 | openstack | Launchpad bug 1753394 in OpenStack Compute (nova) "block_device_mapping_v2 cannot work with Pike" [Undecided,New] | |
| 14:54:26 | mriedem | lyarwood: or you | |
| 14:56:25 | odyssey4me | mriedem Not sure if you've seen this, but I expect that anyone using upgrade_levels/compute=auto will find that the upgrades fail. We have a patch up - I wonder if we could discuss whether that's appropriate or whether there's an alternative we should explore? https://review.openstack.org/#/c/549737/1 | |
| 14:57:39 | mriedem | odyssey4me: dansmith should take a look | |
| 14:58:07 | mriedem | sahid: my guess in that bug is something in https://github.com/openstack/nova/commit/c25629f85feb53b5be0347f68c43b3b55fb9f137 caused a regression | |
| 15:02:01 | sahid | mriedem: yes that seems to be related, i can't really figure that out right now, but i will try to look at it soon | |
| 15:02:09 | mriedem | odyssey4me: that's kind of weird because grenade sets upgrade_levels=auto https://github.com/openstack-dev/grenade/blob/master/projects/60_nova/upgrade.sh#L77 | |
| 15:02:17 | mriedem | sahid: ok, thanks | |
| 15:02:47 | odyssey4me | mriedem I think, in this case, we're seeing failures not on upgrade - but instead on a greenfield deploy | |
| 15:02:51 | mriedem | odyssey4me: were you upgrading from pike to queens? | |
| 15:02:59 | mriedem | odyssey4me: oh... | |
| 15:03:12 | odyssey4me | so this would be a rocky deploy, but with upgrade_levels=auto in the conf file | |
| 15:03:17 | mriedem | odyssey4me: ok so if i set that to auto in just devstack everything should explode | |
| 15:03:31 | odyssey4me | that's what we're seeing in our own tests, yes | |
| 15:03:51 | dansmith | odyssey4me: mriedem I'm commenting | |
| 15:03:53 | odyssey4me | lemme find you an example | |
| 15:04:53 | evrardjp | dansmith: mriedem thanks for your time there. | |
| 15:05:33 | odyssey4me | dansmith mriedem here's the conductor log where it explodes: http://logs.openstack.org/72/547072/6/check/openstack-ansible-functional-ubuntu-xenial/aa76783/logs/openstack/openstack1/nova/nova-conductor.log.txt.gz#_2018-03-05_18_07_21_754 | |
| 15:10:57 | odyssey4me | dansmith your comment makes sense I think, thanks - we may need some hand-holding to get that right, I'll defer to git-harry via review to ask for help if needed. | |
| 15:11:08 | dansmith | odyssey4me: ack | |
| 15:11:12 | odyssey4me | Thanks for the quick review! | |
| 15:11:15 | dansmith | np | |
| 15:13:21 | mriedem | dansmith: i left a question in there for clarification | |
| 15:14:28 | bauzas | disclaimer : I'm not full steam yet, in case people want to ping me some reviews | |
| 15:14:46 | bauzas | that said, if you'd like to see my comments, tell me it | |
| 15:22:28 | Spazmotic | Hey jaypipes, getting ready to head to bed, but just wanted to let you know I updated https://review.openstack.org/#/c/538415/ if you get some time this week. I'm sure you're pretty busy with work coming back from PTG :) | |
| 15:22:45 | Spazmotic | And with that, have a great night novaers.. i've been up way too long | |
| 15:22:49 | jaypipes | Spazmotic: yup, will review this afternoon. | |
| 15:22:53 | jaypipes | thx for th eping | |
| 15:23:01 | Spazmotic | No worries if you can't find the time sir. | |
| 15:23:04 | Spazmotic | Have a great day. | |
| 15:23:07 | jaypipes | ciao | |
| 15:23:55 | mriedem | Spazmotic: why isn't there a test for that bug fix? | |
| 15:24:53 | Spazmotic | I've put a fair amount of thought into that and was trying to think of how to test for a XenAPI fault being raised in such a specific situation. | |
| 15:26:12 | Spazmotic | Or in the case of testing that the assert did not run, ensureing it did not | |
| 15:26:21 | Spazmotic | ensuring* | |
| 15:27:02 | Spazmotic | Would love to hear your thoughts on it though. My mocking logic is not fantastic | |
| 15:27:12 | mriedem | maybe jianghuaw_ can help? | |
| 15:27:23 | Spazmotic | Yeah i've been wanting to sync back up with him since he got back. | |
| 15:33:13 | Spazmotic | The error thrown without the skip in place just comes from XenAPI and in a tight circumstance, not really a code error, so am still thinking of a good test condition I suppose. | |
| 15:34:36 | Spazmotic | And I suppose the real test should be to test the new feature of the skip in place, so not sure how to test that a method call that only asserts wasn't run hehe | |
| 15:37:21 | Spazmotic | Actually.. I think I Know.. will make a note | |
| 15:37:27 | mriedem | well, seems pretty clear to me, | |
| 15:37:35 | mriedem | test would raise an exception from _call_live_migrate_command, | |