| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-24 | |||
| 17:12:17 | efried | yeah, see, that's what seems not to be happening anymore in a certain code path for us. | |
| 17:15:38 | openstackgerrit | melanie witt proposed openstack/nova stable/queens: DNM: testing the ceph job https://review.openstack.org/563175 | |
| 17:16:02 | gibi | Kevin_Zheng: I have an approved bp that could be interesting for you if you have time: https://blueprints.launchpad.net/nova/+spec/add-full-traceback-to-error-notifications | |
| 17:17:11 | gibi | Kevin_Zheng: it is totally OK if you don't have time either, I just wanted advertise the opportunity | |
| 17:20:01 | jroll | melwitt: dansmith: jaypipes: thanks for the help, btw :) | |
| 17:20:21 | openstackgerrit | Merged openstack/nova master: Add periodic task to clean expired console tokens https://review.openstack.org/325381 | |
| 17:20:40 | jaypipes | jroll: I feel like I did nothing but add confusion to the situation, honestly. | |
| 17:21:04 | jroll | jaypipes: thanks for trying to help? :P | |
| 17:21:05 | dansmith | jroll: jaypipes needs a hug | |
| 17:21:12 | jroll | or a pug | |
| 17:21:20 | melwitt | pug hug | |
| 17:21:26 | dansmith | or a pug hug | |
| 17:22:23 | TheJulia | Pug hugs sound far better than cat cuddles... and walking away bleeding | |
| 17:24:23 | jroll | jaypipes: do aussies also cheer you up? https://i.imgur.com/Yswxtpy.jpg | |
| 17:24:32 | melwitt | heh. not our cat. we think he might be part ragdoll | |
| 17:24:34 | dansmith | jroll: I think he only likes ugly dogs | |
| 17:24:42 | jroll | ha, fair | |
| 17:25:05 | jaypipes | jroll: ++ aussie's are a good cheerup. | |
| 17:25:11 | jroll | :) | |
| 17:25:18 | melwitt | jroll: that's adorbz | |
| 17:25:26 | dansmith | jaypipes: but. but.. their eyeballs are fully contained within their heads... | |
| 17:25:53 | jroll | melwitt: thanks, make sure you pass it along to james :) | |
| 17:25:59 | TheJulia | It is side conversations like ^^^ why I love this community | |
| 17:26:27 | melwitt | jroll: forwarding it now | |
| 17:27:03 | jaypipes | dansmith: details, details... | |
| 17:27:20 | jaypipes | dansmith: they are furry, fluffy and perfect. | |
| 17:27:31 | jaypipes | dansmith: even if they are missing googly eyes. | |
| 17:27:45 | jaypipes | heh | |
| 17:32:51 | TheJulia | jroll: Any thoughts on continuing your poc forward or just rewrite mine? | |
| 17:33:23 | jroll | TheJulia: I could do it, or you could take it over, or you could rewrite yours, whatever you'd like to do :) | |
| 17:34:56 | TheJulia | I've got it on the brain so I'll pickup yours and continue it along | |
| 17:36:23 | jroll | awesome, thanks! happy to review if needed | |
| 17:36:43 | jroll | TheJulia: fyi I probably picked up your bug from patchset 1 where you needed the patch wrapped in [] | |
| 17:37:27 | TheJulia | my brain is currently trying to think of any other ways we could be leaking vifs and thus blocking future deploys outside of tearing down an instance and I'm not thinking of any | |
| 17:37:39 | openstackgerrit | Jay Pipes proposed openstack/os-traits master: Add compute capabilities traits https://review.openstack.org/546713 | |
| 17:37:58 | TheJulia | jroll: easy fix :) | |
| 17:38:11 | jaypipes | artom_, gibi, efried: addressed the rewording in https://review.openstack.org/#/c/546713/. | |
| 17:38:14 | melwitt | mriedem: why do you think we can't drop the API code until T? I thought once all computes are upgraded to rocky, then things are guaranteed to all be using the database backend, so removal would be in Stein? https://review.openstack.org/#/c/325414/31/nova/compute/api.py@3613 | |
| 17:38:25 | jroll | TheJulia: yep, just a heads up so you don't wait an hour for CI to find it :) | |
| 17:39:14 | gibi | jaypipes: thanks, +2 | |
| 17:39:31 | mriedem | melwitt: i might have been overthinking it | |
| 17:40:18 | melwitt | k, just trying to make sure there's not something I'm missing | |
| 17:40:33 | mriedem | replied to clarify | |
| 17:41:16 | melwitt | cool thanks | |
| 17:43:32 | sean-k-mooney | melwitt: sorry i was in meeting for the last 4 hours. did ye resolve the issue ye were having? | |
| 17:44:11 | melwitt | sean-k-mooney: yeah, I think so. we were talking about, when is a port guaranteed to have an IP allocated to it? maybe never, but it sounded like after host binding it has to? | |
| 17:45:46 | openstackgerrit | Merged openstack/nova master: Extract generate_hostid method into utils.py https://review.openstack.org/555282 | |
| 17:45:52 | sean-k-mooney | melwitt: right so with multi segment, l3 routed networks the allocation of the ip happens only when the port is bound to a specific host. for the general case the port will get an ip when it is created but you can have ports that only have mac adresses | |
| 17:46:36 | melwitt | sean-k-mooney: gotcha. thanks | |
| 17:46:37 | sean-k-mooney | melwitt: so after you do port binding it should have an ip if it is connected to a neutron network that has a subnet | |
| 17:47:28 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Network bandwidth resource provider https://review.openstack.org/502306 | |
| 17:49:26 | melwitt | sean-k-mooney: okay, so it's not ever necessarily guaranteed (would a neutron network ever not have a subnet?). we were looking at some code in the ironic driver where they need to get the IP in order to hand it to the volume connector (some volume backends require the IP before attaching). and we were wondering, at what point could one reliably query for the IP | |
| 17:50:42 | sean-k-mooney | melwitt: neutron allows your to have interfaces with no ips. nova used to require one for a neutron port to be used with an vm/instance but that requrement was removed. | |
| 17:51:03 | sean-k-mooney | melwitt: the reason it was removed was to cater for non ip networking e.g. infinaband over ethernet | |
| 17:51:07 | melwitt | I see | |
| 17:52:27 | sean-k-mooney | melwitt: it sound like in the ironic case there is a hard requirement for an ip presuable you are using it to configre iscsi targest for the baremtal not or something like that? | |
| 17:53:57 | melwitt | sean-k-mooney: yeah must be a hard requirement. it's already doing it like this https://review.openstack.org/#/c/468353/19/nova/virt/ironic/driver.py but yeah need the IP to set in the volume connector | |
| 17:55:07 | sean-k-mooney | in general l2 only connectivity is not common in neutron so this is an extream edgecase. | |
| 17:55:33 | melwitt | and the problem was that they have to do their equivalent of "plug_vifs" first in order to get the IP and that's happening outside their node reserve lock and there are races happening. so at first we were talking about "can we get the IP before plugging the vif" but it ended up not mattering and the solution needs to be to reserve the node first before doing anything with the networking | |
| 17:58:28 | openstackgerrit | Merged openstack/nova master: Address nits in I00d29e9fd80e6b8f7ba3bbd8e82dde9d4cb1522f https://review.openstack.org/561493 | |
| 18:00:36 | sean-k-mooney | from a ironic perspective i think its prefectly resonable to scope the cinder volume support to jsut instance with ips at a first pass. volumes attached over infinaband is something in the storage space where we might not have ips but that is less common. | |
| 18:01:35 | melwitt | yeah, that's what they've done | |
| 18:05:10 | openstackgerrit | Merged openstack/nova stable/ocata: Add regression test for persisted RequestSpec.retry from failed resize https://review.openstack.org/560162 | |
| 18:05:17 | openstackgerrit | Merged openstack/nova stable/ocata: Don't persist RequestSpec.retry https://review.openstack.org/560167 | |
| 18:05:23 | openstackgerrit | Merged openstack/nova stable/ocata: only increment disk address unit for scsi devices https://review.openstack.org/561613 | |
| 18:09:20 | efried | cdent: yt? | |
| 18:09:30 | cdent | efried: hi, yup | |
| 18:09:56 | efried | cdent: Good evening to you. Do you know of any reason Instance.uuid would or would not respond to isinstance(str) ? | |
| 18:11:09 | cdent | I read you talking about that a bit earlier, but didn't chase it. Is it showing up in a particular piece of code that I can poke at? Have you been able to find out what type it is when that happens? Or is it a racey thing that you've got no easy replication for? | |
| 18:13:30 | sean-k-mooney | efried: cdent jaypipes-lunch i need to run very soon but was a decision reached on the mailing list of how to proceed with resouce provider groups? | |
| 18:14:11 | efried | sean-k-mooney: You mean whether numbered groups are separate by default or unrestricted? | |
| 18:14:25 | cdent | sean-k-mooney: I think you mean this https://review.openstack.org/#/c/562687/ | |
| 18:14:28 | sean-k-mooney | efried: yes. last i read was matt suggesting that its explcit | |
| 18:14:59 | efried | sean-k-mooney: Yup, what cdent said - that guy has (all the links to) all the info you need. | |
| 18:15:30 | efried | cdent: This is what I'm chasing down: http://184.172.12.213/58/557958/10/check/nova-out-of-tree-pvm/c1d7e99/logs/n-cpu.txt.gz?#_Apr_20_08_51_16_452651 | |
| 18:15:38 | sean-k-mooney | cdent: thanks im out of office tomrow but ill print out the current version and review tomrow. | |
| 18:15:41 | cdent | thanks efried | |
| 18:15:55 | sean-k-mooney | efried: im glad ye found a path forward | |
| 18:15:56 | cdent | woah, colors finally merged | |
| 18:16:30 | sean-k-mooney | cdent: colors? | |
| 18:16:30 | efried | cdent: No, I think that's just because it's in our CI env and I have that patched in there (cause that's where I was testing it) | |
| 18:17:07 | efried | cdent: But you should definitely tell everybody how much you like it in https://review.openstack.org/524744 so they might merge it. | |
| 18:17:33 | cdent | oh, sorry, didn't recognize that was your ci efried | |
| 18:17:49 | openstack | Launchpad bug 1765748 in OpenStack Global Requirements "webob-1.8.1 breaks projects" [High,In progress] - Assigned to Matthew Thode (prometheanfire) | |
| 18:17:49 | melwitt | cdent: I had wanted to bring this bug to your attention, in case you might have some idea why the test_wsgi stuff would fail with webob 1.8.1 https://bugs.launchpad.net/nova/+bug/1765748 | |
| 18:18:23 | efried | cdent: Anyway, the deal here is that powervm has a utility method that accepts either an integer ID or a UUID. It detects which one it is and then behaves accordingly. The code that does that hasn't changed in yeeears. | |
| 18:18:47 | efried | The code path that calls it is when we're disconnecting a disk, which (I think) also hasn't changed in yeeeears. | |
| 18:19:20 | sean-k-mooney | melwitt: the stack trace look like one that we get when we need to cap a dependcy in upper constrataint because of an incompatible change | |
| 18:19:35 | cdent | melwitt: hmmm. webob often breaks such stuff, but that looks like a bad mock? is there an in-nova example? | |
| 18:19:37 | efried | cdent: But suddenly on Friday afternoon, our CI started failing with that error. I don't actually know what type it thinks it has in there - just know that isinstance(str) is failing where it didn't before. | |
| 18:19:55 | mriedem | sean-k-mooney: totally unrelated to what you're talking about, but i'm a bit lost in https://review.openstack.org/#/c/551370/16/nova/virt/libvirt/migration.py@229 and looking for some feedback when you get a chance | |
| 18:20:03 | cdent | efried: still parsing | |
| 18:21:03 | sean-k-mooney | mriedem: in the generation of the updated xml for the vif on the destination node | |
| 18:21:45 | mriedem | sean-k-mooney: yeah, i'm looking at how _update_volume_xml works and it's basically an update of any volume disks on the source using the destination block device config | |
| 18:21:55 | mriedem | it does that by keying off the volume 'serial' which is the volume id | |
| 18:22:09 | mriedem | we don't have something like that for the interface config in a domain xml | |
| 18:22:25 | sean-k-mooney | mriedem: we could posibly key of the interface mac adress | |
| 18:22:28 | mriedem | i'm not really even sure if i should be updating the interface xml entries, or replacing them | |
| 18:23:01 | mriedem | i.e. i'm trying to handle the case that you're live migrating from a host using ovs to a host using ovn, or linuxbridge, or vhostuser, et al | |
| 18:23:06 | sean-k-mooney | that said im not sure if we can have a vm with two port with the same mac.. | |