Earlier  
Later
New Search
Posted Nick Remark
#openstack-cyborg - 2018-12-12
03:12:24 Li_Liu Sundar, maybe we can show them how it should work first?
03:12:26 xinranwang Li_Liu: nope, it depends on the DB schemas the ovo object
03:13:03 xinranwang it's just the initial version
03:13:31 Li_Liu xinranwang, the spec should be ready anytime, does it also depends on Coco/zhenghao's work?
03:14:39 Sundar Li_Liu: Yes, the pilot code for Cyborg and its client will be submitted first.
03:15:16 Li_Liu great
03:16:24 xinranwang yes, because the input param for conductor is ovo object
03:16:41 Li_Liu Sundar, I think https://review.openstack.org/#/c/615462/ can be merged
03:17:03 Li_Liu xinranwang, ok\
03:17:08 xinranwang Li_Liu: Btw, I have submitted our POC code with workflow -1
03:17:49 Li_Liu xinranwang, right, understand
03:17:58 Li_Liu thanks a lot for the work
03:18:14 Sundar Li_Liu: The db spec has progressed a lot. Only a couple of points left, which you wanted to address offline. I replied by email about half hour ago.
03:18:52 Coco_gao I received you email
03:19:00 Li_Liu Sundar, I saw that one, I think i address them in my patch already
03:19:01 Yumeng_ Sundar, for tasks in Client and DB https://storyboard.openstack.org/#!/story/2004248. which one has a higher priority currently?
03:19:13 Coco_gao I will update the OVO object patch as well as submmit New DB patch.
03:19:34 Li_Liu Coco_gao, are you gonna work on the DB object based on the new db spec?
03:20:42 xinranwang Coco_gao: I can take over the diff part in conductor if you don't have enough time :)
03:20:59 Coco_gao Yes.
03:21:01 Coco_gao Li
03:21:06 Sundar The table currently named ARQ actually has ExtARQ data, since it includes Cyborg-private fields. That's why I said the table is better named as ExtARQ. ExtARQ is a superset of ARQ
03:21:26 Li_Liu that seems a lot of work, you might wanna offload them
03:22:01 Coco_gao xinran, I have the diff function in the old ovo patch, so it won't take long if the db object is ready.
03:22:26 Li_Liu Sundar, you mean there will not be a ARQ table then. only ExtARQ
03:22:51 Sundar Li_Liu: Yes
03:22:56 Coco_gao Li, I think the ExtARQ combines old ARQ and ExtARQ
03:23:02 Li_Liu ok, I will make the change right now
03:23:11 Sundar Li_Liu: Thanks
03:24:20 Sundar For the question of whether attach handles go with deployables or devices, one could argue both ways but I thought it is easier if it goes at the device level. if we want to keep it in the current form, it may require an upgrade later. As long we are all ok with that, I am fine
03:24:24 Coco_gao Li_Liu, I will implement table device and deployable and attribute. Other DB work might owned by zhenghao or anyone else?
03:24:57 Sundar Coco_gao: It may make sense to split the db work, since there are so many. Thanks for suggesting that.
03:24:59 Li_Liu Coco_gao, I will talk with zheng hao and xinran for the work load
03:25:07 Yumeng_ coco I have can help
03:25:22 Coco_gao OK, you can discuss with zhenghao about other DB works.
03:25:31 xinranwang Coco_gao: ok, this patch is an initial version of conductor update, https://review.openstack.org/#/c/624340/, plz review it to see if it fits your requirements. It need more functions to be implemented.
03:25:31 Coco_gao Thanks, Yumeng_
03:25:43 Li_Liu Sundar, I kinda lean towards let attachHandle reference to Device now
03:25:51 Coco_gao #info Coco_gao
03:26:42 Sundar Li_Liu: OK :) It is all a bit hypothetical because the devices in Stein train frame will work fine either way.
03:27:38 Sundar BTW, even if we put in device level, we have to figure out how to handle a PCI card wih 2 FPGAs, if that ever becomes a thing
03:27:54 Li_Liu sure
03:28:32 Coco_gao xinranwang, I will check your patch, thank you.
03:28:37 Li_Liu ok, I think it's great we can finalize the spec and can push things further
03:29:28 Li_Liu #topic AoB
03:29:57 Li_Liu On top of what we have discussed, do you guys have anything to add?
03:30:11 xinranwang Sundar: do you have any concern about the POC code I put in the community?
03:30:51 Coco_gao Sundar, You mean that cyborg client code is ready?
03:31:04 Sundar xinranwang: My main concern is this is an outdated poc, and it may cause confusion.
03:31:35 Sundar Coco_gao: I have made some changes to Cyborg client too. I will put that on a feature branch too. But it is still WIP
03:31:35 Coco_gao or we still need other one to implement that?
03:32:38 xinranwang Sundar: I understand your concern, it should be clarified to nova that these patches is for reference only
03:32:52 Sundar BTW, clarification: The prototype is not the final code. There will be many TODOs. Our developers are free to re-implement, or fill the gaps while leveraging the prototype
03:33:34 Coco_gao Yes , I think so.
03:34:03 Sundar Coco_gao, Zhenghao and possibly Yumeng_ are working on the db. Xinran is working on the agent/conductor API and the diff. Is that correct?
03:34:47 Li_Liu Sundar I think so
03:35:10 Yumeng_ Sundar: yes, next time please also email me(bao.yumeng@zte.com.cn) if there is any update about the specificaiton :)
03:35:30 Coco_gao Or add yumeng to the reviewer.
03:35:33 Sundar Yumeng_: Sure :) Thanks for helping!
03:35:40 Li_Liu We did not have you before? Yumeng_
03:35:48 Li_Liu We will in the future
03:36:12 Coco_gao That's great
03:36:13 Yumeng_ not yet before. great! :)
03:36:19 Li_Liu :)
03:36:32 Li_Liu ok, I think we can wrap up for today
03:36:39 Sundar We have tons more things to do. Like new v2 APIs, checking that v1 APIs srtill work, adding tempest tests, ....
03:36:58 Li_Liu oh yes, gonna be a fun 2019
03:37:02 Sundar Can we identify owners for that? I propose that Xinran and I can work on the APIs?
03:37:12 Li_Liu sure
03:37:27 Sundar xinranwang: I think you have worked with pecan layer before. Are you fine with that?
03:38:00 Coco_gao OK, we can identify the owner now.
03:39:10 Sundar Do we have some developers to check rolling upgrades from Rocky to Stein? The v1 APIs should return null result in Stein, I think
03:39:23 Sundar For e.g. list deployables will return []
03:41:52 Sundar Silence ... Shall we take this up next week?
03:42:02 Yumeng_ Sundar: did you notice this patch https://review.openstack.org/#/c/619997/
03:42:15 Coco_gao I can list deployables in my previous POC.
03:42:26 Li_Liu Sundar, I guess we can come up with a complete list first
03:42:31 xinranwang Sundar: Yes, I can work with you on Cyborg-Nova API side
03:43:00 Coco_gao Have you got authenticated before asking.
03:44:10 Sundar Yumeng_: We are dropping the accelerators table in Stein. So this API should be modified to return [] all the time in Stein?
03:44:20 Yumeng_ I made this change in v1 APIs to avoid returns null for the situation where we actually have accelerators
03:45:03 Sundar Yumeng_: is anybody using Cyborg today, and therefore relying on tv1 he API?
03:46:23 Sundar *the v1 API
03:46:49 Li_Liu I don't think anyone is using cyborg
03:46:53 Sundar Li_Liu: OK, we can form that task list by next meeting
03:47:19 Li_Liu Sundar, we can talk on zoom in case you need it
03:48:11 Sundar Sure
03:48:11 Coco_gao I can get the deployable list, I also have the test code if you need that.
03:48:32 Yumeng_ Sundar,Li liu: ok, maybe next meeting. I will dig more to discuss with you guys.
03:48:35 Coco_gao Anyway, let's arrange other meething.
03:49:39 Li_Liu ok
03:50:11 Li_Liu can we wrap up? I think it's almost lunch time for china folks :P
03:50:43 Coco_gao Yes, It's time for lunch, bye.
03:50:50 Li_Liu #endmeeting
03:50:52 openstack Meeting ended Wed Dec 12 03:50:50 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
03:50:53 Yumeng_ see you guys
03:50:54 openstack Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-12-12-03.05.html
03:50:55 openstack Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-12-12-03.05.txt
03:50:56 Li_Liu have a good day/night
03:50:57 openstack Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-12-12-03.05.log.html

Earlier   Later