Earlier  
Later
New Search
Posted Nick Remark
#openstack-cyborg - 2017-05-31
15:45:29 zhipeng_ you could commit the patch
15:45:35 zhipeng_ and then iterate around it
15:45:58 zhipeng_ since we need the stub to align with agent/conductor/api
#openstack-cyborg - 2017-06-01
22:25:27 zhipeng #endmeeting
22:25:29 openstack Meeting ended Thu Jun 1 22:25:27 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
22:25:30 openstack Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-05-31-15.12.html
22:25:31 openstack Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-05-31-15.12.txt
22:25:32 openstack Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-05-31-15.12.log.html
22:25:59 zhipeng this is embarrassing ...
#openstack-cyborg - 2017-06-06
13:27:55 jkilpatr trying to plan out rpc and messaging between the conductor and the agents at least. Not sure if we want a spec for this as it's not going to be a stable interface
13:28:41 jkilpatr kinda hard to start from zilch. Maybe we should build from one end where I look at the driver code and build the agent up then the conductor.
15:15:56 zhipengh[m] Might be a good approach to work from driver
15:16:42 zhipengh[m] RPC and msg between agent and conductor should be quite general, right ?
16:22:58 jkilpatr yes it should be very general, I was just going to use oslo messaging/rpc and was reading the docs on that.
#openstack-cyborg - 2017-06-07
14:07:59 NokMikeR any meeting today?
14:09:08 zhipeng_ yes I just sent out the email to the openstack-dev
14:09:14 zhipeng_ weekly meeting as usual
14:09:37 NokMikeR ok thanks
14:59:37 crushil \o
14:59:48 jkilpatr o/
15:00:22 zhipeng_ hey
15:00:43 zhipeng_ let's staaaart the longest irc meeting ever
15:00:51 jkilpatr can't be as bad as last week
15:00:56 openstack Meeting started Wed Jun 7 15:00:56 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:56 zhipeng_ #startmeeting openstack-cyborg
15:00:57 openstack Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:00 openstack The meeting name has been set to 'openstack_cyborg'
15:01:05 zhipeng_ hahaha
15:01:10 zhipeng_ let's hope so
15:01:18 zhipeng_ okey so quick update from my side
15:01:22 zhipeng_ on the api/db patch
15:01:40 zhipeng_ #topic BP discussion
15:01:43 zhipeng_ #link https://review.openstack.org/#/c/445814/
15:02:07 zhipeng_ so ChrisD reviewed with the comments that there is an ongoing discussion on the traits
15:02:16 zhipeng_ we might consider to align our design to it
15:02:43 zhipeng_ originally, the placement resource provider was meant for just compute node
15:02:53 jkilpatr I was looking over that, care to summarize?
15:03:16 zhipeng_ sure I'm putting my thoughts together now
15:03:27 zhipeng_ so now the placement team see the pitfall for that
15:03:48 zhipeng_ since for example for shared storage (external arrays I would suppose)
15:04:03 zhipeng_ if you only count the storage side of things on the compute node
15:04:22 zhipeng_ your resource provider will never correctly reflect the required traits
15:04:43 jkilpatr so this is an issue with accelerators that may be shared between many computes?
15:04:48 zhipeng_ the resouce provider should reflect the shared storage arrays, rather than only local discks
15:05:02 zhipeng_ no, I think this is an issue for accelerators as whole
15:05:14 jkilpatr how so?
15:05:23 zhipeng_ since if the resource provider only identify with compute node
15:05:56 zhipeng_ we could wind up with the same problem as we have now, since accelerator characters are bundled with the compute charaters
15:06:13 zhipeng_ well we could have our own resource class for sure, but that does not solve the problem
15:06:36 zhipeng_ nova scheduler asks the placement api to provide all the necessary resources
15:07:00 zhipeng_ and for Cyborg, one of the important goals is that accelerators being treated as the first class citezen
15:07:50 zhipeng_ meaning that we should have indiidual resource providers for accelerators
15:08:20 zhipeng_ from the email link Chris provided, there is an etherpad documenting the "Plan B"
15:09:02 zhipeng_ which I liked very much, is working on to extend the current nested resource provider definition, to a more relaxed, multiple resource providers one
15:09:02 jkilpatr ok so the issue is that if we have a 'gpu' resource provider it's dependent on computes in a way that resource providers aren't supposed to be.
15:09:11 zhipeng_ yes exactly
15:09:42 zhipeng_ the scheduling decision would still largely depends on the regular compute features, since we are just part of the traits
15:09:59 crushil interesting
15:10:12 zhipeng_ so back to the "Plan B", the current nested resource provider model is designed primarily for stuff like NUMA nodes
15:10:22 zhipeng_ where you got this parent-child relationship
15:10:28 crushil So, how does that change our implementation?
15:10:42 zhipeng_ the Plan B extneds the scope to be more general, meaning for Cyborg use cases
15:11:05 zhipeng_ we could have multiple resource provider for each and every accelerators
15:11:14 zhipeng_ (if they deemed important for the workload)
15:11:23 zhipeng_ crushil the change is that
15:11:46 zhipeng_ our DB design has to align with the proposed nested resource provider/trait design
15:12:02 zhipeng_ at least DB schemas
15:12:18 zhipeng_ so that when cyborg agent populate our inventory to the placement api
15:12:25 zhipeng_ it could understand it correctly
15:13:59 crushil Ok, what about the other specs?
15:14:13 zhipeng_ not concerned that much :)
15:14:18 crushil gotcha
15:14:58 zhipeng_ So I'm thinking we might need two DB schemas
15:15:15 zhipeng_ the current one in the spec patch, could be used for the discovery phase
15:15:37 zhipeng_ that is when user start the cyborg service and then agent/driver do the discovery/pre-config
15:15:53 zhipeng_ collect what we have, on the host
15:16:16 zhipeng_ the second set of schema needs to be aligned with nested resource provider
15:16:33 zhipeng_ to interact with placement api and eventually nova-scheduler
15:16:53 zhipeng_ for the VM to select the correct accelerator resource
15:17:19 jkilpatr so we need to maintain two parallel db's for each purpose or do you mean we want to change the format in a future release?
15:18:20 zhipeng_ what I'm thinking is that we don't have exhaustive knowledge on the hardware now
15:18:58 zhipeng_ therefore we keep a seperate DB schema, the host side one should be more extendable or more abstract
15:19:17 zhipeng_ But on another thought
15:19:23 zhipeng_ it might be just too complex .....
15:19:26 zhipeng_ what do you guys think
15:19:49 jkilpatr I think we should try and keep one db as much as possible, I don't want to try and maintain parallel sets of data
15:19:58 zhipeng_ that makes sense
15:20:24 crushil I agree, having multiple DBs is just clunky
15:21:04 zhipeng_ in that case we will just use the resource provider schema,I will follow up with Chris to see which one I should use
15:21:11 zhipeng_ the current one or the proposed one
15:22:19 jkilpatr sounds good.
15:22:56 jkilpatr Anything else on that subject?
15:22:59 zhipeng_ nope
15:23:13 zhipeng_ anything else from you guys on the open spec ?
15:23:33 crushil nope
15:23:51 zhipeng_ great
15:23:58 zhipeng_ #topic initial code development
15:24:05 zhipeng_ so, any roadblocks
15:24:39 jkilpatr been trying to understand oslo rpc and message passing and start structuring the conductor/agent
15:24:52 zhipeng_ sounds like a great start :)

Earlier   Later