| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-15 | |||
| 10:58:58 | kashyap | sean-k-mooney: Yeah, can imagine (on MTTCG) | |
| 10:59:00 | sean-k-mooney | kashyap: :( | |
| 10:59:52 | kashyap | sean-k-mooney: I don't think it's (no security guarantees for TCG) an issue for us: as the upstream CI isn't running any real workloads in the L2 | |
| 10:59:59 | sean-k-mooney | you can do it today by using a custom cpu_model + setting the machine type and qemu backend | |
| 11:00:15 | sean-k-mooney | kashyap: ya | |
| 11:00:22 | kashyap | (So we're good, there.) | |
| 11:00:39 | sean-k-mooney | the reason i went for qemu64 was to make sure it could run on all the ci cloud providers | |
| 11:00:45 | sean-k-mooney | event the xen based ones | |
| 11:01:05 | sean-k-mooney | and it should be supported by mttcg as it uses the smallest feature set | |
| 11:02:59 | sean-k-mooney | stephenfin: by the way looking at https://review.openstack.org/#/c/652197/7/playbooks/nfv/nfv.yaml can you think of an epa/numa feature i have missed beyond 2 numa nodes? | |
| 11:04:03 | sean-k-mooney | stephenfin: im going to test ovs-dpdk in a different job | |
| 11:06:54 | openstackgerrit | Merged openstack/nova stable/stein: Adding tests to demonstrate bug #1821824 https://review.openstack.org/649600 | |
| 11:06:56 | openstack | bug 1821824 in OpenStack Compute (nova) stein "Forbidden traits in flavor properties don't work" [High,In progress] https://launchpad.net/bugs/1821824 - Assigned to Eric Fried (efried) | |
| 11:29:36 | openstackgerrit | Merged openstack/nova stable/stein: Fix bug preventing forbidden traits from working https://review.openstack.org/649601 | |
| 11:30:17 | sean-k-mooney | :) ^ | |
| 11:31:13 | sean-k-mooney | cool its already proposed to be backported to rocky as well :) | |
| 11:54:31 | openstackgerrit | Merged openstack/python-novaclient stable/stein: Add test for console-log and docs for bug 1746534 https://review.openstack.org/651925 | |
| 11:54:33 | openstack | bug 1746534 in python-novaclient "encoding error when doing console-log" [High,Fix released] https://launchpad.net/bugs/1746534 - Assigned to Thomas Goirand (thomas-goirand) | |
| 12:14:10 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Server move operations with ports having resource request https://review.openstack.org/652608 | |
| 12:35:57 | kashyap | gibi: Does this require a Blueprint (much less a "spec"): https://bugs.launchpad.net/nova/+bug/1789868 | |
| 12:35:58 | openstack | Launchpad bug 1789868 in OpenStack Compute (nova) "RFE: Add a virtio-rng device to Nova instances by default" [Medium,In progress] - Assigned to s10 (vlad-esten) | |
| 12:37:02 | kashyap | I'd actually classify it as a "bug". But, whatever :-) (We already have a patch up for it, though: https://review.openstack.org/#/c/616603/) | |
| 12:46:16 | gibi | kashyap: I'm fine going with that bug report | |
| 12:46:25 | kashyap | gibi: Ah, okay, then. | |
| 12:47:20 | gibi | kashyap: just a question. Could this change cause that on guest can deplete the enthropy pool of the host and therefore cause troubles on the host or in other guests? | |
| 12:47:28 | kashyap | Wasn't sure if the 'process hammer' would come to bite me in the behind ... | |
| 12:47:40 | gibi | kashyap: at least not my process hammer... | |
| 12:47:48 | kashyap | (Heh) | |
| 12:47:58 | kashyap | gibi: No, it won't. But let me quadruple-check with the RNG experts | |
| 12:52:42 | kashyap | gibi: Confirmed: One guest can't do that. | |
| 12:52:54 | kashyap | Where "that" == deplete the entropy pool of the host | |
| 12:55:30 | gibi | kashyap: OK. thanks | |
| 13:04:00 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add TODO to remove function attribute https://review.openstack.org/652649 | |
| 13:05:10 | stephenfin | gibi: If you have a chance, could you look at https://review.openstack.org/#/c/651302/1/nova/objects/instance.py and see if I'm doing anything particular wrong? | |
| 13:07:57 | kukacz | hi, I wonder if nova handles situation of live-migrating an instance with config drive from rbd-backed compute host to file-backed compute host and vice versa? it seems I'm stuck in Ocata with instance resized from rbd-backed to raw-backed compute node, not willing to live-migrate in the other direction | |
| 13:09:00 | kukacz | it's a volume-booted instance. the issue is about config drive | |
| 13:19:37 | gibi | stephenfin: replied to the notification part. I wasn't to helpful, sorry. | |
| 13:19:53 | stephenfin | gibi: Neither was I so that makes two of us. Thanks :) | |
| 13:21:22 | gibi | stephenfin: I think you need dansmith for this | |
| 13:37:46 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Handle unsetting '[DEFAULT] dhcp_domain' https://review.openstack.org/652662 | |
| 13:37:46 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Undeprecate and move the 'dhcp_domain' option https://review.openstack.org/480616 | |
| 13:43:48 | efried | boxiang: Do you mind if I do a quick edit of https://review.openstack.org/#/c/645458/ for grammar? | |
| 13:51:08 | mriedem | lyarwood: questions in your swap volume migration_status patch https://review.openstack.org/#/c/637224/ | |
| 13:51:16 | mriedem | lyarwood: looks like there could be some weird edge cases | |
| 13:58:56 | mriedem | efried: please don't since there are major issues now in that spec | |
| 13:59:10 | mriedem | i.e. persisting RequestSpec.requested_destination now | |
| 13:59:21 | efried | mriedem: Yup, Above comment was before those came in. So now I'll just mark up the issues so boxiang can fix them on the next spin. | |
| 13:59:21 | mriedem | please dear sweet baby jesus in heaven no | |
| 13:59:28 | boxiang | efried: ok | |
| 13:59:44 | efried | mriedem: Did you see the discussion between boxiang and alex_xu in PS13 on persisting? | |
| 13:59:50 | mriedem | yes, and i disagree | |
| 13:59:52 | mriedem | i'm commenting | |
| 14:00:01 | cdent | placement meeting in now ish in #openstack-meeting-alt | |
| 14:00:17 | mriedem | i'm sure dansmith is also not going to be cool with starting to persist RequestSpec.requested_destination now | |
| 14:01:06 | alex_xu | mriedem: we persistent the requested_desitnation now | |
| 14:01:24 | mriedem | alex_xu: no we don't | |
| 14:01:39 | mriedem | if you mean force_hosts/force_nodes, yes, and that's likely a mistake | |
| 14:01:40 | alex_xu | so why we reset the requested_destination when migration? | |
| 14:01:46 | mriedem | that's not requested_destination | |
| 14:01:53 | mriedem | there is literally a field called requested_destination, | |
| 14:02:04 | mriedem | but that's not what reset_forced_destinations resets | |
| 14:02:25 | mriedem | reset_forced_destinations exists solely because we made the mistake of persisting force_hosts/force_nodes | |
| 14:02:38 | boxiang | mriedem: the requestec_destination of request spec is always null in db now? | |
| 14:02:40 | alex_xu | oh... | |
| 14:03:46 | mriedem | i've commented if you want details and history/examples https://review.openstack.org/#/c/645458/ | |
| 14:03:52 | mriedem | but i've been working on fixing these bugs for a long time now | |
| 14:03:59 | mriedem | so i don't really want to undo that work here | |
| 14:04:54 | alex_xu | ok, if so, I agree with that, that is what i'm thinking initial until I missed read reset_forced_destinations method | |
| 14:05:03 | mriedem | that method is a hack | |
| 14:05:09 | mriedem | to workaround persistence we shouldn't be doing | |
| 14:05:29 | alex_xu | but I'm pretty ensure we can migration the instance again without the initial forced host | |
| 14:05:59 | mriedem | yes we can because of reset_forced_destinations | |
| 14:06:17 | mriedem | otherwise you couldn't ever evacuate or live migrate a forced host/node server | |
| 14:06:18 | alex_xu | without the initial of requested_destination :) | |
| 14:06:33 | alex_xu | yes | |
| 14:08:07 | mriedem | the main concern / justification i saw for persisting requested_destination in this spec was for the rebuild from cell0 case, | |
| 14:08:27 | mriedem | but i think i've already pointed out things in that rebuild from cell0 spec that the user will lose from the initial server create if they rebuild from cell0 | |
| 14:08:45 | mriedem | because the rebuild API doesn't match the server create parameters 1:1 | |
| 14:09:25 | mriedem | https://review.openstack.org/#/c/648686/1/specs/train/approved/enable-rebuild-for-instances-in-cell0.rst@72 | |
| 14:10:35 | alex_xu | mriedem: yes, agree with that. so that should be resolved by rebuild spec, right? | |
| 14:11:04 | alex_xu | or you want to process in this spec | |
| 14:11:38 | alex_xu | at least, there need a way to persistent requested_destination for the fail boot instance | |
| 14:11:47 | mriedem | alex_xu: i really don't want to talk about rebuild from cell0 in *this* spec :) | |
| 14:11:56 | alex_xu | mriedem: cool :) | |
| 14:12:05 | mriedem | "there need a way to persistent requested_destination for the fail boot instance" is debateable | |
| 14:12:23 | alex_xu | ha | |
| 14:12:36 | mriedem | i agree with your assertion in boxiang's spec that we should just say you can move the server even if you requested that it was built on a specific host | |
| 14:12:44 | mriedem | the rest is implementation detail | |
| 14:13:14 | alex_xu | ok, thanks | |
| 14:19:03 | mriedem | restricted to rebuild from cell0 cases | |
| 14:19:03 | mriedem | alex_xu: i think we can cross the rebuild from cell0 bridge for this later if needed, i.e. we could either add the host/hypervisor_hostname parameters to the rebuild api to mirror the server create api (i don't love that idea) or we could do something like store the requested destination in the instance system_metadata when burying it in cell0, and then on rebuild from cell0, use those values and wipe the system metadata so i | |
| 14:21:01 | mriedem | rebuild from cell0 is definitely going to have weird corner cases like this since the rebuild api doesn't mirror the server create api | |
| 14:21:24 | mriedem | alex_xu: btw, are you feeling better? | |
| 14:21:40 | alex_xu | mriedem: yes, like the system_metadata better than the change rebuild API also | |
| 14:22:31 | alex_xu | my initial thoughts is persistent the requested_destination, and reset it when we spawn successful, but I see now, you will hate that :) | |
| 14:22:45 | alex_xu | it is urgly indeed | |
| 14:22:59 | mriedem | my sysmeta + rebuild from cell0 idea isn't much different | |
| 14:23:24 | mriedem | but RequestSpec.requested_destination specifically is off limits for persisting i think - the code already explicitly does not persist it | |
| 14:25:32 | alex_xu | yea | |
| 14:25:40 | alex_xu | at least no better idea yet | |