Earlier  
Later
New Search
Posted Nick Remark
#openstack-cyborg - 2017-05-31
15:20:18 jkilpatr it's important we have a good test/integration workflow
15:20:48 jkilpatr um what about standards, I assume most of pep8 (longer line length limit maybe) + some unit test coverage?
15:21:12 zhipeng_ that would be reasonable
15:21:26 zhipeng_ what do you mean by start and put up a review quickly ?
15:21:55 jkilpatr I mean don't go off and code everything then put it up for review. Ideally we start playing around with and testing each others code very early.
15:22:24 jkilpatr it's kinda embarassing to put up unfinished stuff, everyone want's to come in and micdrop great code. But it's not the best way to work.
15:23:30 zhipeng_ okey that I agree
15:24:30 zhipeng_ we will need multiple patches for the spec anyways
15:24:57 zhipeng_ no patch would be too small :P
15:34:20 jkilpatr any other business? I know we still haven't managed to fully define the nova workflow but I need to find time to play with that, ideally with skeleton versions of the rest of cyborg, which is what we agreed on last week.
15:36:40 zhipeng_ i don't have any other stuff on the plate
15:39:22 zhipeng_ so I will leave the channel open for another hour, then I'll close it
15:39:59 crushil Ok
15:40:01 jkilpatr cool, we can get the api commit in and meet next week to start putting things together sound good?
15:40:14 crushil Sounds good to me
15:42:33 zhipeng_ yes
15:42:56 crushil Does nova accelerators work well with virtIO today?
15:43:33 zhipeng_ I'm not aware Nova got vanila virtio based drivers
15:43:39 zhipeng_ for accelerators
15:44:17 zhipeng_ I think for Nova, it mainly means see if kvm got virtio support
15:44:21 crushil Ok. I'll look. I have created stubs for the code that I am going to fill in the next couple months
15:45:20 zhipeng_ i think as Justin suggested, if you got the stubs and basic virtio ops ready
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

Earlier   Later