Earlier  
Posted Nick Remark
#openstack-nova - 2017-09-25
14:23:36 celebrate I have 3 different AZ and during live-migration VMs travel from one AZ to another
14:23:57 celebrate and I want VMs to stay inside their AZ
14:25:04 bauzas celebrate: if the instance wasn't boot by specifying an AZ with --availability_zone' then the answer is "no, it's not possible to modify that later"
14:25:23 bauzas and tweaking the DB is fairly discouraged
14:25:45 bauzas rather, you should consider making use of "default_schedule_zone" config opt which sets a default AZ to any instance
14:26:04 bauzas I really need to disappear for a couple of mins (kids school thingy)
14:28:00 celebrate please tell me where it is stored in DB
14:28:10 celebrate please )
14:28:55 liuyulong_ mriedem, sdague, hello, http://lists.openstack.org/pipermail/openstack-dev/2017-September/122567.html, I sent the issue of rebuild-keypair-updating to the mail list openstack-dev. So what do you guys think about it?
14:29:33 mriedem sahid: jaypipes: replied to the ML thread on vgpus
14:29:41 liuyulong_ Are there any others related to this discussion? PTG members?
14:36:24 celebrate so anybody knows where in DB "availability_zone" attribute is located?
14:36:40 celebrate the one attribute that is respected by scheduler
14:39:30 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Field network.multi_host is now deprecated. https://review.openstack.org/507151
14:41:39 openstackgerrit zhangyangyang proposed openstack/nova master: Update oslo version in requirements https://review.openstack.org/507153
14:43:19 jaypipes mriedem: danke\
14:48:47 openstackgerrit Moshe Levi proposed openstack/nova master: Don't overwrite binding-profile https://review.openstack.org/505613
14:58:17 mriedem bauzas: don't forget https://review.openstack.org/#/c/506414/
14:58:34 bauzas mriedem: I'm on it
14:58:43 bauzas just needs moar time
15:01:14 sahid mriedem: ok thanks it's fair :)
15:01:33 sahid just have replied
15:04:01 openstackgerrit Merged openstack/nova master: Change livesnapshot to true by default https://review.openstack.org/454323
15:04:14 jianghuaw bauzas, sahid, do you have a link where I can get the list of vGPU type ids for mdev?
15:05:49 jianghuaw per this link: https://libvirt.org/drvnodedev.html
15:05:56 openstackgerrit Merged openstack/nova master: Add live.migration.force.complete to the legacy notification whitelist https://review.openstack.org/506104
15:06:10 jianghuaw 'The element has one attribute id which holds an official vendor-supplied identifier for the type'
15:06:21 openstackgerrit Merged openstack/nova master: Add functional migrate force_complete test https://review.openstack.org/496202
15:07:09 jianghuaw I guess the type id is exactly mapped into the type name.
15:22:16 openstackgerrit Takashi NATSUME proposed openstack/nova master: Deprecate idle_timeout in api_database https://review.openstack.org/507006
15:22:22 openstackgerrit Takashi NATSUME proposed openstack/nova master: Deprecate idle_timeout in api_database https://review.openstack.org/507006
15:23:23 openstackgerrit Merged openstack/nova-specs master: Clarify wording in Searchlight spec - error conditions https://review.openstack.org/463388
15:27:01 bauzas jianghuaw: AFAIK, that's vendor specific templates
15:27:25 bauzas jianghuaw: like described in https://www.kraxel.org/blog/2017/01/virtual-gpu-support-landing-upstream/
15:27:43 bauzas jianghuaw: that's basically the driver which will provide mediated devices
15:28:15 bauzas jianghuaw: well, it will provide the mdev types, and operators will have to create the mdev as stated in the bottom of the page you pointed me
15:30:24 openstackgerrit Merged openstack/nova-specs master: Fix pike spec names to match blueprints https://review.openstack.org/500368
15:30:44 mriedem dansmith: replied in https://review.openstack.org/#/c/505661/ - i think we don't need it now, we should drop it
15:30:50 mriedem *if we don't need it now
15:31:01 dansmith okay, I'll snip it out the next time I push
15:32:12 mriedem ok, i guess the next patch for me to review is the big kahuna
15:36:47 dansmith mriedem: it's not particularly big, but it is the kahuna yeah :)
15:36:56 dansmith mriedem: just think of all the awesome we get once that is in:)
15:37:14 dansmith -353, +91
15:37:17 dansmith pretty good ratio
15:38:30 mriedem if you like that
15:39:16 mriedem oh nvm
15:39:21 mriedem it already merged https://review.openstack.org/#/c/460377/ :)
15:39:54 mriedem stephenfin: an excellent +1 +W there ^
15:40:22 dansmith oh, I thought you mean the patch that uses the instance_list bit
15:40:33 stephenfin mriedem: God damn it
15:40:59 stephenfin dansmith: Fancy taking a look through it anyway? If I missed something, I imagine we can revert
15:41:39 dansmith stephenfin: in a bit, I'm in the middle of rebase hell with my migration uuid set
15:41:57 stephenfin (y)
15:52:31 openstackgerrit Jianghua Wang proposed openstack/nova-specs master: Support virtual GPU resources https://review.openstack.org/450122
15:54:22 openstackgerrit Balazs Gibizer proposed openstack/nova master: cover migration cases with functional tests https://review.openstack.org/493865
15:54:39 mriedem ooo pike 16.0.1 was released
15:55:05 bauzas jaypipes: mriedem: dansmith: as we discussed previously, if we say we could just imagine implementing baby steps for VGPU tracking by just amending the current RP that is returned by the virt driver and just add some resource class about how many VGPUs are available, that would mean it would be limited to only one single track of the virtual GPUs, whatever the number of devices we have
15:55:33 jaypipes bauzas: yeah
15:55:39 dansmith bauzas: which would be fine I think
15:55:40 bauzas jaypipes: mriedem: dansmith: to make it clear, once nested RPs would be a thing, we would have the virt driver reporting the inventory per pGPU
15:55:46 dansmith yes
15:55:53 jaypipes bauzas: until n-r-p there would only be a single provider to associate a trait to, so yeah
15:55:59 bauzas okay, we're all in violent agreement then
15:56:07 jaypipes VIOLENCE!
15:56:18 mriedem bauzas: are you going to implement get_inventory for the virt driver then? or munge it into get_available_resources?
15:56:29 mriedem i think only ironic and libvirt have the get_inventory method implemented
15:56:30 bauzas mriedem: I was planning to use the new call
15:56:33 mriedem ok
15:56:34 dansmith yes
15:56:41 mriedem jianghuaw would do it for xen,
15:56:54 bauzas mriedem: yeah, libvirt already uses the new interface
15:56:54 mriedem and either cdent or rado (sp?) is i think doing it for vmware
15:57:06 mriedem radu?
15:57:27 mriedem and according to claudiub, there is nothing hyperv *can't* do, so i'm sure he's up for implementing that
15:57:33 jaypipes heh
15:57:50 bauzas HAH
15:58:17 bauzas honestly, I just feel having vGPU support in Nova would be an interesting usecase for showing how Placement can help :)
15:58:35 bauzas and no longer do any crap stuff like PCIDeviceTracker
15:58:43 jianghuaw mriedem, absolutely I'm happy to take the needed work for xen.
15:58:54 mriedem cdent: edleafe: one of you want to update this for nova? http://specs.openstack.org/openstack/api-wg/liaisons.html#liaisons
15:59:18 jaypipes lyarwood: I can't believe you didn't list my proposed name of "ffs" for fast-forward skips ;)
15:59:44 dansmith jaypipes: because skip can't be in the name
15:59:54 edleafe mriedem: who should the new liaison be?
15:59:56 dansmith but if we could come up with another word for the s
15:59:57 jaypipes dansmith: I know I was only kidding. :)
16:00:18 mriedem how about slop
16:00:26 mriedem skip-level offline (upgrade) process
16:00:34 jianghuaw bauzas, jaypipes: please help to check if you are happy with the revised vGPU spec: https://review.openstack.org/#/c/450122/
16:00:38 dansmith can't have skip in the name
16:00:43 jaypipes jianghuaw: yep, will do.
16:00:46 bauzas jianghuaw: I'm already on it
16:01:15 claudiub what do I have to do?
16:01:34 jaypipes dansmith: I still like the package repository - integrated clustered kubernetes
16:01:35 mriedem claudiub: make the hyperv driver implement the get_inventory method
16:01:52 mriedem claudiub: to set the stage for vgpu support https://review.openstack.org/#/c/450122/
16:02:11 claudiub awesome
16:03:25 jianghuaw jaypipes, bauzas: thanks both:-)
16:04:37 claudiub welp, at the moment hyper-v reports some vgpu resources / stats, so i guess we'll have to move that around a bit.
16:10:08 jianghuaw bauzas, cool. thanks for +2 on the spec:-)

Earlier   Later