| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-20 | |||
| 15:10:10 | jmlowe | I'm starting to form the opinion that evernything except get's should be retried | |
| 15:10:59 | mriedem | jmlowe: so how about we ease into this hot tub by you figuring out if (1) are those bugs duplicates and (2) post patches for them (assuming they overlap with what you've already patched locally | |
| 15:11:12 | mriedem | and then follow up with a bug report for the bdm one | |
| 15:11:39 | mriedem | i have to run, but that's my advice to get started | |
| 15:11:47 | mriedem | cezary_zukowski: i'd have to look but can't right now | |
| 15:14:55 | mriedem_afk | cezary_zukowski: shows hosts within an az https://developer.openstack.org/api-ref/compute/?expanded=get-detailed-availability-zone-information-detail#get-detailed-availability-zone-information | |
| 15:15:41 | mriedem_afk | cezary_zukowski: so try this https://docs.openstack.org/python-novaclient/latest/cli/nova.html#nova-availability-zone-list | |
| 15:16:02 | mriedem_afk | or openstack availability zone list --compute | |
| 15:16:06 | mriedem_afk | https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/availability-zone.html#availability-zone-list | |
| 15:16:09 | cezary_zukowski | mriedem_afk: Many thanks | |
| 15:16:29 | mriedem_afk | you'll have to be admin by default to get host info out of those | |
| 15:16:38 | cezary_zukowski | okay | |
| 15:37:24 | openstackgerrit | Merged openstack/nova master: conf: Convert 'live_migration_inbound_addr' to HostAddressOpt https://review.openstack.org/456573 | |
| 15:37:37 | openstackgerrit | Merged openstack/nova master: doc: Rework 'resize' user doc https://review.openstack.org/625878 | |
| 16:00:46 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268 | |
| 16:00:47 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Fill the RequestGroup mapping during schedule https://review.openstack.org/619528 | |
| 16:00:47 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Calculate RequestGroup resource provider mapping https://review.openstack.org/616239 | |
| 16:00:47 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Extend RequestGroup object for mapping https://review.openstack.org/619527 | |
| 16:00:48 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Recalculate request group - RP mapping during re-schedule https://review.openstack.org/619529 | |
| 16:00:48 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Pass resource provider mapping to neutronv2 api https://review.openstack.org/616240 | |
| 16:00:49 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317 | |
| 16:00:49 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send RP uuid in the port binding https://review.openstack.org/569459 | |
| 16:00:50 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reject networks with QoS policy https://review.openstack.org/570079 | |
| 16:00:50 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reject interface attach with QoS aware port https://review.openstack.org/570078 | |
| 16:00:51 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove port allocation during detach https://review.openstack.org/622421 | |
| 16:00:52 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add pf_interface_name tag to passthrough_whitelist https://review.openstack.org/625311 | |
| 16:00:52 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310 | |
| 16:00:52 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Refactor PortResourceRequestBasedSchedulingTestBase https://review.openstack.org/624080 | |
| 16:00:53 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543 | |
| 16:28:25 | openstackgerrit | Merged openstack/os-vif master: Change openstack-dev to openstack-discuss https://review.openstack.org/621825 | |
| 16:37:55 | cfriesen | sean-k-mooney_: you around? could you take another look at jackding's cpu model spec? | |
| 16:38:15 | sean-k-mooney_ | technically im on vacation but yes | |
| 16:38:26 | sean-k-mooney_ | i can take a look before i sign off | |
| 16:39:00 | sean-k-mooney_ | i have a pep8 issue on my own spec so i need to respin it again before i disapaer | |
| 16:42:44 | adrianc | sean-k-mooney_: Enjoy your vacation :) coming back after new year ? | |
| 16:42:48 | gibi | mriedem: I'm soon leave for the year. I don't know if you see the discussion in the ML thread about the feature flag. There are some complications. I introduced one possible solution to the patch that enables the boot with bandwidth | |
| 16:43:05 | sean-k-mooney_ | adrianc: ya the 3rd | |
| 16:43:31 | gibi | mriedem: anyhow I'm sure we will continue talking about next year. (I'm back on 7th Jan) | |
| 16:44:21 | sean-k-mooney_ | i may be online intermitently and take some time in excange after m2 if it makes sese but effectly im away for the next 2 weeks | |
| 16:48:55 | mriedem | gibi: i haven't gone through the ML thread yet, but i will, | |
| 16:49:13 | mriedem | gibi: in general i'm not supportive of feature flags in the API (smells like config-driven API behavior) | |
| 16:49:26 | mriedem | unless it's policy or something | |
| 16:49:38 | mriedem | gibi: coincidentally, i will be on vacation the week of jan 7 :) | |
| 16:50:53 | gibi | mriedem: if you leave me reasonable suggestion I can try to implement that on the week of Jan you are off | |
| 16:51:30 | mriedem | i'll make it your xmas gift | |
| 16:51:35 | gibi | mriedem: thanks | |
| 16:51:37 | gibi | :) | |
| 17:03:41 | openstack | Launchpad bug 1642537 in OpenStack Compute (nova) "finish_resize fails with DBDeadlock on migrations table" [Undecided,Confirmed] | |
| 17:03:41 | mriedem | jmlowe: i duped one of those bugs against the other so it's just https://bugs.launchpad.net/nova/+bug/1642537 now | |
| 17:03:43 | mriedem | which is migrate_update | |
| 17:13:05 | openstackgerrit | Jack Ding proposed openstack/nova-specs master: Select cpu model from a list of cpu models https://review.openstack.org/620959 | |
| 17:28:51 | mriedem | yonglihe: cfriesen: comments in the show server numa topo spec https://review.openstack.org/#/c/612256/ | |
| 17:29:52 | mriedem | seems i've asked some of the same questions bauzas did, i.e. wanting details about how the information is going to be retrieved, which will definitely impact performance | |
| 17:30:37 | cfriesen | mriedem: thanks for taking a look. | |
| 17:32:16 | sean-k-mooney_ | cfriesen: https://review.openstack.org/#/c/620959 looks fine to me. its a short spec but a small feature so i think its fine | |
| 17:35:49 | sean-k-mooney_ | so nowone has changed the laws of number lately 78 is still less the 79... | |
| 17:36:29 | sean-k-mooney_ | my spec failed pep8 in the gate on a line lenght issue where the line is actully 78 colums wide and it passes localy. | |
| 17:40:33 | sean-k-mooney_ | ok never mind i was looking at the previous patchset locally | |
| 17:41:57 | openstackgerrit | sean mooney proposed openstack/nova-specs master: Add spec for sriov live migration https://review.openstack.org/605116 | |
| 17:43:23 | sean-k-mooney_ | cfriesen: by the way i dont know if you have seen https://review.openstack.org/#/c/605116 but hopefully it is to your likeing also. | |
| 17:43:40 | openstackgerrit | Merged openstack/nova master: Remove legacy RequestSpec compat from conductor unshelve_instance https://review.openstack.org/625706 | |
| 17:43:48 | openstackgerrit | Merged openstack/nova master: Remove legacy RequestSpec compat from conductor rebuild_instance https://review.openstack.org/625707 | |
| 17:45:58 | cfriesen | sean-k-mooney: oooh, fun. will take a look. hadn't seen it yet | |
| 17:48:20 | sean-k-mooney | cfriesen: adrianc has working poc code up for macvtap. i will hopfully get the vnic_type=direct|direct-physical code up in early january | |
| 17:49:50 | cfriesen | for direct/direct-physical how does that even work in the guest kernel? does it see a device detach/attach? | |
| 17:50:15 | sean-k-mooney | yep exactly as it does for suspend | |
| 17:50:51 | sean-k-mooney | if you want to prevent loss of netwroking you have to create a bond in the guest with a livemigratable port | |
| 17:51:11 | sean-k-mooney | that can either be a macvtap sriov port or a vswitch port | |
| 17:51:37 | cfriesen | I guess you'd need to have a hook in the end-user app to detect the port changes and check the tags on the newly-attached device | |
| 17:51:50 | cfriesen | to figure out which ports should be used for what | |
| 17:52:29 | sean-k-mooney | ya i have left that as an exercise for the end user. i dont want to add it to the spec as there are a few ways to do it | |
| 17:52:47 | cfriesen | sean-k-mooney: arguably you'll lose networking anways in some cases since vswitch/macvtap won't be able to handle the same throughput | |
| 17:52:54 | cfriesen | right, not needed in spec | |
| 17:53:16 | sean-k-mooney | ya that is ture it woudl be degraded | |
| 17:53:35 | sean-k-mooney | the intent is to keep bgp peering session ectra alive | |
| 17:53:46 | sean-k-mooney | rather then nessisarlly maintain kpis | |
| 17:53:59 | cfriesen | I guess you'd need some sort of prioritization to drop the less important stuff while letting the important stuff through | |
| 17:54:23 | sean-k-mooney | you could do that with dscp perhaps but yes. | |
| 17:55:05 | sean-k-mooney | you are always better to drain instance before moving them when they are vnf but its less impactful then cold migration | |
| 17:55:49 | cfriesen | I assume this would depend on the stuff artom is doing for resource tracking over live migration? | |
| 17:55:55 | sean-k-mooney | there are some technologes under developement that will replace sriov in the future which do supprot livemigration natively | |
| 17:56:04 | sean-k-mooney | cfriesen: not really | |
| 17:56:09 | sean-k-mooney | its related | |
| 17:56:15 | sean-k-mooney | but there is not direct dependcy | |
| 17:56:34 | cfriesen | both of them are adding resource claims in the "check can live migrate" code, and both are modifying XML on the source | |
| 17:56:34 | sean-k-mooney | cfriesen: artom is looking jsut at the numa aspect | |
| 17:56:53 | sean-k-mooney | yes they are | |
| 17:57:14 | sean-k-mooney | well actull we dont ned to mofiy the xml for the sriov case | |
| 17:57:24 | sean-k-mooney | in macvtap the code already exits to handel it | |
| 17:57:40 | sean-k-mooney | for direct mode we do a detach and attach before/after the migration | |
| 17:57:46 | sean-k-mooney | so the code is there for that also | |
| 17:58:04 | cfriesen | the guest XML to reflect the host PCI address on the destination" | |
| 17:58:04 | cfriesen | the spec says "second, nova does not modify | |
| 17:58:41 | sean-k-mooney | correct | |
| 17:59:03 | sean-k-mooney | but the ording is imporant | |
| 17:59:06 | cfriesen | okay, I guess you could view the attach after the migration as modifying the xml. :) | |
| 17:59:22 | sean-k-mooney | yes it is in a way | |
| 18:00:02 | sean-k-mooney | its is not modifing it in a sense that the fuction that normally modify the xml on migration will not be modifying the xml to do the detach/attach | |
| 18:00:25 | sean-k-mooney | its basically detach, migrate then attach | |
| 18:00:44 | sean-k-mooney | the actul migration happens with out the sriov interfaces | |