| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-06 | |||
| 12:47:17 | sean-k-mooney | sahid: tap devices are not persited across reboots | |
| 12:47:36 | sean-k-mooney | they are created by libvirt/qemu when the vm starts | |
| 12:47:51 | sahid | oh yes you are right | |
| 12:48:14 | sean-k-mooney | but the ovsdb info is preserved across reboot so ovs is expecting it to exist but libvirt/qemu have not created it yet | |
| 12:49:15 | sahid | yes that is a possible case | |
| 12:49:30 | sean-k-mooney | sahid: anyway im going to approve the patch as it is for master and request you add a check for the interface type on backport as we technically support ovs older then 2.6 in ocata. is that ok with you? | |
| 12:51:21 | sahid | sean-k-mooney: ok so please take the time to ack it soon as possible | |
| 12:52:29 | sean-k-mooney | sahid: i have it open on another tab. i was currently reading neutron release notes to see if they required ovs 2.6+ but i could not find any assertion to that effect for ocata | |
| 12:53:00 | sean-k-mooney | i need to run to a meeting at 1 but ill try to ack it before then | |
| 12:54:17 | sahid | sean-k-mooney: yes actually using 2.5 looks really old | |
| 12:54:21 | sean-k-mooney | looking at osp 11 redhat shiped ovs 2.6 for the ocata release if i can validate that suse,mirantis and canonical also did the same then perhaps we can skip the check but that is up to the stable mainance team to decide | |
| 12:54:37 | sahid | sean-k-mooney: that would be the ideal | |
| 12:56:30 | sahid | stephenfin, sean-k-mooney can we work together to ensure that for newton all the major openstack dist are using OVS2.6 | |
| 12:57:24 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/550057 | |
| 12:58:14 | sahid | s/netwon/ocata | |
| 13:02:56 | sahid | sean-k-mooney: I'm thinking about something, the scenario you have indicated is not in relation with the patch | |
| 13:15:35 | sean-k-mooney | sahid: correct however that was the reason that https://github.com/openstack/nova/commit/33cc64fb817 was merged to resolve https://bugs.launchpad.net/nova/+bug/1270973 | |
| 13:15:36 | openstack | Launchpad bug 1270973 in OpenStack Compute (nova) "Remove and recreate interface if already exists" [Medium,Fix released] - Assigned to Aaron Rosen (arosen) | |
| 13:18:00 | sean-k-mooney | sahid: so your fix would be reverting that previous change. but that bug can nolonger happen after ovs 2.6 so its safe to revert the old change on any moderen openstack deployment | |
| 13:20:06 | sahid | sean-k-mooney: the fix will be backported for stable queens only - i think we are ok | |
| 13:21:41 | sean-k-mooney | oh yes well the addtionally check would only be required for stable/ocata if it was backported to ocata. for queens and pike the patch can be applied as is | |
| 13:30:48 | sahid | sean-k-mooney: i'm just going to backport it for stable/queens and stable/pike, I don't think we can backport the patch in 3 release whether it's not a security issue | |
| 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 | sahid | sean-k-mooney: seems reasonable | |
| 13:35:01 | stephenfin | I think that might have got lost in translation :) | |
| 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 | |