| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-28 | |||
| 06:56:41 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/nova_api/2018/nova_api.2018-11-28-06.00.html | |
| 06:56:42 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/nova_api/2018/nova_api.2018-11-28-06.00.txt | |
| 06:56:43 | openstack | Log: http://eavesdrop.openstack.org/meetings/nova_api/2018/nova_api.2018-11-28-06.00.log.html | |
| 07:17:59 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Per-instance serial number https://review.openstack.org/619953 | |
| 07:40:49 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Bump compute service to indicate attach/detach root volume is supported https://review.openstack.org/614750 | |
| 07:41:45 | openstackgerrit | Vieri proposed openstack/python-novaclient master: add python 3.6 unit test job https://review.openstack.org/620509 | |
| 07:58:32 | kashyap | artom: Thanks for the review. | |
| 07:59:07 | alex_xu | gmann: from this https://docs.openstack.org/nova/rocky/user/block-device-mapping.html#block-device-mapping-v2, we don't have deleted_on_termination param for bdmv2. Also we don't have that param for bdmv2 in nova cli. but I can pass that param by the API directly, does it support from the beginning or we leak something? | |
| 08:02:18 | kashyap | alex_xu: Hi, when you get a moment, mind having a look at this: https://review.openstack.org/#/c/620327 | |
| 08:04:05 | alex_xu | kashyap: got it, will try | |
| 08:04:32 | gmann | alex_xu: humm, checking | |
| 08:04:41 | kashyap | alex_xu: Thanks | |
| 08:05:55 | alex_xu | kashyap: np | |
| 08:06:07 | alex_xu | gmann: thanks | |
| 08:07:07 | alex_xu | gmann: actually, I'm reviewing this spec https://review.openstack.org/#/c/580336 | |
| 08:09:09 | gmann | alex_xu: delete_on_termination is bdmv1 attribute which is allowed for bdmv2 also | |
| 08:09:40 | gmann | alex_xu: you can see that in doc you mentioned also under Block device mapping v1 (aka legacy)¶ section | |
| 08:14:07 | alex_xu | gmann: so v2 inhertis all the attributes from v1, right? | |
| 08:15:41 | gmann | alex_xu: yeah, https://github.com/openstack/nova/blob/62245235bc15da6abcdfd3df1c24bd856d69fbb4/nova/api/openstack/compute/schemas/servers.py#L90 | |
| 08:18:30 | alex_xu | gmann: it is strange that we don't have delete_on_termination on the CLI | |
| 08:18:54 | gmann | alex_xu: humm it is error ? | |
| 08:19:51 | alex_xu | gmann: i don't know | |
| 08:24:39 | gmann | alex_xu: i can see it is supported in CLI - https://github.com/openstack/python-novaclient/blob/58b3ac457aa817da28c757b4845bc39e565139dd/novaclient/v2/shell.py#L138 | |
| 08:36:37 | openstackgerrit | Yikun Jiang proposed openstack/nova master: Change the default values of XXX_allocation_ratio https://review.openstack.org/602803 | |
| 08:36:37 | openstackgerrit | Yikun Jiang proposed openstack/nova master: Use new ``initial_xxx_allocation_ratio`` CONF https://review.openstack.org/602804 | |
| 09:22:20 | openstackgerrit | Ghanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup https://review.openstack.org/603969 | |
| 09:23:40 | openstackgerrit | Ghanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup https://review.openstack.org/603969 | |
| 10:09:08 | openstackgerrit | Yikun Jiang proposed openstack/nova master: Use new ``initial_xxx_allocation_ratio`` CONF https://review.openstack.org/602804 | |
| 10:33:33 | openstackgerrit | Yikun Jiang proposed openstack/nova master: Add ratio online data migration when load compute node https://review.openstack.org/613499 | |
| 10:33:34 | openstackgerrit | Yikun Jiang proposed openstack/nova master: Add compute_node ratio online data migration script https://review.openstack.org/609995 | |
| 10:36:57 | noonedeadpunk | Hi everyone. | |
| 10:39:08 | noonedeadpunk | I've faced with a problem (not sure if it's a bug or not), when nova in Q generates config, which is not compatible with libvirt 4 (which is a default for ubuntu). So VM creation results in error "'serial' is deprecated, please use the corresponding option of '-device' instead" | |
| 10:41:40 | openstackgerrit | Chris Dent proposed openstack/nova master: Use external placement in functional tests https://review.openstack.org/617941 | |
| 10:42:49 | openstackgerrit | Chris Dent proposed openstack/nova master: Delete the placement code https://review.openstack.org/618215 | |
| 11:33:04 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Support for changing deleted_on_termination after boot https://review.openstack.org/580336 | |
| 11:39:44 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/rocky: Migrate nova v2.0 legacy job to zuulv3 https://review.openstack.org/620571 | |
| 11:47:43 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/queens: Migrate nova v2.0 legacy job to zuulv3 https://review.openstack.org/620578 | |
| 11:53:26 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/pike: Migrate nova v2.0 legacy job to zuulv3 https://review.openstack.org/620579 | |
| 12:01:48 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/rocky: Migrate nova v2.0 legacy job to zuulv3 https://review.openstack.org/620571 | |
| 12:02:08 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/pike: Migrate nova v2.0 legacy job to zuulv3 https://review.openstack.org/620579 | |
| 12:02:30 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/queens: Migrate nova v2.0 legacy job to zuulv3 https://review.openstack.org/620578 | |
| 12:32:35 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/pike: DNM: For testing only https://review.openstack.org/620592 | |
| 12:49:15 | jroll | flwang: at oath we eventually changed the catalog, it was fine | |
| 14:34:12 | mriedem | couple of easy patches here that need another core https://review.openstack.org/#/c/620165/ https://review.openstack.org/#/c/620170/ | |
| 14:42:18 | gmann | mriedem: melwitt nova-next job does not run in queens but seems like it supposed to run there - https://github.com/openstack/nova/blob/master/.zuul.yaml#L140 | |
| 14:42:43 | gmann | reason is- job migration patch got merged in rocky - https://review.openstack.org/#/c/541474/ | |
| 14:43:14 | gmann | and it was mistakenly added in stable/queens check and gate pipeline list here - https://review.openstack.org/#/c/604134/ | |
| 14:43:51 | gmann | nova-next job definition is not present in stable/queens but listed in check and gate pipeline. | |
| 14:47:41 | gmann | to run it on queens, we need to backport these 2 in queens - https://review.openstack.org/#/c/541474/ https://review.openstack.org/#/c/513160/ | |
| 14:50:04 | Sundar | efried: Please ping me when you have the time. | |
| 14:50:13 | efried | Sundar: I'm here. What's up? | |
| 14:52:14 | Sundar | efried: Are you aligned with the decision to drop os-acc? I am trying to make sure we have a quorum of Nova developers. | |
| 14:53:49 | gmann | stephenfin: what is use of bug-tag in openstackdocstheme? - https://review.openstack.org/#/c/619434/2 | |
| 14:54:01 | gmann | i did not find where it was linked on doc/buglink | |
| 14:54:07 | artom | gmann, he's on PTO | |
| 14:54:39 | gmann | artom: ohk. thanks. added him in review. | |
| 14:55:55 | Sundar | jaypipes: Please let me know when you have some time to follow up from last week. | |
| 14:57:38 | jaypipes | Sundar: I am here. | |
| 14:58:54 | Sundar | jaypipes: I am trying to reconcile your views with what everybody else is saying. You wanted to see os-acc as a small library that works by itself. Whereas others don;t see a need for os-acc at all :) #link http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-11-20.log.html#t2018-11-20T17:47:21 | |
| 15:00:09 | jaypipes | Sundar: correct. | |
| 15:00:40 | Sundar | jaypipes: Could I understand your motivation? Nova virt drivers will do the actual attachment for accelerators, as with networking. All device-specific actions should be in Cyborg. | |
| 15:00:45 | Sundar | DO you agree? | |
| 15:00:49 | efried | Sundar: It seems reasonable, if nova only needs to talk to the cyborg API, to nix os-acc. | |
| 15:01:10 | jaypipes | Sundar: I was under the impression os-acc would function similarly to os-vif, where os-vif provides the data models that are used to understand what and how network interfaces are brought up on the host. | |
| 15:01:34 | efried | Sundar: My impression of os-acc was that it would be the clearinghouse for platform- and virt-specific plugins to do discovery and attachment. | |
| 15:01:39 | efried | yeah, what jaypipes said. | |
| 15:02:17 | Sundar | jaypipes: Yes, that's how we started. As the discussion progressed, and the spec was reviewed, it became clear that most of the work would be done by Cyborg APIs. | |
| 15:02:36 | jaypipes | Sundar: which I completely disagree with. | |
| 15:02:54 | jaypipes | Sundar: I have continued to maintain I see very little use in a Cyborg REST API at the moment. | |
| 15:03:30 | mriedem | gmann: yes https://review.openstack.org/#/c/604134/1/.zuul.yaml is a bad backport | |
| 15:03:54 | jaypipes | Sundar: let me tell you why. | |
| 15:04:06 | mriedem | gmann: the commit message in https://review.openstack.org/#/c/541474/ sounds like we don't need it in queens | |
| 15:04:18 | mriedem | the queens comment in https://github.com/openstack/nova/blob/master/.zuul.yaml#L140 might be wrong | |
| 15:04:35 | jaypipes | Sundar: focusing on the REST API in Cyborg right now means you are constrained by versioning in a way that just focusing on iterating a workable object/data model would not constrain you. | |
| 15:04:37 | Sundar | jaypipes: Without Cyborg APIs, how would one initiate device configuration, whether it is for a GPU, FPGA, ...? | |
| 15:04:40 | mriedem | gmann: https://review.openstack.org/#/c/396186/ isn't in queens | |
| 15:04:47 | jaypipes | Sundar: IMHO, a REST API is just a giant distraction right now for Cyborg. | |
| 15:05:09 | efried | jaypipes: The way I see it, we need a way to follow the thread of an ARQ from [set of resources and traits] to [actual accelerator instance plugged into a VM]. | |
| 15:05:11 | jaypipes | Sundar: what does Cyborg do "under the covers" in its drivers? | |
| 15:05:20 | jaypipes | Sundar: *that* is what I think os-acc should be doing. | |
| 15:06:06 | dansmith | bauzas: gonna circle back on https://review.openstack.org/#/c/599587 right? | |
| 15:06:17 | efried | jaypipes: Nova is going to be driving that workflow, but cyborg needs to be the one to make some of those transitions (like, "I landed on a host; pick me a specific device and configure it") and needs to be made aware of the ones Nova makes (like, "I plugged accelerator X into VM Y"). | |
| 15:06:27 | gmann | mriedem: ok. then we can remove the nova-next from queen pipeline list also + that job comment fix. i observed it while backporting the nova v2 job. | |
| 15:06:31 | Sundar | jaypipes: Are you saying that os-acc should have its own device-specific drivers and run the show by itself? Or that it should call into Cyborg drivers, without involving any REST API? | |
| 15:06:34 | bauzas | dansmith: yup, I'm just reviewing it | |
| 15:06:35 | efried | jaypipes: *some* kind of API seems like the appropriate way to do that. | |
| 15:06:40 | dansmith | bauzas: awesome, thanks | |
| 15:06:57 | jaypipes | Sundar: that is correct. | |
| 15:07:07 | mriedem | gmann: yeah it's either that or backport the devstack and nova change | |
| 15:07:41 | jaypipes | Sundar: I've said a number of times that I wish Cyborg would just accept that Nova is its sole consumer right now, stop working on some "stand-alone Cyborg" thing and just function like a Nova virt driver for right now. That way, you can iterate more quickly, actually get something that works (as opposed to just abstract, non-working things) and go from ther | |
| 15:08:08 | gmann | mriedem: i can give backport try also if you think it is worth to run on queens. | |
| 15:09:07 | mriedem | gmann: i backported the devstack change, you can backport https://review.openstack.org/#/c/513160/ if you want | |
| 15:09:10 | mriedem | it has merge conflicts | |
| 15:09:21 | mriedem | i'm guessing the nova-next/devstack testing just missed the queens GA | |
| 15:09:29 | mriedem | but the feature itself is in nova in queens | |
| 15:09:33 | mriedem | so it would probably be good to test it... | |
| 15:09:50 | Sundar | jaypipes: There are are several use cases for accelerators without direct Nova involvement. For example, we may want to set up OVS offload in an accelerator in a host, but that doesn't involve assigning to a VM. | |
| 15:10:05 | jaypipes | Sundar: there might be, yes. I' | |
| 15:10:28 | jaypipes | m saying I don't care about those use cases and I feel they are a giant distraction from getting anything working in Nova/Cyborg at the moment. | |
| 15:11:23 | gmann | mriedem: +1. will do tomorrow. | |