*** wanghao has joined #openstack-mogan | 00:34 | |
*** wanghao has quit IRC | 00:36 | |
*** wanghao has joined #openstack-mogan | 00:37 | |
*** wanghao_ has joined #openstack-mogan | 00:45 | |
wanghao_ | morning! | 00:45 |
---|---|---|
*** wanghao has quit IRC | 00:48 | |
zhenguo | morning! | 01:05 |
*** liujiong has joined #openstack-mogan | 01:11 | |
wanghao_ | zhenguo: ping | 01:15 |
zhenguo | wanghao_: pong | 01:15 |
wanghao_ | zhenguo: do you liusheng's comments in manage spec? | 01:15 |
zhenguo | wanghao_: sorry, I'm in a internal meeting, not got time to review that | 01:16 |
wanghao_ | zhenguo: okay, never mind. | 01:17 |
wanghao_ | zhenguo: take your time, it's not a ruhs | 01:18 |
wanghao_ | liusheng: ping | 01:22 |
*** liusheng has quit IRC | 01:23 | |
openstackgerrit | wanghao proposed openstack/mogan master: Using assertFalse/True(A) instead of assertEqual(False/True, A) https://review.openstack.org/477265 | 01:43 |
*** liusheng has joined #openstack-mogan | 02:24 | |
liusheng | wanghao_: pong, sorry just restarted my system | 02:30 |
zhenguo | liusheng: hi, please remember to update the etherpad | 02:48 |
liusheng | zhenguo: ok | 02:49 |
zhenguo | liusheng: to help wangao collect the report | 02:49 |
liusheng | zhenguo: really appreciate wanghao to do that | 02:49 |
zhenguo | liusheng: sure | 02:50 |
liusheng | zhenguo: are you in the meeting ? :D | 02:50 |
zhenguo | liusheng: yes | 02:50 |
zhenguo | liusheng: hah | 02:50 |
liusheng | zhenguo: I am just want to refactor our scheduler, maybe a big change, wdyt ? | 02:50 |
liusheng | zhenguo: lol | 02:50 |
zhenguo | liusheng: yes, | 02:50 |
zhenguo | liusheng: wrt the placement patch, how about just make one for reporting | 02:51 |
zhenguo | liusheng: which can be get reviewed and we can land it when it's ready | 02:51 |
liusheng | zhenguo: yes, sure, will split them to serveral patches | 02:51 |
zhenguo | liusheng: ok, thanks, we can quickly move to placement | 02:52 |
zhenguo | liusheng: maybe by this week, lol | 02:52 |
liusheng | zhenguo: may I will push two basic PoC patches firstly to verify the whole function | 02:52 |
liusheng | zhenguo: yes, maybe | 02:52 |
zhenguo | liusheng: sure | 02:52 |
zhenguo | liusheng: but the reporting patch can be land first | 02:53 |
liusheng | zhenguo: yes | 02:53 |
zhenguo | liusheng: I will help to review that, and maybe also update the patch | 02:53 |
liusheng | zhenguo: yes, please go ahead to update if you want to do any change :D | 02:54 |
zhenguo | liusheng: hah, maybe after the splitting, hah | 02:55 |
liusheng | zhenguo: ye | 02:55 |
wanghao_ | zhenguo: liusheng, hi | 03:06 |
liusheng | wanghao_: hi | 03:06 |
wanghao_ | liusheng: I want to talk your comment in mange spec. | 03:07 |
wanghao_ | liusheng: that I get that may impact 'rebuild' operation if we didn't specify network info in API. | 03:07 |
wanghao_ | liusheng: but I didn't get the security risk you said. | 03:08 |
wanghao_ | liusheng: could you explain it more? | 03:08 |
liusheng | wanghao_: just my guess, I thought may before we adopting a baremetal server, the server may have itself networks, and after we adopt it, we can attach a tenant network interfaces, so the server may have the possbility that have the acess to tenant network and another unknown netowrk | 03:10 |
liusheng | zhenguo, wanghao_ do you think if this situation have any risk | 03:11 |
wanghao_ | liusheng: I think it's possible, but not sure have any rish, even we specify network_info in API, it still could be, since bm server could didn't change it network connection. | 03:13 |
wanghao_ | liusheng: Just create a vitrual network in Neutron to map the physical network. | 03:13 |
wanghao_ | liusheng: that will not change the physical connection that existing before managing it. | 03:14 |
zhenguo | liusheng, wanghao: yes, instead of an empty field of server network info, we may better to let operators map the existing physical networks to neutron. | 03:14 |
*** litao__ has joined #openstack-mogan | 03:15 | |
wanghao_ | so operators should map the network before invoking managing api in mogan. But if he didn't do it, we still can let user call mogan api to manage it, but just this server could be 'rebuilded' or 'attach a new interface' I think. | 03:17 |
wanghao_ | since this server will not have any network info field. | 03:18 |
liusheng | zhenguo, wanghao_ just talked with zhaobo, we think in this situation, the server mahbe the acesses both a tenant networ and another network(uncontrolled by openstack), if we have other servers in the tanent networ, it may have the risk that other servers may also can acecess the unknow network, unless, administrator know and can acess the risk. | 03:20 |
openstackgerrit | Tao Li proposed openstack/mogan master: Fix the stunk in *ing in powering servers. https://review.openstack.org/476862 | 03:21 |
zhenguo | yes, we don't want to let users aware a server is adopted or create after it land to mogan | 03:21 |
liusheng | wanghao_: you mean also create a provider network of the network the server created ? | 03:21 |
zhenguo | so maybe only let servers with network in neutron can be managed? | 03:22 |
zhenguo | we can make the process simple now | 03:22 |
zhenguo | if we really want to adopt a server, the operators should fully prepared before that | 03:22 |
liusheng | zhenguo: yes, if so, that will have no risk | 03:22 |
zhenguo | as for bareemtals the servers physical networks can be easily get into mogan, right? | 03:23 |
zhenguo | oh, we may need to get the vlanid | 03:23 |
liusheng | hah | 03:23 |
wanghao_ | liusheng: yes | 03:24 |
zhenguo | on first step. we can make the requirements for manageable servers strict | 03:24 |
wanghao_ | yes, we need a check list to operators. | 03:25 |
zhenguo | yes, operators should do more things, then for mogan, the process can be easier | 03:25 |
wanghao_ | zhenguo: So, we didn't support the empty network info in API? | 03:25 |
zhenguo | wanghao_: yes, I think so | 03:25 |
zhenguo | wanghao_: if there's really customers requirments, we can do it later | 03:26 |
liusheng | so it's better to add warning notes in doc for operators of this feature | 03:26 |
wanghao_ | zhenguo: got it, will updat it. | 03:26 |
zhenguo | thanks | 03:26 |
wanghao_ | liusheng: yes, I will write it in spec too. | 03:26 |
liusheng | wanghao_: thanks | 03:26 |
wanghao_ | we don't need to figure the list out now, but at least we should do it after merging the code. | 03:27 |
zhenguo | wanghao_, liusheng: I will be in shenzhen for internal meeting in the whole week, maybe don't got enough time for reviewing, you guys can discuss more about this | 03:27 |
wanghao_ | zhenguo: sure | 03:27 |
liusheng | zhenguo: have a great trip :D | 03:27 |
zhenguo | hah, | 03:27 |
wanghao_ | zhenguo: you're already here, do you? | 03:28 |
zhenguo | and the review hour, you can prepare a list before that, thanks | 03:28 |
zhenguo | wanghao_: yes | 03:28 |
wanghao_ | zhenguo: cool | 03:28 |
wanghao_ | zhenguo: you can eat some shaguozhou | 03:28 |
liusheng | casserole porridge | 03:29 |
openstackgerrit | Zhenguo Niu proposed openstack/mogan-specs master: Track resources using Placement https://review.openstack.org/475700 | 05:34 |
liusheng | zhenguo: I found if we using placement, we don't need filters, cannot use weighters, the scheduler will be very very simple :( | 06:48 |
zhenguo | liusheng: yes | 07:00 |
zhenguo | liusheng: but they think the atomic resources just should be scheduled that simple :D | 07:00 |
liusheng | zhenguo: hah, if wo, seems I will remove most code of scheduler :D | 07:01 |
zhenguo | liusheng: sure, just leave two methods, report and query, lol | 07:01 |
liusheng | zhenguo: ... ok | 07:01 |
zhenguo | liusheng: I just thought, should placement client be under scheduler? | 07:05 |
liusheng | zhenguo: now, I put it under the scheduler | 07:05 |
zhenguo | liusheng: yes, we use placement for resource tracking, but maybe not just for scheduling? | 07:06 |
zhenguo | liusheng: I plan to add physical ports resource there as well, but not used for scheduling | 07:06 |
zhenguo | liusheng: placement is somewhere we track resources, not only for scheuling? | 07:06 |
liusheng | zhenguo: if we don't put it under scheduler, why we need a scheduler service... | 07:07 |
liusheng | zhenguo: just very very smallllll | 07:07 |
liusheng | zhenguo: hah | 07:07 |
zhenguo | liusheng: hah | 07:07 |
zhenguo | liusheng: not sure if a separated service can make scheduling faster in parallel model? | 07:08 |
liusheng | zhenguo: maybe we only need mogan-engine to call placement api, and don't need scheduler service, hah | 07:08 |
liusheng | zhenguo: but actually, our scheduler hard to support multiple worker | 07:09 |
zhenguo | liusheng: seems yes | 07:09 |
liusheng | zhenguo: and we have synchronized lock | 07:09 |
zhenguo | liusheng: yes, that's the current painpoint of our scheduler | 07:10 |
zhenguo | liusheng: if there's no lock, I don't know how to keep it work | 07:11 |
zhenguo | liusheng: many parallel requests may scheduled to one node | 07:11 |
liusheng | zhenguo: and if we switch to use placemnt, and we almost only have a resources query filter, it will be very fast, we may don't have performence burden | 07:12 |
liusheng | zhenguo: only a api call to placement api | 07:12 |
zhenguo | liusheng: I think so, maybe after moving to placement, we can just get rid of the scheuler | 07:12 |
zhenguo | liusheng: currently not, we can just focus on the placement stuff now, wdyt? | 07:13 |
liusheng | zhenguo: seems it is a part of work of switching to placement, hah | 07:13 |
zhenguo | liusheng: getting rid of scheduler? | 07:13 |
zhenguo | liusheng: we can just keep the service there | 07:13 |
liusheng | zhenguo: hah, yes | 07:14 |
zhenguo | liusheng: with the two methods | 07:14 |
liusheng | zhenguo: ok, will try | 07:14 |
zhenguo | liusheng: thanks, seems we will get there soon. | 07:14 |
liusheng | zhenguo: hah, yes | 07:14 |
liusheng | zhenguo: do you think should we use weighters now ? | 07:15 |
zhenguo | liusheng: no, for scheduling stuff, we only use one query for resource class, that's all | 07:15 |
liusheng | zhenguo: ok | 07:15 |
zhenguo | liusheng: aha, and the aggregates traits we will add later | 07:15 |
zhenguo | liusheng: that's enough for scheduling atomic resouces | 07:16 |
liusheng | zhenguo: ok, so things be come clear | 07:16 |
liusheng | zhenguo: ok | 07:16 |
zhenguo | liusheng: ok | 07:16 |
openstackgerrit | liusheng proposed openstack/mogan master: WIP: import placement service https://review.openstack.org/476325 | 07:28 |
openstackgerrit | liusheng proposed openstack/mogan master: WIP: Refactor the scheduler to use placement service https://review.openstack.org/477426 | 07:28 |
openstackgerrit | Tao Li proposed openstack/mogan master: Fix reverting the network when plug vif failed https://review.openstack.org/477440 | 08:01 |
openstackgerrit | Tao Li proposed openstack/mogan master: Fix reverting the network when plug vif failed https://review.openstack.org/477440 | 08:55 |
openstackgerrit | liusheng proposed openstack/mogan master: WIP: Refactor the scheduler to use placement service https://review.openstack.org/477426 | 09:01 |
liusheng | zhenguo: dou you think should we change the resources field in the default flavor to be "CUSTOM_SMALL" ? | 09:08 |
liusheng | zhenguo: or just convert it in code logical | 09:08 |
zhenguo | liusheng: not sure if we need to convert both resource class and flavor resources, but they should be consistent | 09:15 |
zhenguo | liusheng: as operators define the node's resource class and the flavor resources | 09:16 |
zhenguo | liusheng: CUSTOM is only a concept of placement | 09:16 |
zhenguo | liusheng: we can hide that part | 09:16 |
liusheng | zhenguo: we must convert resource class when reporting, since Mogan have the constraint | 09:16 |
liusheng | zhenguo: Mogan can only accept the name with "CUSTOM_" prefix | 09:17 |
zhenguo | liusheng: yes, so if the node's resource is small, then the flavor should be small | 09:17 |
liusheng | zhenguo: s/Mogan/Placement | 09:17 |
liusheng | zhenguo: ok, so we convert it in code | 09:17 |
zhenguo | liusheng: yes, so we need the same converting logic for both node resources class and flavor resources | 09:17 |
liusheng | zhenguo: ok | 09:18 |
zhenguo | liusheng: maybe we should change the current flavor name from 'small' to 'pretend' | 09:19 |
liusheng | zhenguo: why this word ? | 09:20 |
zhenguo | liusheng: to indicate that the vm is a pretend baremetal, lol | 09:22 |
liusheng | zhenguo: hah | 09:23 |
zhenguo | liusheng: aha, sorry not name, it's the resoruce class | 09:23 |
liusheng | zhenguo: maybe just change the flavor name, not the resources field | 09:23 |
zhenguo | liusheng: hah, yes | 09:23 |
zhenguo | maybe we don't even expose resources/resources traits to users | 09:23 |
liusheng | zhenguo: we can do it later | 09:24 |
liusheng | zhenguo: yes | 09:24 |
liusheng | zhenguo: but not sure if we have special requirement | 09:24 |
zhenguo | liusheng: no requirements at all | 09:24 |
liusheng | zhenguo: hah | 09:25 |
*** wanghao_ has quit IRC | 09:31 | |
openstackgerrit | liusheng proposed openstack/mogan master: WIP: Refactor the scheduler to use placement service https://review.openstack.org/477426 | 09:55 |
openstackgerrit | Merged openstack/mogan master: Using assertFalse/True(A) instead of assertEqual(False/True, A) https://review.openstack.org/477265 | 10:05 |
*** liujiong has quit IRC | 10:05 | |
liusheng | zhenguo: does taskflow persistent the tasks ? | 10:10 |
liusheng | zhenguo: sorry, ignore me, my mistake :D | 10:26 |
openstackgerrit | liusheng proposed openstack/mogan master: WIP: Refactor the scheduler to use placement service https://review.openstack.org/477426 | 10:26 |
openstackgerrit | liusheng proposed openstack/mogan master: WIP: Refactor the scheduler to use placement service https://review.openstack.org/477426 | 11:19 |
openstackgerrit | liusheng proposed openstack/mogan master: WIP: Refactor the scheduler to use placement service https://review.openstack.org/477426 | 11:28 |
*** litao__ has quit IRC | 12:02 | |
*** ChanServ has quit IRC | 19:30 | |
*** ChanServ has joined #openstack-mogan | 19:35 | |
*** card.freenode.net sets mode: +o ChanServ | 19:35 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!