| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2017-05-31 | |||
| 15:12:22 | zhipeng_ | jkilpatr about the packaging | |
| 15:12:30 | zhipeng_ | could you elaborate a little bit more ? | |
| 15:12:36 | zhipeng_ | #topic packaging options | |
| 15:12:52 | jkilpatr | So I was wondering how we easily setup the project while we're doing dev | |
| 15:13:19 | jkilpatr | I don't know what you guys have for test environments but I can stand them up and tear them down very easily, so an ansible playbook that just uses pip to install the components would make me happy. | |
| 15:13:39 | jkilpatr | I don't know what other sort of distribution system we would use. So suggestions are welcome. | |
| 15:14:19 | zhipeng_ | pip would be the common practice for OpenStack, right ? | |
| 15:14:42 | jkilpatr | I'm not actually sure never installed a project not packaged by someone for me... | |
| 15:15:07 | jkilpatr | but yes it's python I don't see what else they would use, except maybe some sort of heat / mistral stuff. | |
| 15:15:29 | crushil | I use devstack for dev or RDO if I want to test it in a production style environment | |
| 15:15:41 | zhipeng_ | mistral got a different system ? | |
| 15:15:45 | zhipeng_ | hey crushil | |
| 15:15:59 | jkilpatr | well you could do it with mistral I have no idea if it's a good idea, never did anything with it myself. | |
| 15:16:10 | jkilpatr | anyways sounds like no one has an issue with pip | |
| 15:16:19 | zhipeng_ | yep I guess so | |
| 15:17:14 | zhipeng_ | #agreed pip for packaging options | |
| 15:17:40 | zhipeng_ | #topic development process | |
| 15:18:31 | zhipeng_ | I will address ChirsD and Justin's comment on the api spec | |
| 15:18:51 | zhipeng_ | so after spec freezes, how should we coordinate on the code development ? | |
| 15:19:07 | zhipeng_ | shall we write each part first ? | |
| 15:20:10 | jkilpatr | I think we should start and put up a review quickly, wait until it's possible to use all the different reviews together and then merge them and move on from there. | |
| 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 | zhipeng_ | #startmeeting openstack-cyborg | |
| 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: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 | 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: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: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 | |