| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-09 | |||
| 13:57:20 | cdent | ✔ | |
| 13:59:04 | mriedem | i guess gerrit just died | |
| 13:59:17 | bauwser | oh yet | |
| 13:59:19 | bauwser | yeah | |
| 13:59:20 | bauwser | fun | |
| 13:59:39 | mriedem | sdague: just all i guess, i don't have a full list right now | |
| 14:02:01 | artom | mriedem, btw, continuing the transient/persistent domain discussion from last night | |
| 14:02:47 | artom | mriedem, you may be interested in what kashyap told me this morning | |
| 14:02:48 | artom | http://eavesdrop.openstack.org/irclogs/%23openstack-nova/latest.log.html | |
| 14:03:00 | artom | (Sorry I can't link to a specific line, but it's near the end) | |
| 14:05:07 | mriedem | ok | |
| 14:05:08 | melwitt | here's a link to a line http://eavesdrop.openstack.org/irclogs/%23openstack-nova/latest.log.html#t2017-06-09T12:59:43 | |
| 14:05:08 | mriedem | read it | |
| 14:05:30 | mriedem | artom: i'm out today in about 20 minutes, | |
| 14:05:35 | mriedem | this is my debug patch https://review.openstack.org/#/c/471494/ | |
| 14:05:43 | mriedem | in neutron which depends on a nova change that dumps debug info when we fail | |
| 14:05:54 | mriedem | interestingly it's survived a few rechecks without hitting hte issue | |
| 14:05:55 | mriedem | of course | |
| 14:31:56 | openstack | Launchpad bug 1696664 in OpenStack Compute (nova) "Order of the interfaces is not honored when using virt and SR-IOV interfaces" [Low,Confirmed] | |
| 14:31:56 | bauwser | vladikr: do we have some documentation that I can point to for NIC device tagging in order to mark https://bugs.launchpad.net/nova/+bug/1696664 as invalid ? | |
| 14:32:08 | bauwser | vladikr: I can point to the spec but it's not super handy | |
| 14:32:16 | bauwser | superdan: in case you know too ^ | |
| 14:32:37 | superdan | bauwser: not sure, ask artom | |
| 14:32:45 | vladikr | bauwser, I'm not aware of anything besides the spec.. | |
| 14:32:51 | superdan | I'm guessing maybe just the spec and the api-ref | |
| 14:33:31 | bauwser | fair enough, the api-ref is a valid document | |
| 14:33:45 | artom | bauwser, in the end, regardless of what magic we're able to achieve across the entire stack, the guest OS can still do whatever it wants | |
| 14:34:07 | artom | So even if we magically can preserve whatever order the user expects, the guest can say "lulz no, have it my way" | |
| 14:34:13 | bauwser | artom: that's the reason why you proposed tags, right? | |
| 14:34:37 | artom | bauwser, it's the reason tags came about, yeah | |
| 14:34:46 | bauwser | artom: I just want to explain to the bug reporter that he can lookup those tags instead of awaiting specific ordering | |
| 14:35:13 | bauwser | and FWIW, I'd even be in favor of removing the codepath that does the ordering now that we have that feature | |
| 14:35:26 | bauwser | because it makes false promises | |
| 14:36:13 | artom | bauwser, I'm not aware of any doc that promises preserved ordering | |
| 14:37:20 | bauwser | artom: that's worst, that's in code | |
| 14:37:39 | artom | bauwser, it's technically better, because it's easier for us to say "it's not supported" | |
| 14:37:46 | bauwser | which would mean that someone looking at the code could add some documentation | |
| 14:37:54 | bauwser | without getting full knowledge | |
| 14:38:10 | bauwser | artom: see my original comment on the bug | |
| 14:38:15 | bauwser | I was saying that | |
| 14:38:23 | bauwser | but mriedem pointed me the code | |
| 14:42:34 | artom | I'm pretty sure mriedem reads the code as bedtime stories :) | |
| 14:50:39 | kashyap | artom: melwitt: Another way to look at the transient / persistent is: | |
| 14:50:43 | kashyap | If you are going to manage the guest yourself (e.g. via `virt-manager`), you want persistent domains by default, so that even when the guest powers down, libvirt still remembers all the details, and can use those details to reboot the guest. | |
| 14:50:58 | kashyap | However, if you are using a higher-level application to manage guests (like Nova), you probably prefer transient guests, since all the smarts for managing the guests are tied to the cluster as managed by Nova, while libvirt management of persistent guests is local only to one host. | |
| 14:51:07 | kashyap | And lastly... | |
| 14:51:40 | kashyap | A change to a persistent guest is only made on the host where the guest is currently living -- but in a cluster setup, you want to make sure the change lives on, no matter which host in the cluster is currently running the guest; which is why Nova takes care of the configuration, and uses transient guests instead of letting libvirt store (potentially stale) information. | |
| 14:51:47 | kashyap | </EOM> | |
| 14:52:36 | artom | kashyap, aha! | |
| 14:52:43 | artom | That's very helpful, thanks! | |
| 14:53:26 | kashyap | Np; /me wonders if I should paste the above in a .txt file and put it on the web somewhere. I'm sure it's not the first time this came up | |
| 14:53:57 | artom | kashyap, the libvirt docs are pretty sparse on the "why" | |
| 14:54:03 | kashyap | Yeah, I hear you | |
| 14:54:14 | artom | They explain "what", but without the context you just gave, that's not very useful | |
| 14:55:13 | kashyap | I agree, it can be improved | |
| 14:55:42 | kashyap | artom: In other 'news', for upstream QEMU, I began writing a long document for its block operations. An HTML version - https://kashyapc.fedorapeople.org/virt/qemu/live-block-operations.html | |
| 14:56:08 | kashyap | It took a couple of months to slowly chip away at it | |
| 14:56:15 | kashyap | Still in review on upstream qemu-devel list | |
| 14:56:53 | openstackgerrit | Hironori Shiina proposed openstack/nova-specs master: Ironic: Cold migration support https://review.openstack.org/449155 | |
| 14:57:13 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform instance.resize_prep notification https://review.openstack.org/465081 | |
| 14:59:01 | artom | bauwser, your message to close the bug looks fine to me. | |
| 14:59:26 | artom | But perhaps you're right, we need to be clearer in the documentation that we don't make guarantees about nic ordering | |
| 15:02:02 | bauwser | artom: I can amend api-ref | |
| 15:02:14 | bauwser | well, if gerrit allows me... | |
| 15:04:23 | openstack | Launchpad bug 1696759 in OpenStack Compute (nova) "Inconsistent RabbitMQ messages after subnet update" [Undecided,New] | |
| 15:04:23 | bauwser | gibi: would love your insights on https://bugs.launchpad.net/nova/+bug/1696759 | |
| 15:05:59 | bauwser | gibi: and also, I was looking at a Launchpad tag for that one, can't find it, so will use 'notifications' | |
| 15:17:30 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Amend api-ref for multiple networks request https://review.openstack.org/472733 | |
| 15:22:58 | bauwser | artom: see https://review.openstack.org/472733 | |
| 15:23:03 | danpawlik | Hi. Why when I have different password for placement user as nova api has, nova-status upgrade check is raising an error? Is this normal? | |
| 15:25:38 | artom | bauwser, thanks for proposing that, left a suggestion :) | |
| 15:26:20 | artom | bauwser, if you want I can just write the thing myself | |
| 15:30:41 | stvnoyes | mriedem, johnthetubaguy, I finally got migrate working with the cinder v3. The review is here - https://review.openstack.org/#/c/463987/ , please take a look when you get a chance. thx. | |
| 15:30:55 | bauwser | artom: absolutely, flood is yours | |
| 15:31:29 | bauwser | artom: you're Canadian, at least living there, so your english skills are way better than mines | |
| 15:31:54 | bauwser | even if you're living in a very specific area where people speak way more French than we do | |
| 15:32:13 | bauwser | and related, I'll go on 'fin de semaine' soon | |
| 15:33:15 | artom | bauwser, bonne fin de semaine alors :) | |
| 15:33:46 | bauwser | ooooh, and *floor*, not flood | |
| 15:34:13 | artom | bauwser, I know, but we did get flooding in the periphery of Montreal not long ago, so you were kinda correct | |
| 15:34:32 | artom | If you'd said that to vladikr you'd have been 100% right ;) | |
| 15:34:37 | bauwser | orly? | |
| 15:34:38 | artom | Happily, his house was spared | |
| 15:34:53 | bauwser | oh yeah, I think I heard that | |
| 15:35:04 | vladikr | :) | |
| 15:37:17 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Remove custom comparison methods https://review.openstack.org/472285 | |
| 15:48:42 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Amend api-ref for multiple networks request https://review.openstack.org/472733 | |
| 15:52:28 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Return alternate allocation requests to scheduler https://review.openstack.org/471927 | |
| 16:10:29 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Return alternate allocation requests to scheduler https://review.openstack.org/471927 | |
| 16:11:30 | openstackgerrit | Merged openstack/nova master: Add earliest-version tags for stable branch renos https://review.openstack.org/469969 | |
| 16:16:05 | breton | hi | |
| 16:17:22 | ajay | i am seeing a failure in nova-compute creating resources providers for placement on ocata | |
| 16:17:24 | breton | what happens if notification https://github.com/openstack/nova/blob/5d95cb9dbca403790db4e9680919e6716fa5cb76/nova/compute/manager.py#L2092-L2094 fails due to rabbit failure for example? Will the instance status be set to "Failed"? | |
| 16:17:31 | ajay | Failed to create resource provider record in placement API for UUID eff80c6e-a087-458e-8821-8ae4a9f64387. Got 300: {"choices": [{"status": "SUPPORTED", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.compute+json;version=2"}], "id": "v2.0", "links": [{"href": "http://15.0.0.42:8778/v2/resource_providers", "rel": "self"}]}, {"status": "CURRENT", "media-types": [{"base": "application/json", "type": | |
| 16:17:50 | ajay | it seems like it is posting to version=2 even though all my nova endpoints are 2.1 | |
| 16:19:24 | ajay | anyone have an idea why this api incompatibility with placement | |
| 16:24:40 | cfriesen | is there a novaclient command that does a GET on /servers/list ? | |
| 16:27:23 | cfriesen | whoops, I mean a GET on /servers | |
| 16:30:23 | cfriesen | answered my own question..." nova list --minimal" will do it. | |
| 16:39:45 | superdan | ajay: placement is a different api versioning scheme | |