| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-25 | |||
| 14:09:27 | jaypipes | dansmith: very simple resources, yes. we could add a (custom) resource class for the VGPU resources and have a flavor consume some amount of those | |
| 14:09:43 | dansmith | jaypipes: right, that'd be my preference for the first go-round | |
| 14:10:02 | jianghuaw | bauzas, I think if the type id is different, it will be a good solution to use 'type-id' for libvirt. | |
| 14:10:20 | bauzas | dansmith: jaypipes: I was only seeing the virt drivers adding the new VGPU resource class to the existing RPs as a first round, that's it :) | |
| 14:10:26 | dansmith | jaypipes: let people segregate different types of gpus into aggregates, and just assume equal portions of vgpu per instance without any smarts, which I think would be a perfectly reasonable first stab, which we can iterate on when we have traits and things | |
| 14:10:32 | dansmith | bauzas: ++ | |
| 14:11:06 | jaypipes | dansmith: agreed. | |
| 14:11:21 | bauzas | jianghuaw: yeah, so you agree with the fact that the listOpt can have different semantics based on the driver? | |
| 14:11:50 | jianghuaw | bauzas, yes. libvirt uses the type-id but XenServer continue to use the type name. As you suggested, virt driver should able to mapping them into real resources. | |
| 14:12:05 | bauzas | that would be strings for each of the drivers, but in the libvirt case, it would be device IDs while it would be pGPU resource type names for xen | |
| 14:12:08 | jianghuaw | but we need confirm if the type-id will be different. | |
| 14:12:19 | bauzas | jianghuaw: what I need is a testbed :p | |
| 14:13:02 | jianghuaw | bauzas, thanks. | |
| 14:13:28 | bauzas | jianghuaw: fancy updating the spec so I can do a pass once again ? | |
| 14:14:10 | jianghuaw | bauzas, sure. I will update it soon. | |
| 14:14:19 | bauzas | cool | |
| 14:14:28 | sahid | dansmith: basically you can't do more than that right now and it's exactly what i'm pointing where we could have better support | |
| 14:14:36 | jianghuaw | bauzas, so I think the option name as enabled_vgpu_types is fine. right? | |
| 14:14:58 | jianghuaw | just confirm if I can keep this option name:-) | |
| 14:15:25 | celebrate | Hi guys! Do you know where the "availability_zone" attribute of instance is stored? | |
| 14:15:28 | dansmith | sahid: building more on the current pci stuff isn't "better" in any way, IMHO :) | |
| 14:15:57 | dansmith | sahid: and I just think that providing a basic building block initially and moving on from there avoids us building more baggage that we have to migrate, adapt, and remove later | |
| 14:16:00 | mriedem | celebrate: instance.availability_zone, or as metadata on a host aggregate the instance is in | |
| 14:16:25 | bauzas | celebrate: the scheduler queries hosts based on request_spec.availability_zone | |
| 14:16:41 | bauzas | instance.az is only set at boot time | |
| 14:16:50 | celebrate | yeah, in database i see AZ=nova, but scheduler thinks its "None" | |
| 14:17:12 | sahid | dansmith: i'm not agree with you the /pci is good and do what we need | |
| 14:17:27 | dansmith | sahid: okay :) | |
| 14:17:35 | sahid | dansmith: in all cases we will have to migrate the /pci | |
| 14:17:44 | celebrate | Do you know how to make scheduler understand that AZ is "nova"? | |
| 14:17:58 | mriedem | sahid: we don't have to migrate vgpus if we don't implement it in /pci | |
| 14:17:59 | sahid | the support of mdev is not so heavy | |
| 14:18:12 | sahid | mriedem: mdev is just pci devices | |
| 14:18:14 | bauzas | celebrate: well, nova AZ is actually equal to None | |
| 14:18:29 | sahid | so when you will migrate sriov it will be the same work | |
| 14:18:50 | bauzas | celebrate: that's a convention, or rather a config option default value | |
| 14:19:08 | mriedem | celebrate: https://docs.openstack.org/nova/latest/user/aggregates.html | |
| 14:19:11 | bauzas | namely [DEFAULT]/default_availability_zone | |
| 14:19:37 | celebrate | I've already set [DEFAULT]/default_availability_zone to "nova" | |
| 14:19:56 | celebrate | however scheduler thinks its None and refuses to respect AZ from aggregates | |
| 14:20:15 | bauzas | celebrate: I will need to disappear in a couple of minutes, but here are a few things to know | |
| 14:20:41 | bauzas | celebrate: #1 if you didn't ask a specific AZ at boot time, that means the scheduler won't care about placing your instance to a specific AZ | |
| 14:21:19 | bauzas | celebrate: if you did specified a AZ at boot, AZFilter in the scheduler will check the AZ for each of the hosts | |
| 14:21:28 | celebrate | can I somehow make scheduler change its mind? | |
| 14:21:38 | bauzas | celebrate: not sure I get why :) | |
| 14:22:07 | celebrate | because I have different AZ and scheduler sends VM there during live-migration | |
| 14:22:33 | celebrate | where this information is stored in DB? | |
| 14:23:03 | bauzas | celebrate: could you please describe your problem ? | |
| 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 | |