| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-08-06 | |||
| 15:42:09 | shaohe_feng_ | * If the conductor does the diff, it can become the scalability bottleneck. The agent needs to store the previous config in local host. | |
| 15:42:17 | shaohe_feng_ | * It is more efficient for the agent to make one RPC call than many separate calls once for each deployable, trait etc. | |
| 15:42:37 | shaohe_feng_ | The diff include a new acc on line or a exist acc off line? | |
| 15:42:52 | shaohe_feng_ | Yes. Also, changes to existing devices. | |
| 15:42:59 | shaohe_feng_ | Then how does agent to present these diff? | |
| 15:43:14 | shaohe_feng_ | It needs to indicate the list of added devices, the list of deleted ones, and the list of modified ones. How we indicate the modifications to existing devices is open to q. :) | |
| 15:43:30 | shaohe_feng_ | Yes， modification is more complex than others(add/delete) | |
| 15:43:40 | shaohe_feng_ | Agreed. That's why I thought it is easier for the conductor to do the diff, because it can compare the db fields, field by field | |
| 15:43:50 | shaohe_feng_ | But, for the agent to send it, it should send a dictionary that also indicates what got added, deleted or changed for an existing device. | |
| 15:43:59 | shaohe_feng_ | E.g. a region got programmed, so the function type trait changed. So, the diff must indicate the old function type trait must be deleted, and a new one added | |
| 15:58:20 | shaohe_feng_ | #endmeeting | |
| 15:58:22 | openstack | Meeting ended Mon Aug 6 15:58:20 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 15:58:23 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg_driver/2018/openstack_cyborg_driver.2018-08-06-14.08.html | |
| 15:58:24 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg_driver/2018/openstack_cyborg_driver.2018-08-06-14.08.txt | |
| 15:58:25 | openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg_driver/2018/openstack_cyborg_driver.2018-08-06-14.08.log.html | |
| #openstack-cyborg - 2018-08-07 | |||
| 02:49:43 | openstackgerrit | Merged openstack/cyborg master: Switch to stestr https://review.openstack.org/580927 | |
| 05:59:24 | openstackgerrit | wangqi proposed openstack/python-cyborgclient master: Remove PyPI downloads https://review.openstack.org/589367 | |
| 09:30:45 | openstackgerrit | YumengBao proposed openstack/cyborg master: Docs: Autogenerate config documentation https://review.openstack.org/588480 | |
| 23:41:04 | openstackgerrit | Merged openstack/cyborg master: Added rest API for FPGA programming https://review.openstack.org/579315 | |
| #openstack-cyborg - 2018-08-08 | |||
| 01:00:23 | openstackgerrit | Merged openstack/os-acc master: Change "type" to "interface_type" https://review.openstack.org/586928 | |
| 01:22:33 | openstackgerrit | zhurong proposed openstack/cyborg master: Docs: Autogenerate config documentation https://review.openstack.org/588480 | |
| 01:24:15 | openstackgerrit | zhurong proposed openstack/cyborg master: Docs: Autogenerate config documentation https://review.openstack.org/588480 | |
| 01:25:03 | openstackgerrit | wangzhh proposed openstack/cyborg master: Imply new cyborg deployable api https://review.openstack.org/584641 | |
| 01:26:41 | openstackgerrit | zhurong proposed openstack/cyborg master: Docs: Autogenerate config documentation https://review.openstack.org/588480 | |
| 07:18:19 | openstackgerrit | Merged openstack/cyborg master: Imply new cyborg deployable api https://review.openstack.org/584641 | |
| 10:17:51 | openstackgerrit | Merged openstack/cyborg master: Docs: Autogenerate config documentation https://review.openstack.org/588480 | |
| 14:01:54 | zhipeng | #startmeeting openstack-cyborg | |
| 14:01:55 | openstack | Meeting started Wed Aug 8 14:01:54 2018 UTC and is due to finish in 60 minutes. The chair is zhipeng. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 14:01:56 | openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 14:01:58 | openstack | The meeting name has been set to 'openstack_cyborg' | |
| 14:02:25 | zhipeng | #topic Roll Call | |
| 14:02:51 | zhipeng | cmd is definitely not working today | |
| 14:04:21 | zhipeng | #info Howard | |
| 14:11:58 | shaohe_feng_ | #info shaohe_feng | |
| 14:12:05 | xinran | #info xinran | |
| 14:13:03 | zhipeng | shaohe_feng_ xinran let's catch up in wechat | |
| 14:14:08 | shaohe_feng_ | OK | |
| 14:14:53 | xinran | ok | |
| 14:14:57 | zhipeng | #endmeeting | |
| 14:14:59 | openstack | Meeting ended Wed Aug 8 14:14:57 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 14:15:00 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-08-08-14.01.html | |
| 14:15:01 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-08-08-14.01.txt | |
| 14:15:02 | openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-08-08-14.01.log.html | |
| 14:38:49 | Coco_gao | Hi | |
| 15:35:35 | Li_Liu | finally, I am in... | |
| #openstack-cyborg - 2018-08-09 | |||
| 02:50:00 | openstackgerrit | wangxu proposed openstack/cyborg master: Fix deployable get all sort issue and unit test failure. https://review.openstack.org/590075 | |
| 08:39:55 | openstackgerrit | ShaoHe Feng proposed openstack/cyborg master: support sub provider https://review.openstack.org/585146 | |
| 11:04:40 | openstackgerrit | ShaoHe Feng proposed openstack/cyborg master: support sub provider https://review.openstack.org/585146 | |
| 11:07:58 | openstackgerrit | ShaoHe Feng proposed openstack/cyborg master: support sub provider https://review.openstack.org/585146 | |
| 12:09:10 | openstackgerrit | ShaoHe Feng proposed openstack/cyborg master: support sub provider https://review.openstack.org/585146 | |
| 20:40:52 | Sundar_ | Hi Eric and Sean | |
| 20:41:18 | efried | Sundar_: hold on, Sean's not here yet... | |
| 20:45:14 | efried | Sundar_, sean-k-mooney: Absolutely agree libvirt-XML-specific code should live in the os-acc driver and/or plugin, NOT in nova. | |
| 20:46:02 | Sundar_ | Sean, I am just saying that the os-acc provides device-specific info to Nova virt drivers depending on the hypervisor. For e.g., for libvirt + PCI, it may provide a XML snippet for a PCI device, but does not modify the VM's domain XML. That is left to the libvirt driver. | |
| 20:46:22 | Sundar_ | efried: Agreed | |
| 20:46:27 | sean-k-mooney | efried: only if the os-acc driver is part of nova and not cyborg | |
| 20:46:32 | Sundar_ | efried: Agreed | |
| 20:47:06 | efried | "part of nova and not cyborg" - the driver stands alone. It talks to both nova and cyborg, but it's not really "part of" either. | |
| 20:47:13 | sean-k-mooney | what is the argument for allowing arbitary xml to be instered form an external lib that is loaded dynamically at runtime | |
| 20:48:13 | sean-k-mooney | efried: this exact usecase was forbin for both os-brick and os-vif | |
| 20:49:22 | Sundar_ | sean-k-mooney: It is not necessarily arbitrary: the return value, including the schema, can be specified and checked by the virt driver. But it allows for more extensibility -- environment/device-specific variations can be handled better | |
| 20:50:29 | sean-k-mooney | Sundar_: how do you know how to asign virtual pci address for acclorator withing the guest | |
| 20:50:39 | sean-k-mooney | jsut as an example | |
| 20:51:11 | Sundar_ | sean-k-mooney: The analogy with os-vif cannot be taken too far. The os-vif handles a small number of plugins (Linux bridge, OVS, etc.) and it is intertwined with virt driver logic in practice. With os-acc, we will have far more variation in devices. Also, we do not want to repeat the coupling and legacy pracices of os-vif | |
| 20:52:08 | sean-k-mooney | Sundar_: you are going to end up coupleing the drivers to hyperviros in a way that is highly fragile | |
| 20:52:18 | Sundar_ | sean-k-mooney: For the virtual PCI, the os-acc plugin/driver will get it in a device-specific way and, depending on the hypervisor (e.g. libvirt+qemu), can construct the needed snippets | |
| 20:53:12 | Sundar_ | sean-k-mooney: "Coupling the drivers to hypervisors' -- can you make that more concrete with an example or specific scenario? | |
| 20:53:12 | sean-k-mooney | Sundar_: which would mean i would have to pass the iamge and flavor to you in addtion to the list of all interfaces | |
| 20:53:45 | sean-k-mooney | well for a start the fact that os-acc needs to know you are using libvirt at all is a failing in my view | |
| 20:54:56 | sean-k-mooney | whey canre we not define a datamodle using oslo versioned object that will be returned by os-acc and have each of the virt driver interperate them internally | |
| 20:56:41 | Sundar_ | For the specific case of libvirt and PCI, I don't see the issue with this. But I am not sure if that works for all devices and hypervisors. Power seems quite different, for example. may be efried can chime in. | |
| 20:58:01 | efried | Yeah, sean-k-mooney, platform-gnostic code is like half of the raison d'être for os-acc. | |
| 20:58:18 | Sundar_ | As long as the XML snippet is well-defined and constrained, what is the issue? | |
| 20:58:34 | efried | sean-k-mooney: Because e.g. the 'plug' operation for libvirt entails modifying xml, whereas on power it involves issuing a REST command to a proprietary API. | |
| 20:59:02 | sean-k-mooney | efried: plug does not modify xml | |
| 20:59:24 | sean-k-mooney | os-vif cant by design. | |
| 20:59:34 | efried | what does, then? | |
| 20:59:40 | efried | the nova virt driver? | |
| 20:59:43 | sean-k-mooney | the libvirt driver | |
| 20:59:55 | efried | okay, so be it. | |
| 21:00:06 | efried | what about discovery? | |
| 21:00:12 | efried | who's responsible for that? | |
| 21:00:13 | sean-k-mooney | os-vif is invoked with a ovo construted by the driver to wire up the backend | |
| 21:00:25 | efried | Again, libvirt => lspci (I think); Power => REST call. | |
| 21:00:26 | sean-k-mooney | efried: current the libvirt driver alos | |
| 21:00:50 | sean-k-mooney | i had proposed haveing a call in os-vif for discovery | |
| 21:01:24 | sean-k-mooney | it was pushed back on however so we can discover what plugins are install but thats about it | |
| 21:02:08 | sean-k-mooney | efried: in the os-vif the spcific example of modiging the hypervior code came up for smartnic. | |
| 21:02:56 | sean-k-mooney | sorry i shoudl retype that but what i ment to say originaly having os-vif generate xml so that new nic could be added was proposed | |
| 21:03:05 | sean-k-mooney | it was also rejected | |
| 21:03:20 | Sundar_ | sean-k-mooney: Please look at #link https://libvirt.org/formatdomain.html#elementsHostDevSubsys . How would the virt driver determine XML elements like |
|
| 21:03:40 | Sundar_ | Those are device-specific and configuration-specific | |
| 21:04:05 | sean-k-mooney | Sundar_: today we already do that. at least part of it. | |
| 21:04:21 | sean-k-mooney | we would pass that infomation from neutron | |
| 21:04:27 | sean-k-mooney | in the vif_binding details | |
| 21:05:09 | efried | how does neutron know? | |
| 21:05:27 | efried | based on the ml2 thingy, or the plugin? | |
| 21:05:47 | sean-k-mooney | ml2 in general. | |
| 21:06:09 | Sundar_ | sean-k-mooney: That results in a double translation: first you have to fill in a VIF, and then translate that to another syntax. Since the final syntax is also well-defined, we may as well go to that directly | |
| 21:06:14 | sean-k-mooney | so for example ml2/ovs detect if ovs is kernel or dpdk and select vhost-user or a tap device | |