| *** luyao has joined #openstack-nimble | 01:25 | |
| *** yuntongjin has joined #openstack-nimble | 01:27 | |
| *** luyao has quit IRC | 01:50 | |
| zhenguo | morning nimble | 01:56 |
|---|---|---|
| liusheng | morning | 01:58 |
| RuiChen | hi, nimble folks :-) | 01:58 |
| zhenguo | liusheng, RuiChen: o/ | 01:59 |
| liusheng | will the meeting be in IRC ? | 01:59 |
| zhenguo | yes | 02:00 |
| liusheng | cool | 02:00 |
| *** lei-zh has joined #openstack-nimble | 02:00 | |
| zhenguo | #startmeeting nimble | 02:00 |
| openstack | Meeting started Thu Nov 17 02:00:15 2016 UTC and is due to finish in 60 minutes. The chair is zhenguo. Information about MeetBot at http://wiki.debian.org/MeetBot. | 02:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 02:00 |
| openstack | The meeting name has been set to 'nimble' | 02:00 |
| liusheng | o/ | 02:00 |
| zhenguo | hi everyone | 02:00 |
| shihanzhang | o/ | 02:00 |
| zhenguo | the agenda: | 02:00 |
| lei-zh | o/ | 02:00 |
| zhenguo | #link https://wiki.openstack.org/wiki/Meetings/Nimble#Agenda_for_next_meeting | 02:00 |
| zhenguo | shaohe_feng, yuntongjin: are you around? | 02:01 |
| yuntongjin | hi | 02:01 |
| zhenguo | ok, let's jump in | 02:01 |
| zhenguo | #topic announcements and reminders | 02:01 |
| zhenguo | we have added db/object/scheduler tests last week and new functional tests work well now, thanks everyone who contributed to the tests work | 02:02 |
| shaohe_feng | hi all | 02:02 |
| shihanzhang | good work | 02:02 |
| zhenguo | liusheng will work on both functional tests and tempest, anyone who wants to help can contact with him :) | 02:03 |
| zhenguo | and a new project nimble-specs is ready now, we can use it in futue | 02:03 |
| zhenguo | we have a new contributor luyao who is very active recently, let's welcome luyao :P | 02:04 |
| RuiChen | o/ | 02:04 |
| yuntongjin | :-D | 02:04 |
| liusheng | how much tests should be added before we announce the Nimble project? :P | 02:04 |
| zhenguo | liusheng: I'm not sure, but seems it's enough, we can continue to add tests after we are public | 02:05 |
| RuiChen | good to see new contributors | 02:05 |
| liusheng | zhenguo: cool | 02:05 |
| zhenguo | shaohe_feng: do you think we need to add more tests before going public? | 02:06 |
| RuiChen | what about add a coverage jenkins job? | 02:06 |
| liusheng | RuiChen: agree :) | 02:06 |
| shaohe_feng | maybe, one exmaple test case for authorization? | 02:06 |
| zhenguo | shaohe_feng: agree | 02:07 |
| zhenguo | shaohe_feng: we still have two days this week :P | 02:07 |
| shaohe_feng | zhenguo: yes. let add it these two days. | 02:07 |
| zhenguo | shaohe_feng: ok | 02:08 |
| zhenguo | not much of announcement, anyone else have a thing here? | 02:08 |
| zhenguo | we can continue to discuss about tests in open discussion topic :) | 02:08 |
| RuiChen | so what's the plan that we publish nimble in community? which day and what action? | 02:08 |
| zhenguo | RuiChen: hah, let's move on to next topic | 02:09 |
| zhenguo | #topic our next plan | 02:09 |
| yuntongjin | the plan is before hackthon? | 02:09 |
| zhenguo | ok, let's talk about our next plan :P | 02:09 |
| zhenguo | maybe next week? | 02:09 |
| zhenguo | or at the end of this week | 02:10 |
| RuiChen | yuntongjin and shaohe_feng will join bug smash in Shenzhen? | 02:10 |
| yuntongjin | we won't | 02:10 |
| liusheng | hope we can attract new comer in hackthon :) | 02:10 |
| RuiChen | and lei-zh? | 02:10 |
| zhenguo | oh, that's a shame! | 02:10 |
| yuntongjin | lei-zh will | 02:10 |
| lei-zh | I will be there | 02:10 |
| zhenguo | why you won't go? | 02:10 |
| zhenguo | lei-zh: hah | 02:10 |
| shaohe_feng | RuiChen: no. no budget for me. | 02:11 |
| liusheng | shaohe_feng: it is a pity | 02:11 |
| zhenguo | shaohe_feng, yuntongjin: oh, that's a pity | 02:11 |
| yuntongjin | some time in next week, like wendsday | 02:11 |
| yuntongjin | to public Nimble | 02:11 |
| zhenguo | shaohe_feng, yuntongjin: I thought we can have a meetup in the hackthon | 02:11 |
| yuntongjin | haha | 02:12 |
| RuiChen | that's shame, we can pick Beijing for next Bug Smash :-) | 02:12 |
| zhenguo | lol | 02:12 |
| liusheng | the next boss is Intel :P | 02:12 |
| *** luyao has joined #openstack-nimble | 02:13 | |
| yuntongjin | we can do bug smash remotely | 02:13 |
| shaohe_feng | zhenguo: you need to pr欧模特 | 02:13 |
| RuiChen | It's great, yuntongjin, IRC connect us :-) | 02:14 |
| shaohe_feng | promote nimble in bug smach | 02:14 |
| shaohe_feng | smash | 02:14 |
| zhenguo | shaohe_feng: sure | 02:14 |
| zhenguo | maybe we will have a presentation there | 02:14 |
| yuntongjin | there should be a presentation there | 02:14 |
| zhenguo | but you won't be there :( | 02:15 |
| yuntongjin | i know it won;t be same, but i can almost hear it when you presenting | 02:15 |
| yuntongjin | lol | 02:15 |
| zhenguo | lol | 02:16 |
| RuiChen | Live show for nimble presentation, hah | 02:16 |
| zhenguo | hah, ok let's continue | 02:16 |
| yuntongjin | so, how about next Wendsday to public Nimble? | 02:16 |
| zhenguo | I think it should be ok | 02:16 |
| zhenguo | so we still have about a whole week | 02:17 |
| zhenguo | we can talk about the procedure of going public | 02:17 |
| zhenguo | firstly, I think we need a eamil to formally announce our project in the mailling list | 02:17 |
| liusheng | should the tempest plugin be added before going public ? | 02:18 |
| zhenguo | liusheng: if you can, that would be wonderful | 02:18 |
| liusheng | zhenguo: I will try | 02:18 |
| zhenguo | liusheng: thanks very much | 02:18 |
| RuiChen | yeah, procedure and time are important, zhenguo | 02:18 |
| zhenguo | RuiChen: yes | 02:18 |
| zhenguo | then, we need to use launchpad to track our bug and features and maybe use psecs for bp | 02:19 |
| zhenguo | s/psecs/specs | 02:19 |
| RuiChen | UT, funcational, Tempest, wiki, API doc, devref should be ready, anything else? | 02:19 |
| liusheng | that is way of big-tent, hah | 02:20 |
| zhenguo | hah | 02:20 |
| RuiChen | good tips, we have a checklist for big-tent | 02:20 |
| RuiChen | liyongle draft it | 02:20 |
| zhenguo | and another important thing is review rules | 02:21 |
| zhenguo | we shouldn't merge directly after we are public :( | 02:21 |
| yuntongjin | i like using specs to disuss new feature | 02:21 |
| zhenguo | yuntongjin: yes | 02:22 |
| zhenguo | all things should be changed, we should work like an official project | 02:22 |
| zhenguo | changes will be approved once 2 core +2 are posted | 02:23 |
| liusheng | some official projects don't like official projetcs now, :( | 02:23 |
| zhenguo | liusheng: hah, | 02:23 |
| zhenguo | as we will restrict our review rules, everyone should try to do more reviews | 02:24 |
| zhenguo | especially core reviewers | 02:24 |
| RuiChen | agree, review should be match the community rules, even if It's slow | 02:24 |
| zhenguo | RuiChen: agree | 02:25 |
| zhenguo | but we can ping any core here for reviewing if needed | 02:25 |
| zhenguo | if our cores are all active enough, I think it will not be that slow | 02:25 |
| liusheng | yeah we are in a same timezone | 02:25 |
| RuiChen | good point ^^ | 02:26 |
| zhenguo | I will paste the contribution report link here at every meeting | 02:26 |
| zhenguo | #link http://stackalytics.com/report/contribution/nimble/90 | 02:26 |
| zhenguo | from the link above we can see that the activeties of every contributor | 02:27 |
| zhenguo | we will add/remove core reviewers according the contribution report there | 02:27 |
| zhenguo | wdyt? | 02:27 |
| zhenguo | that's also what offical project do now | 02:27 |
| liusheng | agree | 02:28 |
| RuiChen | yeah, that's reasonable | 02:28 |
| zhenguo | oh, RuiChen mostly focuses on nimbleclinet, we should also paste the client contribution like here :P | 02:28 |
| *** fredli has joined #openstack-nimble | 02:29 | |
| zhenguo | oh, welcome fredli | 02:29 |
| fredli | Hi | 02:30 |
| zhenguo | fredli: o/ | 02:30 |
| fredli | Glad to join this amazing project | 02:30 |
| liusheng | welcome :) | 02:30 |
| RuiChen | hi, fredli we talk about your contribute for big-tent checklist, thank you | 02:30 |
| zhenguo | fredli: we are talking about the procedure of going public now | 02:30 |
| zhenguo | fredli: do you have some suggestion here? | 02:31 |
| fredli | Please go ahead | 02:31 |
| zhenguo | ok | 02:31 |
| zhenguo | shaohe_feng, yuntongjin: do you have anything else here? | 02:31 |
| yuntongjin | not much | 02:32 |
| zhenguo | ok, | 02:32 |
| yuntongjin | we need prepare challenge from communit | 02:32 |
| shaohe_feng | z | 02:32 |
| zhenguo | yuntongjin: sure | 02:32 |
| zhenguo | ok, what's next | 02:32 |
| zhenguo | #topic Ocata priorities | 02:33 |
| yuntongjin | and think about some killer feature | 02:33 |
| zhenguo | yuntongjin: sure, we can talk about it in our O priorites | 02:33 |
| zhenguo | I listed many things to do on our trello board | 02:33 |
| zhenguo | oh, do you think we should keep using our private trello board? | 02:34 |
| zhenguo | or track bugs and features using launchpad | 02:34 |
| RuiChen | I think RAID should one, and nova prepare to implement it, but it's difficult for nova | 02:34 |
| zhenguo | RuiChen: yes, but RAID depends on Ironic's RAID on deploy time feature | 02:35 |
| zhenguo | which is not finished yet | 02:35 |
| zhenguo | #link https://trello.com/b/FBsIvUTp/ironic-nimble-plan | 02:36 |
| RuiChen | I think it's not conflicted, we can set the trello to public and link it in launchpad | 02:36 |
| zhenguo | RuiChen: agree | 02:36 |
| liusheng | zhenguo: may we can paste this link in our wiki ? | 02:36 |
| zhenguo | liusheng, RuiChen: yes | 02:36 |
| RuiChen | yep, liusheng | 02:36 |
| yuntongjin | sure | 02:36 |
| zhenguo | liusheng, RuiChen: but should we create a new trello board? | 02:36 |
| RuiChen | let me check it | 02:37 |
| zhenguo | a public trello board for Nimble instead of an old with all our histroy there seems it's better | 02:37 |
| zhenguo | wdyt? | 02:37 |
| liusheng | zhenguo: sure | 02:38 |
| yuntongjin | wiki and etherpad would be more community way | 02:38 |
| RuiChen | I think it should be ok, fredli, any suggestion? | 02:38 |
| zhenguo | yuntongjin: yes, etherpad should be used | 02:38 |
| liusheng | zhenguo: wiki, lp, etherpad | 02:39 |
| zhenguo | yuntongjin: but Ironic have a trello board for it's priorities features | 02:39 |
| zhenguo | we can add a etherpad for our Ocata priorites | 02:39 |
| yuntongjin | let's keep it internel | 02:39 |
| zhenguo | yuntongjin: lol | 02:40 |
| yuntongjin | move the info to spec/wiki/etherpat | 02:40 |
| zhenguo | yuntongjin: and launchpad | 02:40 |
| zhenguo | liusheng: you can register a bp for tempest in our launchpad | 02:41 |
| yuntongjin | sounds good, that's task before annoucement | 02:41 |
| liusheng | zhenguo: ok | 02:41 |
| zhenguo | ok, so after this meeting, we will try to use launchpad for bug or feature tracking | 02:41 |
| zhenguo | about the detailed priorites, I can prepare a list then we need to discuss more | 02:42 |
| zhenguo | do you prefer to use a etherpad or on our trello board | 02:42 |
| yuntongjin | etherpad | 02:43 |
| RuiChen | agree | 02:43 |
| zhenguo | ok | 02:43 |
| zhenguo | ok, anything else here? | 02:43 |
| zhenguo | #topic open discussion | 02:44 |
| zhenguo | so do you have anything else want to talk about | 02:44 |
| zhenguo | open discussion :P | 02:44 |
| shaohe_feng | zhenguo: I think we more exception test for nimble. | 02:44 |
| zhenguo | shaohe_feng: agree | 02:45 |
| shaohe_feng | zhenguo: luyao has find a issue. | 02:45 |
| shaohe_feng | zhenguo: not sure her patch is ready. | 02:45 |
| zhenguo | shaohe_feng: I reviewed luyao's patch yesterday | 02:45 |
| zhenguo | shaohe_feng: that's all because we don't have test cases for engine service | 02:45 |
| zhenguo | shaohe_feng: so I think we need a volunteer work on engine service tests next week | 02:46 |
| shaohe_feng | zhenguo: agree. | 02:46 |
| zhenguo | shaohe_feng, liusheng: it should be in UT or functional tests? | 02:47 |
| shaohe_feng | zhenguo: more exception handle is very useful for a project stable | 02:47 |
| yuntongjin | at least have some UT for it | 02:47 |
| liusheng | shaohe_feng: it is about the functionality of engine services ? | 02:47 |
| zhenguo | yes, | 02:48 |
| RuiChen | UT first, then funcational | 02:48 |
| liusheng | so we can add a coverage jenkins job as RuiChen suggested | 02:48 |
| zhenguo | agree, and when adding tests, I think you can find many bugs in our codes, please also fix that | 02:49 |
| liusheng | I am not fimilar with the coverage job | 02:49 |
| zhenguo | liusheng: I'm not familiar as well | 02:49 |
| zhenguo | liusheng, RuiChen: seems we can add coverage job later | 02:49 |
| zhenguo | I think currently we highly need an dsvm job in our gate :P | 02:50 |
| shaohe_feng | fimilar is not the issue. seems all of us are good learner. :P | 02:50 |
| zhenguo | shaohe_feng: hah, | 02:50 |
| yuntongjin | shaohe is a fast learner | 02:50 |
| liusheng | zhenguo: that seems a part of tempest work | 02:50 |
| zhenguo | liusheng: oh sorry, | 02:51 |
| RuiChen | so, the proirity is ? UT > functional > dsvm > converage? zhenguo | 02:51 |
| zhenguo | RuiChen: I think so, | 02:51 |
| zhenguo | dsvm is part of tempest, haha | 02:52 |
| RuiChen | same to me, let's do it | 02:52 |
| zhenguo | ok | 02:52 |
| RuiChen | I can try to add coverage for python-nimbleclient, because the UT | 02:53 |
| zhenguo | only 8 minites left, do you have anything else want to discuss? | 02:53 |
| RuiChen | is ready for now, then do it for nimble | 02:53 |
| RuiChen | nothing from me | 02:53 |
| zhenguo | oh, I think everyone here can talk about what he wants to do after this meeting | 02:54 |
| liusheng | nothing else | 02:54 |
| RuiChen | good start, we discuss in whole meeting time, thanks everybody | 02:55 |
| zhenguo | haha | 02:55 |
| yuntongjin | do more review, will push scheduler test to merged, migrate trallo info to wikil/spec... | 02:55 |
| zhenguo | yuntongjin: ok thanks | 02:55 |
| zhenguo | yuntongjin will focuse on scheduler tests | 02:56 |
| zhenguo | I will work on engine service tests | 02:56 |
| RuiChen | shihanzhang and I merge the instance resource CLI today | 02:57 |
| zhenguo | RuiChen, shihanzhang: thanks, that should be done before we are public :P | 02:57 |
| RuiChen | of course, :-) | 02:57 |
| zhenguo | liusheng is working on fuctional tests and tempests | 02:58 |
| openstackgerrit | Zhong Luyao proposed openstack/nimble: bug fix: delete instance correctly https://review.openstack.org/398306 | 02:58 |
| liusheng | zhenguo: yeah | 02:58 |
| zhenguo | shaohe_feng, luyao: we can all help to add more tests | 02:58 |
| RuiChen | work hard, luyao, hah | 02:58 |
| *** kevin__ is now known as kevinz | 02:58 | |
| zhenguo | oh, luyao just updated a patch, what a good contributor:P | 02:58 |
| yuntongjin | next time you are in GTC, you will meet her in person | 02:59 |
| RuiChen | on time, first IRC meeting \o/ | 02:59 |
| zhenguo | yuntongjin: haha | 02:59 |
| zhenguo | thanks y'all | 03:00 |
| zhenguo | #endmeeting | 03:00 |
| openstack | Meeting ended Thu Nov 17 03:00:25 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 03:00 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/nimble/2016/nimble.2016-11-17-02.00.html | 03:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/nimble/2016/nimble.2016-11-17-02.00.txt | 03:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/nimble/2016/nimble.2016-11-17-02.00.log.html | 03:00 |
| zhenguo | haha | 03:01 |
| shaohe_feng | zhenguo: when will you go to GTC for the phy nimble evn? | 03:03 |
| zhenguo | shaohe_feng: haha | 03:03 |
| zhenguo | shaohe_feng: neary forgot it, sorry | 03:03 |
| openstackgerrit | liusheng proposed openstack/nimble: Add support for updating instance type https://review.openstack.org/386439 | 03:03 |
| zhenguo | s/neary/nearly | 03:03 |
| zhenguo | shaohe_feng: maybe after we are public or after hackthon? | 03:04 |
| openstackgerrit | liusheng proposed openstack/nimble: Add support for updating instance type https://review.openstack.org/386439 | 03:12 |
| * zhenguo brb | 03:15 | |
| zhenguo | kevinz: are you kevin from ARM? | 03:28 |
| openstackgerrit | liusheng proposed openstack/nimble: Trival-fix: Correct an exception and a method definition https://review.openstack.org/398729 | 03:28 |
| kevinz | zhenguo: Yeah :-) | 03:29 |
| zhenguo | kevinz: oh, welcome to nimble :P | 03:29 |
| kevinz | zhenguo: haha Interested about nimble | 03:29 |
| kevinz | Thanks~ | 03:29 |
| zhenguo | kevinz: hah, please feel free to ping me if you have any question here | 03:30 |
| *** yuntongjin has quit IRC | 03:30 | |
| kevinz | kevinz: Cool~ I will get some knowledge about nimble first, and happy to contribute if I can help | 03:33 |
| kevinz | zhenguo:aha, send to myself, make a mistake...:D | 03:33 |
| zhenguo | kevinz: hah, | 03:34 |
| zhenguo | kevinz: thanks | 03:34 |
| zhenguo | kevinz: maybe this is helpful https://wiki.openstack.org/wiki/Nimble | 03:34 |
| zhenguo | kevinz: and you can use devstack to setup an development evn | 03:35 |
| zhenguo | kevinz: https://github.com/openstack/nimble/blob/master/doc/source/dev/dev-quickstart.rst | 03:36 |
| *** luyao has quit IRC | 03:36 | |
| kevinz | zhenguo: WOw cool, I will try it first on X86 to see what has happened. | 03:37 |
| kevinz | zhenguo: Thanks~ | 03:37 |
| zhenguo | kevinz: np :) | 03:37 |
| openstackgerrit | liusheng proposed openstack/nimble: Add instance deletion api reference https://review.openstack.org/398733 | 03:56 |
| *** luyao has joined #openstack-nimble | 04:36 | |
| *** yuntongjin has joined #openstack-nimble | 04:45 | |
| *** luyao has quit IRC | 05:13 | |
| *** fredli has quit IRC | 05:15 | |
| openstackgerrit | Merged openstack/nimble: Add instance deletion api reference https://review.openstack.org/398733 | 05:23 |
| openstackgerrit | Zhenguo Niu proposed openstack/nimble: Correct some Error response codes in api-ref https://review.openstack.org/398751 | 05:28 |
| *** yuntongjin has quit IRC | 05:50 | |
| *** luyao has joined #openstack-nimble | 05:51 | |
| *** yuntongjin has joined #openstack-nimble | 06:06 | |
| openstackgerrit | ShaoHe Feng proposed openstack/nimble: add PolicyFixture for functional test. https://review.openstack.org/398198 | 06:44 |
| *** luyao has quit IRC | 07:17 | |
| *** luyao has joined #openstack-nimble | 07:19 | |
| zhenguo | shaohe_feng, liusheng: about the current create_instance, do you have any suggestion? we just casted the request to engine now | 07:41 |
| zhenguo | shaohe_feng, liusheng, yuntongjin: how about moving scheduling part to api and rpc call to engine only do some time consuming work | 07:42 |
| zhenguo | otherwise, api request can't get anything returned | 07:43 |
| liusheng | zhenguo: there will be only one nimble-engine in a deployment ? | 07:45 |
| zhenguo | liusheng: yes, currently it is | 07:45 |
| zhenguo | liusheng: but we should consider HA | 07:46 |
| zhenguo | liusheng: our scheduler is not to choose a engine but select one node from ironic node list | 07:46 |
| openstackgerrit | ShaoHe Feng proposed openstack/nimble: add PolicyFixture for functional test. https://review.openstack.org/398198 | 07:47 |
| zhenguo | liusheng: so I think in create_instance api, we can do the node selected work in api, and then cast the rpc request to engine with the selected node | 07:47 |
| liusheng | zhenguo:hmm... sounds reasonable | 07:49 |
| shaohe_feng | zhenguo: you means a thread for to call engine? | 07:49 |
| shaohe_feng | zhenguo: yes. scheduling part to API sounds good. | 07:50 |
| zhenguo | shaohe_feng: seems every api reqeust will in a separte thread now, right? | 07:50 |
| zhenguo | shaohe_feng, liusheng: as our scheduling is not time consuming, just a select work, so we can move it to api, then engine only do ironic node deploy work | 07:52 |
| liusheng | the reason only because you want to return the selectd host info to api when creating an instance ? | 07:53 |
| shaohe_feng | zhenguo: Not sure a thread or a coroutine | 07:53 |
| shaohe_feng | zhenguo: seems eventlet will start coroutine pool. and a request in a coroutine. | 07:54 |
| zhenguo | liusheng: not only because that, I want to catch more exceptions for the procesure of creating an instance then we can give feedback to users | 07:55 |
| zhenguo | shaohe_feng: yes, I think so | 07:55 |
| zhenguo | liusheng: if all things wil done in engine side, we can only find the status is error in db :( | 07:56 |
| shaohe_feng | zhenguo: but for end user, we can treat coroutine are same with thread. | 07:58 |
| liusheng | it looks a bit strange :( | 07:58 |
| zhenguo | shaohe_feng: yes | 07:58 |
| shaohe_feng | zhenguo: about luyao's patch. I really think we need some refactor for create_instance | 07:59 |
| zhenguo | shaohe_feng: yes, I think so, that's why I ask suggestion from you here | 07:59 |
| zhenguo | liusheng, shaohe_feng: if scheduling work in api part, I think there's no need to create an instance object if NoValidHost exceptions raised | 08:01 |
| zhenguo | oh s/NoValidHost/NoValidNode | 08:02 |
| shaohe_feng | zhenguo: a only error status is not help for user to find where the issue come out. | 08:02 |
| zhenguo | shaohe_feng: yes | 08:03 |
| liusheng | zhenguo: a question, does the scheduler need to cache some data, that will make the api service stateful | 08:04 |
| zhenguo | liusheng: oh, yes. | 08:04 |
| shaohe_feng | zhenguo: maybe for create, we can just return 500(server error) and do not create instance, if no node find or we can not associate the node, | 08:05 |
| zhenguo | liusheng: if we split the work, I thing the current cache data should put into db | 08:05 |
| shaohe_feng | zhenguo: then users do not need to delete the instance. | 08:05 |
| zhenguo | shaohe_feng: agree, that should be better | 08:05 |
| zhenguo | shaohe_feng, liusheng: yes, currently we periodically fetch nodes infromation from ironic and cache it in engine service | 08:06 |
| shaohe_feng | zhenguo: the question is that, if error in the status. what should user do? now we do not other api for them to fix the instance, that means this instance is invalide. | 08:06 |
| zhenguo | shaohe_feng, liusheng: but if we move scheduling work to api, that cache data need to put into db like nova | 08:06 |
| liusheng | zhenguo: the stateless api service make the multiple deployments easy, but if not, the situation will be complex | 08:06 |
| zhenguo | liusheng: yes, we need to discuss this more | 08:07 |
| shaohe_feng | liusheng: yes. api is better to be stateless. | 08:08 |
| zhenguo | shaohe_feng: yes, if the instance is error, the only way is to delete it. the error information is for operators instead of end users | 08:08 |
| zhenguo | liusheng, shaohe_feng: but if our api only do something like a db query, it's still stateless, right? | 08:09 |
| zhenguo | liusheng, shaohe_feng: in nova, during the long creating instance procedure, seems we only cast the rpc call to compute at the last step, all others need to wait for return | 08:11 |
| liusheng | zhenguo: if the api depends on db, the db will ensure the synchronous access | 08:13 |
| liusheng | zhenguo: in Nova, it has sperated scheduler service | 08:14 |
| zhenguo | liusheng: yes, but a separete scheduler is not difference | 08:14 |
| zhenguo | liusheng: nova compute collect informations the put it into db | 08:15 |
| zhenguo | liusheng: a request from api to conductor, then conductor ask scheduler for a compute host, then scheduler select it from db and return it to conductor | 08:15 |
| zhenguo | liusheng: and if we use local conductor, seems conductor work is done in api side | 08:17 |
| shaohe_feng | zhenguo: conductor like a Housekeeper, it coordinate all kinds of tasks, and assign them to different component | 08:19 |
| zhenguo | shaohe_feng: yes | 08:20 |
| liusheng | zhenguo: but the request from api to conductor is by rpc | 08:20 |
| zhenguo | liusheng, shaohe_feng: but if we use local conductor, it's not a separate service, right? not sure | 08:21 |
| zhenguo | maybe Kevin_Zheng and RuiChen can help here | 08:21 |
| liusheng | zhenguo: yes, but the api service is not tied with conductor | 08:21 |
| shaohe_feng | zhenguo: what do you means local conductor? | 08:21 |
| shaohe_feng | zhenguo: local conductor are int the same host of API component? | 08:22 |
| zhenguo | shaohe_feng: seems you can configure to use local conductor | 08:22 |
| zhenguo | shaohe_feng: not sure | 08:22 |
| zhenguo | liusheng, shaohe_feng: so do we need a conductor service, lol | 08:23 |
| shaohe_feng | zhenguo: but it is still a seperated process, api still talk with it by RPC? | 08:23 |
| zhenguo | shaohe_feng: I'm not sure, as I understand, it's not a separate service | 08:24 |
| shaohe_feng | zhenguo: so Kevin_Zheng and RuiChen familar with it? | 08:27 |
| zhenguo | shaohe_feng: yes, they are Nova experts | 08:27 |
| zhenguo | shaohe_feng: but seems they are not around | 08:27 |
| liusheng | if we choose to use local task API (local conductor), the request from api to conductor will not through RPC | 08:33 |
| liusheng | zhenguo: but seems the use_local mode of conductor has been deprecated, FYI https://review.openstack.org/#/c/387996/1 | 08:38 |
| luyao | Can we add a new api to allow user associate the instance to the node ? | 08:40 |
| *** luyao has left #openstack-nimble | 08:40 | |
| *** luyao has joined #openstack-nimble | 08:40 | |
| shaohe_feng | zhenguo: ^ | 08:41 |
| shaohe_feng | luyao: maybe we can. | 08:41 |
| liusheng | luyao: sounds like create instance with specific host, like nova does ? | 08:41 |
| luyao | liusheng: yes | 08:41 |
| zhenguo | luyao, liusheng: we can use scheduler_hints for this | 08:42 |
| shaohe_feng | zhenguo: but firstly, we can retry other node if something wrong during create instance. | 08:42 |
| zhenguo | shaohe_feng: yes | 08:44 |
| shaohe_feng | I remeber nova retry in a recursive function. | 08:44 |
| luyao | If the instance is not associated to the node when created, users can do the association manually | 08:45 |
| liusheng | zhenguo: I have confirmed with Kevin_Zheng, that the use_local mode of conductor has been deprecated | 08:45 |
| zhenguo | liusheng: yes, I just googled for that | 08:46 |
| zhenguo | luyao: you mean the whole create process or just communicate with ironic | 08:48 |
| luyao | zhenguo: I am not sure now | 08:49 |
| zhenguo | luyao: end users should not now the node information I think, it's hard to control if they can associate it manually | 08:49 |
| zhenguo | s/now/know | 08:49 |
| zhenguo | luyao: end users could create instances, but there's somthing wrong with that, operators should come to help | 08:51 |
| zhenguo | luyao: and we need to add retry mechism to keep it works well. like rescheduling or retry to communicate with ironic or other services | 08:52 |
| shaohe_feng | zhenguo: associate can also let scheduler to find a new node. I think. | 08:52 |
| zhenguo | shaohe_feng: we can add retry logic here | 08:52 |
| luyao | zhenguo: I have a question, which the instance status can be save to db,if the status is error ,should we save the instance info to db? | 08:53 |
| zhenguo | luyao: currently we should save it to db | 08:53 |
| zhenguo | luyao: maybe with excepton information in future to help operators to debug why | 08:54 |
| shaohe_feng | zhenguo: yes, maybe we refactor the code, some error we do not need to save instance to db, just return 500 error. | 08:54 |
| shaohe_feng | luyao: we can discuss how to refactor the create code. you can give your comments. | 08:55 |
| zhenguo | shaohe_feng: yes, but I still confused about how to refactor it | 08:55 |
| shaohe_feng | zhenguo: yes. we do not need rush | 08:56 |
| zhenguo | shaohe_feng: yes, we need to discuss this more | 08:56 |
| luyao | zhenguo: if the instance's status is unassiociated and user can not do association manually, i think the instance is useless forever, right? | 08:57 |
| shaohe_feng | zhenguo: yes, need think over | 08:57 |
| zhenguo | luyao: I'm thinking a way to refactor our code, and maybe no need to add a new unassociated status | 08:58 |
| zhenguo | luyao: if we failed to set instance info to ironic node, we should reshceduling and destroy the current instance | 08:59 |
| shaohe_feng | zhenguo: unassociated status is just an expedient for the current code. | 09:00 |
| zhenguo | shaohe_feng, luyao: yes, thanks for that | 09:00 |
| shaohe_feng | luyao: you can give some comments for it, and note or Fixme "a good solution will fix it." | 09:01 |
| shaohe_feng | zhenguo: Anthony also do it by this way, and I help to fix it, when I work with him. | 09:03 |
| luyao | shaohe_feng: ok | 09:03 |
| zhenguo | shaohe_feng: Anthony? | 09:04 |
| shaohe_feng | zhenguo: yes, the former qemu maintainer, he said he know every thing except TCG. | 09:05 |
| zhenguo | shaohe_feng: oh, hah | 09:05 |
| shaohe_feng | zhenguo: he write a compiler front-end, write json parser by himself, do not use lib. also can write UI. | 09:07 |
| zhenguo | shaohe_feng: oh, a full stack developer | 09:08 |
| shaohe_feng | zhenguo: sure. full stack. | 09:08 |
| * zhenguo brb | 09:17 | |
| openstackgerrit | Zhong Luyao proposed openstack/nimble: (A good solution will fix it)bug fix: delete instance correctly https://review.openstack.org/398306 | 09:30 |
| openstackgerrit | Merged openstack/nimble: add PolicyFixture for functional test. https://review.openstack.org/398198 | 09:34 |
| *** yuntongjin has quit IRC | 09:34 | |
| zhenguo | shaohe_feng: do you find there are some problems with our ironic client wrapper? | 09:37 |
| *** luyao has quit IRC | 09:45 | |
| *** openstackgerrit has quit IRC | 09:48 | |
| *** openstackgerrit has joined #openstack-nimble | 09:49 | |
| shaohe_feng | zhenguo: any problem do you find? | 09:50 |
| shaohe_feng | zhenguo: liusheng: neturon has a fullstack_testing | 09:50 |
| zhenguo | shaohe_feng: every call will construct a new client | 09:51 |
| shaohe_feng | it starts service and agent. | 09:51 |
| zhenguo | shaohe_feng: I'm trying to use a cached client as IronicClientWrapper have a _cached_client | 09:51 |
| shaohe_feng | zhenguo: Is this _cached_client a singleton? | 09:52 |
| zhenguo | shaohe_feng: yes | 09:53 |
| shaohe_feng | zhenguo: good. | 09:54 |
| *** lei-zh has quit IRC | 09:56 | |
| shaohe_feng | zhenguo: liusheng: http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron | 09:58 |
| shaohe_feng | zhenguo: liusheng: some test rules of neutron. | 09:59 |
| zhenguo | shaohe_feng: seems the rules is very clear there | 10:00 |
| shaohe_feng | zhenguo: yes. for both unit and functional. | 10:01 |
| zhenguo | shaohe_feng: yes | 10:02 |
| openstackgerrit | Merged openstack/nimble: Correct some Error response codes in api-ref https://review.openstack.org/398751 | 10:06 |
| openstackgerrit | Zhenguo Niu proposed openstack/nimble: Use ironic cached_client instead of constructing every time https://review.openstack.org/398924 | 11:02 |
| openstackgerrit | Merged openstack/python-nimbleclient: Support Instance Resource https://review.openstack.org/392399 | 11:06 |
| openstackgerrit | Merged openstack/nimble: Trival-fix: Correct an exception and a method definition https://review.openstack.org/398729 | 11:48 |
| zhenguo | shaohe_feng: seems we also need to add policy check for neutron related actions, like whether we can create port on the specified network | 12:01 |
| shaohe_feng | zhenguo: add policy in nimble or neutron? | 12:14 |
| shaohe_feng | zhenguo: we check the tenant can be authorized to create port? | 12:16 |
| shaohe_feng | zhenguo: but which kind of tenant can be? | 12:16 |
| zhenguo | shaohe_feng: sorry, I was away for smoking | 12:20 |
| zhenguo | shaohe_feng: in Nova, I find we also have a create:attach_network policy check | 12:21 |
| zhenguo | shaohe_feng: but seems it's not reasonable as create request always with a network specified | 12:25 |
| zhenguo | shaohe_feng, liusheng: I think we can list what nova api do for create_instance before the first rpc call issued | 12:33 |
| * zhenguo away | 12:38 | |
| *** lei-zh has joined #openstack-nimble | 14:12 | |
| *** lei-zh has quit IRC | 16:41 | |
| *** openstackgerrit has quit IRC | 19:48 | |
| *** openstackgerrit has joined #openstack-nimble | 19:49 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!