| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2017-03-22 | |||
| 15:19:15 | jkilpatr | I need to read the last couple of times we talked about this. Anyways so we have to select an appropriate host, just one? Might result in some code duplication from the normal scheduler but not too bad hopefully. | |
| 15:21:25 | zhipeng | I think we will be using the placement module for the scheduling, won't be too much of code duplication I guess ? | |
| 15:21:53 | zhipeng | we need to select one host with the best fit accelerators | |
| 15:22:03 | zhipeng | do we have scenarios for more than one host ? | |
| 15:23:41 | jkilpatr | zhipeng, not at the moment. Just trying to think ahead | |
| 15:23:54 | zhipeng | understood :) | |
| 15:24:26 | zhipeng | well we need to review it thoroughly , so any question is welcomed | |
| 15:31:36 | zhipeng | goldenfri hey dude you there ? | |
| 15:34:21 | goldenfri | hey yea I'm here | |
| 15:34:52 | zhipeng | martial hooked me up with Blair on email about one months ago, but haven't heard from Blair yet | |
| 15:35:05 | zhipeng | Has he shared any update on the GPU side yet ? | |
| 15:35:19 | goldenfri | Last I heard they are still working on it | |
| 15:35:30 | jkilpatr | context for the rest of us? | |
| 15:36:00 | zhipeng | searching the meeting archive now ... | |
| 15:36:18 | goldenfri | I believe you are talking about GPU specs for the cloud declaration? | |
| 15:36:54 | zhipeng | there is a wiki page | |
| 15:37:30 | zhipeng | #topic requirements from scientific working group | |
| 15:37:39 | zhipeng | #link https://wiki.openstack.org/wiki/ScientificWGGPUs | |
| 15:37:51 | zhipeng | #link https://etherpad.openstack.org/p/scientific-wg-gpu-config-guide | |
| 15:38:23 | zhipeng | jkilpatr I think I mentioned in the last meeting that the SWG is now working on GPU requirements | |
| 15:38:40 | zhipeng | it would be great to have a summerized input from them | |
| 15:38:58 | zhipeng | Blair is the one that is contributing the efforts on GPU | |
| 15:39:12 | zhipeng | goldenfri he's from a univ in Aus right ? | |
| 15:39:26 | goldenfri | yes, IIRC | |
| 15:40:17 | goldenfri | I'll follow up with Martial today to see if there are any recent updates | |
| 15:40:22 | zhipeng | I think I will need to ping him again | |
| 15:40:32 | zhipeng | okey that'd be great, thx goldenfri | |
| 15:41:33 | zhipeng | #topic Boston Summit Sessions | |
| 15:42:13 | zhipeng | so Boston Summit will have Forum sessions | |
| 15:42:34 | zhipeng | suppose to be a substitute for the good old design summit | |
| 15:43:02 | zhipeng | I don't think we need a dedicated Cyborg session, we could piggyback on many of the available sessions | |
| 15:43:17 | zhipeng | one is, again, from SWG | |
| 15:43:30 | zhipeng | #link https://etherpad.openstack.org/p/BOS-UC-brainstorming-scientific-wg | |
| 15:44:24 | zhipeng | or do we need a cross-project session with Nova ? | |
| 15:46:39 | jkilpatr | zhipeng, I think we should have a firm grasp of what we need to do with nova and what we want and who's going to do it before we do a cross team session | |
| 15:46:58 | zhipeng | jkilpatr good suggestion | |
| 15:46:59 | jkilpatr | so maybe a couple of weeks from now? when these blueprints are mature? | |
| 15:47:08 | zhipeng | I agree | |
| 15:47:30 | crushil | zhipeng: I agree with jkilpatr. We need to have things streamlined on our end before we propose such sessions | |
| 15:48:08 | zhipeng | Nova will have a placement session anyway, so we could use that occasion even if we don't propose our session | |
| 15:48:16 | zhipeng | crushil agree :) | |
| 15:48:43 | zhipeng | #topic AoB | |
| 15:49:09 | zhipeng | any other buisnees before I could set the miserable bot loose ? lol | |
| 15:52:35 | zhipeng | okey I guess we could conclude the meeting early today | |
| 15:52:44 | zhipeng | thx everyone for participation ! | |
| 15:52:51 | zhipeng | #endmeeting | |
| 15:52:53 | openstack | Meeting ended Wed Mar 22 15:52:51 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 15:52:54 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-03-22-15.02.html | |
| 15:52:56 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-03-22-15.02.txt | |
| 15:52:57 | openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-03-22-15.02.log.html | |
| 15:53:07 | NokMikeR | thanks all | |
| 15:53:28 | zhipeng | got the full log, not bad :P | |
| 15:53:34 | NokMikeR | "its alive" | |
| 15:53:43 | NokMikeR | good its working. | |
| 15:54:11 | zhipeng | it is just running in da background :P | |
| #openstack-cyborg - 2017-03-25 | |||
| 00:31:52 | natra | hi | |
| 01:23:45 | zhipengh[m] | Hey | |
| #openstack-cyborg - 2017-03-29 | |||
| 14:53:37 | jkilpatr | anyone alive in here? | |
| 14:54:10 | jkilpatr | oh man I should check on my commits more often. | |
| 14:54:21 | NokMikeR | barely | |
| 14:54:52 | zhipengh[m] | lol | |
| 15:00:18 | zhipeng | #startmeeting openstack-cyborg | |
| 15:00:19 | openstack | Meeting started Wed Mar 29 15:00:18 2017 UTC and is due to finish in 60 minutes. The chair is zhipeng. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 15:00:20 | openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 15:00:22 | openstack | The meeting name has been set to 'openstack_cyborg' | |
| 15:00:38 | zhipeng | #topic Roll Call | |
| 15:00:49 | crushil | \o | |
| 15:01:09 | zhipeng | \o | |
| 15:01:22 | jkilpatr | o/ | |
| 15:02:20 | zhipeng | waiting for more folks if we have | |
| 15:03:35 | skelso | o/ | |
| 15:03:47 | mpaolino | \o | |
| 15:06:51 | zhipeng | okey let's proceed | |
| 15:07:02 | zhipeng | #topic BP review | |
| 15:07:12 | zhipeng | #link https://review.openstack.org/#/q/project:openstack/cyborg | |
| 15:07:44 | zhipeng | i must appologize i was buried with kubecon work this week so haven't got the time for the reviews | |
| 15:08:02 | zhipeng | i see _gryf posted a lot of good comments | |
| 15:08:10 | zhipeng | as well as rushil and others | |
| 15:08:26 | zhipeng | if we have any outstanding issues, please feel free to shout out | |
| 15:11:16 | jkilpatr | do we want to consolidate all DB interaction to the api end point (presumably on the controllers) or have the agent on the computes update the database themselves. | |
| 15:11:49 | jkilpatr | essentially that's a question of where to handle communication and parallelism. | |
| 15:13:08 | zhipeng | if we choose the latter one, does it mean the controller side will be sometimes out of sync with the agents ? | |
| 15:14:11 | jkilpatr | it would make it a concern, it would be possible to prevent if we tried. | |
| 15:14:32 | jkilpatr | on the other hand if the agent's don't store anything themselves then we can lose accelerator state if anything disrupts the agent. | |
| 15:17:21 | zhipeng | how could we prevent the out-of-sync problem ? using heartbeat ? | |
| 15:17:44 | crushil | I would prefer the latter option> And I believe heartbeat can be an option | |
| 15:18:02 | jkilpatr | just make sure both sides refresh info from the DB when it might have changed. So proper cache invalidation. | |
| 15:18:07 | jkilpatr | and probably more DB load | |
| 15:18:33 | crushil | But the agent should definitely keep its database updated | |
| 15:19:06 | zhipeng | but in real deployment that always hard to manage, I always hear complaints from our product team about the heartbeat | |
| 15:19:21 | zhipeng | cache invalidation is prong to go wrong | |
| 15:19:58 | zhipeng | is there a way for us to simplify so that we could avoid the common shortcomings | |
| 15:20:25 | jkilpatr | so agent <-> rabbit <-> api end point <-> db | |
| 15:20:54 | jkilpatr | that way we don't need invalidation because the end point is the only one that interacts with the DB | |
| 15:22:18 | crushil | Isn't that overkill though? Going through hoops to update db? | |
| 15:22:35 | crushil | Can | |
| 15:23:05 | crushil | Can't we have agent maintain a local copy of the db and agent keeps updating it? | |
| 15:23:52 | zhipeng | but if say we have 3 compute node that all have FPGA based iNIC on it | |
| 15:24:01 | jkilpatr | why does the agent need info about all accelerators? it only needs to manage one machine (there are many agents on many compute nodes, but each one only needs to care about it's own scope) I guess they could have a mini db each but what good is that. | |
| 15:24:07 | zhipeng | if the DB is updated only via local copy | |