Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-02-05
15:36:09 efried sean-k-mooney: I don't think so. The data type per se isn't changing.
15:36:15 sean-k-mooney efried: as in i dont think we are allowed to chagne types of fields in OVO
15:36:30 efried sean-k-mooney: All existing in-tree consumers use a string to assign the field
15:37:27 sean-k-mooney that is not my concern im wonderign how this will work during an upgrade
15:38:12 sean-k-mooney e.g. if you had an old api node and a new compute
15:38:48 sean-k-mooney i guess that shoudl not be and issue as you should upgrade your api and condocutor before the computes
15:38:59 sean-k-mooney at least for majour upgrades
15:39:00 efried adding an enum value doesn't make that better though, right?
15:39:08 efried still have the same problem
15:39:42 efried if you receive an object and it has a value you don't recognize in that field, you're borked either way.
15:40:00 efried but at least making it a string field will avoid that problem in the future.
15:40:02 sean-k-mooney well you would need to handel it in the object make compatioble function
15:40:07 sean-k-mooney when you are downleveling it
15:40:55 sean-k-mooney ya im just wondering if we shoudl rename it to driver_name when we make it a sting
15:42:47 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Fix legacy-grenade-dsvm-neutron-multinode-live-migration https://review.openstack.org/634962
15:42:50 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543
15:42:54 efried I'm not an ovo expert by any means. If that's necessary, so be it.
15:43:59 sean-k-mooney efried: well i usuall check with dansmith for these kindo fo things. but in the past he has alswas asked if i am changing form a dict to an ovo for example that the filed be renamed.
15:44:09 sean-k-mooney enum to string is slightly differnet
15:44:17 sean-k-mooney but technically its the same
15:44:27 sean-k-mooney you are still changeing datatypes
15:45:31 efried Guess it depends how ovo is treating the enum. In python the enum value is just a string.
15:46:08 sean-k-mooney yes the underlying python type is a sting in either case
15:46:14 efried other than checking against the set of valid values, there *shouldn't* be any extra significance tied to the fact that it's an enum.
15:46:33 sean-k-mooney an enum field is the same a string field with the choices attibute set
15:47:05 gibi_off melwitt: hi! I'm still not 100% back but I can chair the nova meeting on Thursday as normal.
15:48:19 openstackgerrit Stephen Finucane proposed openstack/nova master: API: Remove evacuate/live-migrate 'force' parameter https://review.openstack.org/634600
15:48:56 sean-k-mooney efried: it just field like casting to void*. the data in memory is still the same but how you use it just chaged. its not somting i would block it on but i would still check with jaypipes or dansmith personally
15:49:11 sean-k-mooney *feels like
15:49:47 dansmith sean-k-mooney: yep, agree, and since this is for something out of tree, it's not really worth doing something like that to make it work, imho
15:51:41 sean-k-mooney dansmith: so to be clear are you +/- on changing to string and if we do change to string would you also want the field name change form driver to driver_name?
15:53:23 dansmith sean-k-mooney: char *response = "meh"; int vote = -1 *(int*)(void*)response;
15:55:12 dansmith hrm, my C is rusty
15:57:55 sean-k-mooney i belive that woudl set vote to -1 * the address of responce.
15:58:42 dansmith I meant to have another * in there, so it tried to set vote to -1 * the intlike value of meh, which would be negative something large :)
15:59:26 sean-k-mooney yes i assumed that was what you were going for. poters are always fun...
16:00:36 sean-k-mooney *pointers
16:07:38 mriedem need another stable core for this https://review.openstack.org/#/c/627011/
16:07:57 mriedem you guys are still talking about this out of tree enum thing? :)
16:11:29 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Retrieve the table schema using ovsdb-client command https://review.openstack.org/634967
16:12:53 sean-k-mooney mriedem: i think we had finished but yes
16:13:52 openstackgerrit Andrey Volkov proposed openstack/nova master: Check hosts have no instances for AZ rename https://review.openstack.org/509206
16:14:20 sean-k-mooney mriedem: by the way i agree with your ml post regardign changing the jobs. when i get my third party ci triggering of upstream it would be good to get your input on what you would like it to test
16:15:07 mriedem ok
16:17:33 openstackgerrit sean mooney proposed openstack/nova master: Libvirt: do not set mac when unplugging macvtap vf https://review.openstack.org/624842
16:17:34 openstackgerrit sean mooney proposed openstack/nova master: Add free for claimed, allocated devices https://review.openstack.org/616120
16:17:34 openstackgerrit sean mooney proposed openstack/nova master: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365
16:17:35 openstackgerrit sean mooney proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929
16:17:35 openstackgerrit sean mooney proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115
16:17:36 openstackgerrit sean mooney proposed openstack/nova master: libvirt: auto detach/attach sriov ports on migration https://review.openstack.org/629589
16:18:02 sean-k-mooney i fixed the merge conflict ^ otherwise its the same
16:23:59 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Retrieve the table schema using ovsdb-client command https://review.openstack.org/634967
16:36:43 artom sean-k-mooney, so, explain again why the nodeset in memoryBacking isn't necessary? If the dest compute has differently-numbered NUMA nodes, doesn't that need updating?
16:37:48 sean-k-mooney it is but its is carried in the numa_mappings info already
16:37:54 sean-k-mooney https://etherpad.openstack.org/p/numa_migration
16:40:34 sean-k-mooney i think the object i have listed in https://etherpad.openstack.org/p/numa_migration should have all the info you need?
16:42:10 artom sean-k-mooney, sorry, still don't get how if the source has <page size="1" unit="G" nodeset="4"/> and on the dest there is no nodeset 5 because there's only 4 NUMA nodes, how the source is supposed to update that bit of the XML
16:43:30 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Retrieve the table schema using ovsdb-client command https://review.openstack.org/634967
16:43:48 sean-k-mooney simple if it recives numa_maping:{0:2, 1:3} from the dest it sets nodeset=2,3
16:44:30 sean-k-mooney nodeset will be the union of of all the host numa nodes listed in numa_maping
16:44:50 artom Ah, yep, that's annoyingly obvious
16:45:11 artom The kernel will spread the pages across all nodes as equally as it can
16:45:13 sean-k-mooney libvirt allows mixed page size for the xml but nova does not
16:45:21 sean-k-mooney yes
16:45:25 artom Right, I knew the size won't change
16:45:26 sean-k-mooney by default
16:45:35 sean-k-mooney you can allocate pages differently if you choose too
16:46:24 sean-k-mooney artom: the mempage size could cange form 2M to 1G on migration if the flavor had hw:mem_page_size=large
16:46:40 sean-k-mooney or at leaste we woudl be allowed to do that
16:46:47 artom I feel like that should not be allowed?
16:46:48 sean-k-mooney if we choose to support that is another matter
16:47:06 sean-k-mooney well large state you will recive any pagezie other then the smallest available
16:47:06 artom I don't think the guest would like that...
16:47:15 sean-k-mooney the guest wont be able to tell
16:47:38 artom So wait, the guest will continue to see 1G pages, but they'll be backed by 2M?
16:47:51 sean-k-mooney the guest does nto see 1G hugepages
16:48:06 sean-k-mooney this all happens in qemu
16:48:21 sean-k-mooney the guest sees virtual ram dims
16:48:41 dims o/ :)
16:48:50 sean-k-mooney hehe o/
16:49:09 dims LOL
16:49:52 sean-k-mooney artom: if the guest expcitly requested 1G pages in the flavor and the destiation cant provide that the resouce tracker will fail to claim it
16:50:12 sean-k-mooney artom: but this is why i added numa_pagesize
16:50:26 artom sean-k-mooney, I'm confused because when I first set up my env for this, I gave the devstack machines 2M hugepages, but didn't configure anything on the host. With that I could boot only like, 1 VM out of 10
16:50:29 sean-k-mooney the guess will have only 1 page size for all its memory
16:50:32 artom The rest hung in 'spawning'
16:50:47 artom So I assumed guest and host pagesize need to match up, otherwise dragons!
16:51:22 sean-k-mooney no hugepages in the guest is totally independat
16:51:30 artom Which is why the idea of live-migrating a guest with 1G pages to a host that only has 2M pages (and this would get accepted because hw:numa_pagesize=large) confuses me
16:51:39 sean-k-mooney you can create 1G pages in the gues and have 4k pages on the host
16:52:12 artom And there's no performance impact? That's not been my experience... Or maybe I was doing something else wrong
16:52:25 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226
16:52:42 artom I kinda feel we need danpb
16:52:57 sean-k-mooney of corse there is a performacne impact but if you did not ask for hugepages for the vm you cannot expect to have the performace benifit
16:53:44 artom In my case it appeared to be a debilitating performance impact
16:53:45 sean-k-mooney the point is the guest internal memory allocation stragy is not something nova shoudl care about
16:54:30 sean-k-mooney artom: it will perfom better then 4k pages in the geuset but it wont significatly improve performance
17:13:29 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Fix legacy-grenade-dsvm-neutron-multinode-live-migration https://review.openstack.org/634962
17:15:40 sean-k-mooney artom: i updated https://etherpad.openstack.org/p/numa_migration
17:15:50 artom sean-k-mooney, yep, cheers for that

Earlier   Later