*** wanghao has joined #openstack-mogan | 00:28 | |
wanghao | zhenguo: ping | 01:04 |
---|---|---|
wanghao | zhenguo: I saw your review in managing existing, | 01:04 |
wanghao | ports [ | 01:04 |
wanghao | { | 01:04 |
wanghao | "uuid": xx, | 01:04 |
wanghao | "address": xx, | 01:04 |
wanghao | "port_id": xx # which is extracted from extra or internal_info in ironic driver. | 01:04 |
wanghao | } | 01:04 |
wanghao | 01:04 | |
wanghao | zhenguo: there port_id means neutron's port id, right? | 01:04 |
wanghao | zhenguo: and I also think we should add mac address too. | 01:05 |
wanghao | zhenguo: sorry, mac address has been here. | 01:05 |
*** wanghao_ has joined #openstack-mogan | 01:06 | |
*** wanghao has quit IRC | 01:10 | |
*** litao__ has joined #openstack-mogan | 01:20 | |
zhenguo | wanghao: yes, address is mac and port_id is neutron port | 01:36 |
zhenguo | wanghao: as different driver may save neutron port in different way, so we need to make the API object more generic | 01:37 |
*** openstackgerrit has joined #openstack-mogan | 01:47 | |
openstackgerrit | Merged openstack/python-moganclient master: Add commands for aggregate node actions https://review.openstack.org/492370 | 01:47 |
openstackgerrit | Zhenguo Niu proposed openstack/mogan-specs master: Add server group support https://review.openstack.org/489541 | 01:56 |
openstackgerrit | Tao Li proposed openstack/mogan master: Manage existing BMs: Part-2 https://review.openstack.org/481544 | 01:57 |
zhenguo | liusheng: please remember to move ironic_states import out from engine | 01:57 |
liusheng | zhenguo: ok, will do it, I am testing the server_group + scheduler_hings :D | 01:58 |
zhenguo | liusheng: ok | 01:58 |
liusheng | zhenguo: seems I made a mistak for the aggregate node commands: "baremetalcompute aggregate list node", it will conflict with "baremetalcompute aggregate list", sorry :( | 02:02 |
liusheng | zhenguo: maybe "baremetalcompute aggregate node <ACTIONK>" | 02:03 |
zhenguo | liusheng: you can add a following up patch to address that | 02:03 |
liusheng | zhenguo: ok | 02:03 |
zhenguo | liusheng: seems nova doesn't have such commands | 02:05 |
zhenguo | liusheng: should we add nodes to aggregate object | 02:05 |
liusheng | zhenguo: hmm, maybe it is similar with Xinran's problem | 02:06 |
zhenguo | liusheng: yes | 02:06 |
zhenguo | liusheng: do we have other similar problems | 02:06 |
liusheng | zhenguo: maybe aggregate list node command, we can intergrated to aggregate object, but add/remove node for an aggregate cannot | 02:07 |
zhenguo | liusheng: yes | 02:07 |
liusheng | zhenguo: so that may need to be done in API side firstly | 02:08 |
zhenguo | liusheng: it's ok to keep add/remove aggregate nodes/ flavor access in separated controller | 02:08 |
liusheng | zhenguo: yes | 02:08 |
zhenguo | liusheng: ok, I will try later | 02:09 |
liusheng | zhenguo: how about just change the commands firstly for now ? | 02:09 |
zhenguo | liusheng: you mean just get rid of that command | 02:09 |
zhenguo | liusheng: aggregate list node | 02:09 |
liusheng | zhenguo: no I mean switch the lacation of "node" and "ACTION" in the 3 node aggregeate commands | 02:09 |
liusheng | baremetalcompute_aggregate_node_add = moganclient.osc.v1.aggregate:AggregateAddNode | 02:10 |
zhenguo | liusheng: seems we don't need to change that | 02:10 |
liusheng | baremetalcompute_aggregate_node_list = moganclient.osc.v1.aggregate:AggregateListNode | 02:10 |
liusheng | baremetalcompute_aggregate_node_remove = moganclient.osc.v1.aggregate:AggregateRemoveNode | 02:10 |
zhenguo | liusheng: just follow nova's way | 02:10 |
zhenguo | liusheng: ACTION node | 02:10 |
liusheng | zhenguo: ok, let me check how Nova does | 02:10 |
liusheng | zhenguo: en, yes | 02:11 |
liusheng | zhenguo: let's keep it | 02:11 |
*** wanghao_ has quit IRC | 02:11 | |
openstackgerrit | liusheng proposed openstack/mogan master: Add support for scheduler_hints https://review.openstack.org/463534 | 02:24 |
openstackgerrit | liusheng proposed openstack/mogan master: WIP: Use server group in scheduler https://review.openstack.org/496151 | 02:24 |
openstackgerrit | liusheng proposed openstack/mogan master: Use server group in scheduler https://review.openstack.org/496151 | 02:24 |
openstackgerrit | Zhenguo Niu proposed openstack/mogan-specs master: Add server group support https://review.openstack.org/489541 | 02:26 |
openstackgerrit | liusheng proposed openstack/mogan master: Use server group in scheduler https://review.openstack.org/496151 | 02:29 |
openstackgerrit | Tao Li proposed openstack/mogan master: Rollback to the original status when server powering action failed https://review.openstack.org/476862 | 02:38 |
*** wanghao has joined #openstack-mogan | 02:53 | |
litao__ | zhenguo: I found the managing servers spec is updated, we needn't pass port id in API,So we needn't check the network? | 03:01 |
*** wanghao has quit IRC | 03:08 | |
zhenguo | litao__: we don't pass all information through API, but you can get the manageable server object, which includes everything you want | 03:08 |
*** wanghao has joined #openstack-mogan | 03:10 | |
wanghao | zhenguo: sure | 03:10 |
wanghao | zhenguo: do you think neutron_port_id is more better | 03:10 |
zhenguo | litao__, wanghao: maybe we just need to pass name, description, metadata | 03:10 |
zhenguo | wanghao: yes | 03:10 |
litao__ | zhenguo, wanghao : so I should call the ironic api to get the network information? | 03:11 |
zhenguo | litao__: no, you don't need to call ironic | 03:11 |
litao__ | zhenguo: If you don't pass network, how can i get it? | 03:12 |
zhenguo | litao__: y ou need to fetch the manageable server object via wanghao's API | 03:12 |
zhenguo | litao__: manage API is just verity informations like port_id, then create a server db record, that's all | 03:12 |
zhenguo | although it's not that smart for now, but it works at least | 03:13 |
litao__ | zhenguo: you mean , I should call wanghao's get API in managing server APi ? | 03:13 |
zhenguo | litao__: oh, not API, but internal API | 03:14 |
wanghao | zhenguo: reuse my process to get manageable nodes information. | 03:14 |
zhenguo | yes | 03:14 |
litao__ | zhenguo: I get | 03:14 |
litao__ | zhenguo: also pass the available_zone | 03:17 |
zhenguo | litao__: our availablility_zone is used for scheduling, not sure how to handle that | 03:17 |
zhenguo | litao__: but seems cinder can support that, and get manageable volumes will include availabiilty_zone information | 03:18 |
zhenguo | liusheng: seems manageable servers will also go to placement, right? | 03:19 |
zhenguo | liusheng: how can we handle that | 03:19 |
litao__ | zhenguo: Yes, we can check the resource of the bare metal node through placement | 03:19 |
zhenguo | litao__: if such nodes can go to placement, it maybe scheduled :( | 03:20 |
liusheng | zhenguo: yes, it should be managed by placement | 03:20 |
zhenguo | liusheng: so it can be scheduled? | 03:21 |
liusheng | zhenguo: that seems has a problem | 03:22 |
liusheng | zhenguo: :( | 03:22 |
zhenguo | liusheng: need to refactor the placement part before Pike | 03:23 |
zhenguo | liusheng: maybe not avaialble nodes, should go to placement with an allocations | 03:24 |
zhenguo | liusheng: but nos sure who allocated it | 03:24 |
*** wanghao has quit IRC | 03:24 | |
liusheng | zhenguo: not sure the "reserved" field in inventory can be used in this situation | 03:24 |
zhenguo | liusheng: we can try | 03:25 |
*** wanghao has joined #openstack-mogan | 03:25 | |
litao__ | I think we can treat bare metal server active without instance_uuid as unallocated resources | 03:26 |
zhenguo | litao__: yes, but we need to find a way to set in placement | 03:27 |
zhenguo | litao__: currently only allocations there can archieve this | 03:27 |
zhenguo | litao__: maybe inventories.reserved can also help with this | 03:27 |
zhenguo | liusheng: not only for active nodes, all unavailble states should be set reserved 1 there | 03:28 |
zhenguo | liusheng:and remove reserved when it turns avaialble | 03:28 |
liusheng | zhenguo: not sure if reserved is designed for that | 03:29 |
zhenguo | liusheng: reserved is desined for vm host reserved cpu, mem | 03:29 |
liusheng | zhenguo: oh, yes, I remember it | 03:29 |
zhenguo | liusheng: but for us, we only got 1 resource_class there, so we can reserve it as we want | 03:30 |
liusheng | zhenguo: so it is also can used in our situation :) | 03:30 |
zhenguo | liusheng: yes | 03:30 |
liusheng | zhenguo: sounds a good idea | 03:30 |
zhenguo | liusheng: hah, that's also address my concerns like we talked | 03:30 |
liusheng | zhenguo: hah, seems yes | 03:31 |
zhenguo | litao__, liusheng, wanghao: so, seems manageable servers can also return availability zone information if it added to the aggregate | 03:32 |
zhenguo | litao__: but seems we don't need to specify az in API | 03:32 |
liusheng | zhenguo: you mean the manageable server already with az info ? | 03:32 |
zhenguo | litao__: if the manageable server contains az, you can add it to server db record | 03:32 |
zhenguo | liusheng: as the node can be added in aggregates with az | 03:33 |
zhenguo | liusheng: we just make it not be abled to scheduled | 03:33 |
zhenguo | liusheng: but our node list, and aggregates node add can also do that | 03:33 |
liusheng | zhenguo: oh, does that will conflict with your aggregate metadata check ? | 03:33 |
zhenguo | liusheng: seems not | 03:34 |
liusheng | zhenguo: cool | 03:34 |
zhenguo | liusheng: that check will only care about node in different aggregate, regardless of it's managteable or deployed by mogan | 03:34 |
liusheng | zhenguo: oh, yes, | 03:35 |
zhenguo | liusheng, litao__: but we may need a following up patch for managing servers | 03:35 |
zhenguo | litao__, wanghao: for now, we don't need to handle az | 03:35 |
litao__ | zhenguo: So you mean we shouldn't pass az in managing server API? | 03:36 |
zhenguo | litao__: yes | 03:36 |
zhenguo | litao__: we desined to pass az for scheduling, | 03:36 |
litao__ | zhenguo: just name , description, metadata and node_uuid can pass> | 03:37 |
litao__ | zhenguo: ? | 03:37 |
zhenguo | litao__: I think so | 03:37 |
openstackgerrit | liusheng proposed openstack/mogan master: Get rid of Ironic state in engine manager layer https://review.openstack.org/497724 | 03:37 |
litao__ | zhenguo: OK | 03:39 |
zhenguo | litao__: will try to land wanghao's patch by today | 03:39 |
litao__ | zhenguo: great, so I can rebase it | 03:40 |
zhenguo | litao__: yes, hah | 03:40 |
openstackgerrit | liusheng proposed openstack/mogan master: Add affinity_zone field for server object https://review.openstack.org/495725 | 03:54 |
*** wanghao has quit IRC | 04:04 | |
*** wanghao has joined #openstack-mogan | 04:08 | |
*** wanghao has quit IRC | 04:31 | |
*** wanghao has joined #openstack-mogan | 04:32 | |
openstackgerrit | wanghao proposed openstack/mogan master: Manage existing BMs: Part-1 https://review.openstack.org/479660 | 05:52 |
openstackgerrit | wanghao proposed openstack/mogan master: Add some missing logs in Mogan https://review.openstack.org/492917 | 06:04 |
litao__ | wanghao: If i get your internal method, should you add a get_one method? | 06:09 |
openstackgerrit | liusheng proposed openstack/mogan master: Add support for scheduler_hints https://review.openstack.org/463534 | 06:10 |
openstackgerrit | liusheng proposed openstack/mogan master: Use server group in scheduler https://review.openstack.org/496151 | 06:10 |
openstackgerrit | liusheng proposed openstack/mogan master: Get rid of Ironic state in engine manager layer https://review.openstack.org/497724 | 06:12 |
wanghao | litao__: I think it's no need, you just need to choose what you want from the list. | 06:13 |
wanghao | litao__: need to expose the get_one to user. | 06:13 |
wanghao | need/no need | 06:14 |
litao__ | wanghao: The manage API passed only the node_uuid, so you mean I get all the node list and get the one by the node_uuid? | 06:18 |
wanghao | litao__: yes | 06:19 |
litao__ | wanghao: Maybe a little low efficiency | 06:20 |
litao__ | wanghao: But it works | 06:20 |
wanghao | litao__: since get_one is useless for getting managebale servers, if I support get_one, it's not different you call the ironic api. | 06:20 |
litao__ | wanghao: Ok | 06:21 |
wanghao | litao__: besides, considering we may can support multi-manage at once, so I think it's better you just use the get_all api. | 06:21 |
litao__ | wanghao: yeah | 06:22 |
litao__ | zhenguo If we don't pass flavor, so is it necessary to check resource class? | 06:26 |
zhenguo | litao__: seems not | 06:27 |
litao__ | zhenguo: ok | 06:27 |
zhenguo | litao__: I'm considering whether we need to expose resource_class through server | 06:28 |
zhenguo | liusheng, wanghao: do you think we should add resource_class to server object to expose it to users? | 06:28 |
zhenguo | oh, seems we dont's how it with flavor to common users | 06:29 |
zhenguo | s/how/show | 06:29 |
liusheng | zhenguo: hah, yes | 06:29 |
wanghao | zhenguo: I think it's no harm to expose it to users. | 06:30 |
wanghao | zhenguo: it could be a tag-like thing to servers. | 06:31 |
zhenguo | seems yes, but maybe we can think more, and do it after managing server landed | 06:31 |
liusheng | flavor is also something like tag for end users | 06:32 |
wanghao | zhenguo: yeah | 06:32 |
litao__ | Maybe we can add tags for server later | 06:32 |
litao__ | rather than flavor | 06:33 |
zhenguo | sure, tags should be supported | 06:33 |
litao__ | if the flavor is not used currently, we don't expose it to users firstly | 06:33 |
zhenguo | litao__: you can check whether it's allowed to be null in server object | 06:34 |
liusheng | for users, they may don't have an accurate concept of the size of server, but a fuzzy concept of the class of server, e.g. gold, silver | 06:35 |
litao__ | zhenguo: yes, it is nullable in server object | 06:36 |
* litao__ zhenguo: the get_manageable_servers | 06:36 | |
* litao__ zhenguo: The flavor_uuid | 06:37 | |
zhenguo | litao__: if so, it's ok | 06:37 |
wanghao | tags is an attributes from mogan side, but resource_class is from underlay side. | 06:38 |
zhenguo | liusheng: maybe we should try to add cpu/mem/disks information with the server, lol | 06:38 |
liusheng | zhenguo: ... we disscussed to avoid expose that info. :P | 06:39 |
zhenguo | liusheng: we don't have a way to expose that | 06:39 |
liusheng | zhenguo: you mean add that in server than flavor ? | 06:40 |
zhenguo | only a flavor uuid with the server, seems not userful to users | 06:40 |
wanghao | zhenguo: I suggest we find a way to expose those information to users. | 06:40 |
zhenguo | not sure, maybe add some human readble information, e,g flavor description? | 06:40 |
zhenguo | wanghao: yes, seems users care about that | 06:41 |
wanghao | zhenguo: or hardware description | 06:41 |
zhenguo | wanghao: yes | 06:41 |
liusheng | zhenguo: I think may we can add another unchangeable field in flavor, and desription for other usage | 06:41 |
wanghao | zhenguo: yes, since Mogan focuse on "baremetal", we can add some hardware information in server. | 06:42 |
wanghao | liusheng: maybe not in flavor | 06:42 |
liusheng | wanghao: so all things in server ? | 06:42 |
wanghao | liusheng: no, a new fieid in server | 06:43 |
zhenguo | when you get a server, I think that's the basic informations users want to know | 06:43 |
wanghao | liusheng: zhenguo, like 'hardware' in server object | 06:43 |
litao__ | Yes, maybe we should add a new filed | 06:43 |
zhenguo | yes | 06:44 |
zhenguo | if driver can provide such properties, we can get that from the server associated node | 06:44 |
liusheng | wanghao, zhenguo litao__ maybe at most cases, users don't want that info, how about add that info in flavor, when sometimes users want that info, they can query flavor and server and merge the flavor info and server info ? | 06:46 |
liusheng | and mostly, users may face their server by dashboard, dashboard plugin can assemble info from several APIs | 06:47 |
zhenguo | liusheng: not sure it's convenient, but if I'm a user, I only care about that informations, lol; | 06:47 |
liusheng | zhenguo: yes, but usually, users may don't direcly use the Mogan API | 06:48 |
zhenguo | liusheng: doesn't it better if we can save a API call? | 06:48 |
zhenguo | liusheng: and maybe the informaition can be different from flavor | 06:48 |
liusheng | zhenguo: no, I mean in many situations, uses may don't need that info, so maybe this way si more save. hah | 06:49 |
zhenguo | liusheng: why users don't need that info? | 06:49 |
liusheng | zhenguo: users don't need to care that | 06:49 |
zhenguo | liusheng: why | 06:49 |
liusheng | zhenguo: why users need ? | 06:50 |
zhenguo | liusheng: if you buy a server, you don't are about the hardware specifications? | 06:50 |
zhenguo | *care | 06:51 |
liusheng | zhenguo: no, I thinks as we desinged, usually, users may don't need that accurate hardware info. and in a few cases, users may need to know that | 06:51 |
zhenguo | liusheng: not sure.. | 06:52 |
liusheng | just personal thoughts | 06:53 |
litao__ | Currently, users can't get hardware information from mogan API | 06:53 |
litao__ | do they? | 06:54 |
zhenguo | also can't get from flavor, as flavor description maybe not hardware info | 06:54 |
liusheng | litao__: yes, that is useful, what I think is may we'd better to avoid return many info when query servers, but we can provide the way to query total info according to users real needs | 06:55 |
zhenguo | hah, but personally, I think hardware specifications is more important than everything returned with the flavor, lol | 06:56 |
liusheng | lol | 06:56 |
litao__ | zhenguo: Yes, I think this is another issue, we could discuss it later | 06:56 |
zhenguo | hah, we can continue to discuss this later, let's try to focus on Pike release | 06:57 |
zhenguo | it's Friday, let's try to land more things this week | 06:58 |
litao__ | Currently, whether expose resource class doesn't matter me, i don't care it | 06:58 |
wanghao | +1, this could be discuss more in next meeting for queens. | 06:59 |
liusheng | seems need doc patch for server managing | 06:59 |
wanghao | zhenguo: liusheng: I have updated the managing patch and miss log patch, plz have a look | 07:00 |
liusheng | wanghao: ok, will review | 07:00 |
zhenguo | I think wanghao's patch is almost good, will test it later, please have a look, liusheng | 07:00 |
zhenguo | wanghao: ok | 07:00 |
zhenguo | I mean the managing servers patch ! | 07:00 |
zhenguo | lol | 07:00 |
zhenguo | liusheng, wanghao^^ | 07:00 |
liusheng | zhenguo: yes, so I will believe your test, hah | 07:00 |
zhenguo | hah | 07:00 |
litao__ | wanghao: The get_manageable_servers should expose image uuid | 07:01 |
wanghao | I did | 07:01 |
wanghao | image_source | 07:01 |
litao__ | wanghao: ok | 07:02 |
wanghao | thanks | 07:02 |
*** Xinran has quit IRC | 07:03 | |
liusheng | zhenguo: btw, server group +scheduler_hints patches are ready for review: https://review.openstack.org/#/c/496151/ | 07:04 |
liusheng | zhenguo: :) | 07:04 |
*** Xinran has joined #openstack-mogan | 07:04 | |
zhenguo | liusheng: cool | 07:05 |
liusheng | zhenguo: I have tested several cases in my env, but my devstack only have 3 nodes, and I tried to install another env failed. maybe need more nodes to test another cases. | 07:06 |
zhenguo | liusheng: you can test with hardware env | 07:07 |
liusheng | zhenguo: hah, how many nodes available in our hardware env ? | 07:07 |
zhenguo | liusheng: I don't know, lol | 07:07 |
zhenguo | liusheng: but only two now, I remember seems more than 10? | 07:07 |
liusheng | zhenguo: seems only 2 | 07:07 |
zhenguo | liusheng: what the others, they got it back? | 07:08 |
liusheng | zhenguo: no, seems we have 7 nodes | 07:09 |
liusheng | zhenguo: need to added | 07:09 |
zhenguo | liusheng: we can add all, then do some tests in the next few days before Pike | 07:09 |
liusheng | zhenguo: ok | 07:09 |
zhenguo | liusheng: seems moganclient still use server update --add-extra for metadata, need to change to use properties? | 07:14 |
liusheng | zhenguo: yes, I will update my patch | 07:15 |
zhenguo | liusheng: ok | 07:15 |
openstackgerrit | wanghao proposed openstack/mogan-specs master: No need flavor and network in managing server https://review.openstack.org/494980 | 07:18 |
zhenguo | liusheng: I like the is_node_consumable method here https://review.openstack.org/#/c/497724/ , please remember to consider to leverage inventory 'reserved' to make consumable more accurate later | 07:21 |
liusheng | zhenguo: hah, OK, will try | 07:31 |
zhenguo | liusheng: thanks | 07:31 |
liusheng | zhenguo: np | 07:31 |
litao__ | liusheng: If then, It is not necessary to schedule the node to placement when managing servers, right? | 07:36 |
liusheng | litao__: yes, we should avoid scheduler to select the manageable server for server creating | 07:38 |
zhenguo | liusheng, litao__: so, if we mange the servers, and create a mogan server, do we need to create an allocation? | 07:40 |
liusheng | zhenguo, litao__ for the managed server, we can also delete the server to relase the node, right ? | 07:42 |
zhenguo | liusheng: yes | 07:42 |
liusheng | zhenguo: so I think we'd better to create an allocation | 07:43 |
zhenguo | liusheng: ok | 07:44 |
litao__ | liusheng: But create an allocation now is in scheduler | 07:45 |
liusheng | litao__: hmm, yes, so maybe we need to add that in create manageable server process | 07:46 |
zhenguo | liusheng, Xinran: after a second think, maybe we should keep flavor accesses/ aggregate nodes list in the seperated controller | 07:48 |
zhenguo | liusheng, Xinran: for aggregate nodes, the list can be very large | 07:48 |
liusheng | zhenguo: seems yes | 07:49 |
zhenguo | liusheng, Xiran: maybe better to just keep this list method there | 07:49 |
liusheng | zhenguo: that is a problem, sigh :( | 07:50 |
litao__ | liusheng: maybe we can use scheduler process using uuid parameter | 07:50 |
zhenguo | Xinran: if you haven't started to work on that, please just abandon the patch, sorry :( | 07:50 |
zhenguo | liusheng: let's just keep that, and focus on other things, not much time left | 07:51 |
liusheng | litao__: seems that is only a placement call, it is very simple, cannot add that to your process ? | 07:52 |
liusheng | zhenguo: yes, sure | 07:54 |
litao__ | liusheng: of course i can | 07:57 |
litao__ | liusheng: I just wan to keep it from scheduler, If not care, I will add it | 07:59 |
liusheng | litao__: maybe it is bit more complex to call scheduler, currently our process is unrelated with scheduler, right ? | 08:00 |
litao__ | liusheng: But the process has been implement in scheduler, add a new one is duplicated. | 08:03 |
litao__ | liusheng: The 'put_allocations' method | 08:04 |
liusheng | litao__: you don't need to implement the method again, just call the method of mogan.scheduler.client.report.SchedulerReportClient#put_allocations, just like how we call the method in report.py in resource updating task | 08:06 |
litao__ | liusheng: OK | 08:06 |
zhenguo | wanghao: on my test, there are still some problems with the listing manageable servers patch, but after some hacks, it works, please see my comments :D | 08:40 |
zhenguo | liusheng, litao__: please also help to look at it, if no other objections, we can land it by today | 08:41 |
litao__ | zhenguo: ok | 08:42 |
liusheng | zhenguo: ok | 08:42 |
* zhenguo brb | 08:44 | |
zhenguo | liusheng: please help to go though all the up patches, then I will call shaohe_feng to make good-to-go ones landed. | 08:58 |
liusheng | zhenguo: ok | 08:58 |
liusheng | zhenguo: still around ? | 09:14 |
zhenguo | liusheng: yes | 09:14 |
liusheng | zhenguo: for you patch: https://review.openstack.org/#/c/495826 | 09:14 |
liusheng | zhenguo: seems there is problem, we store the network name in server object | 09:14 |
liusheng | zhenguo: but the network name can be update | 09:14 |
zhenguo | liusheng: oh, not sure how nova handle that | 09:15 |
zhenguo | liusheng: they also save it | 09:15 |
liusheng | zhenguo: maybe Nova query from neutron and then combine it into server body, just guess | 09:15 |
zhenguo | liusheng: it also save it in to db | 09:16 |
zhenguo | liusheng: do you have a env to test? | 09:16 |
zhenguo | liusheng: or somebody else | 09:16 |
liusheng | zhenguo: just asked, Nova query the network name from info_cache, and info_cache can be synced with neutron | 09:17 |
zhenguo | liusheng: oh, when does that sync happen? | 09:18 |
liusheng | zhenguo: when neutron update network, it will sent a notification, and Nova will update its info_cache | 09:18 |
zhenguo | liusheng: we also need to catch that notification? | 09:18 |
liusheng | zhenguo: that seems a bit complex :( | 09:19 |
zhenguo | liusheng: yes | 09:19 |
zhenguo | liusheng: info cache is also in db? | 09:20 |
liusheng | zhenguo: yes | 09:23 |
zhenguo | liusheng: does nova only send notifications to nova, or we can also catch it | 09:24 |
liusheng | zhenguo: not sure, seems it depens on how nova consume the notification message, there is a "requeue" parameter when consume a notification message | 09:25 |
liusheng | zhenguo: seems neutron only consider Nova as the notification consumer :( | 09:26 |
zhenguo | liusheng: sigh | 09:27 |
wanghao | zhenguo: sure | 09:33 |
wanghao | zhenguo: I will fix it tonight | 09:35 |
zhenguo | liusheng: or we jsut use nework id? | 09:35 |
zhenguo | wanghao: thanks | 09:35 |
zhenguo | wanghao: liusheng and I will still in office tomorrow :D | 09:36 |
liusheng | zhenguo: hah | 09:36 |
liusheng | zhenguo: small weekend | 09:36 |
wanghao | zhenguo: liusheng: I see, hahahahah | 09:36 |
zhenguo | liusheng: but I didn't get the email | 09:36 |
wanghao | almost fogot it. | 09:37 |
zhenguo | lol | 09:37 |
liusheng | zhenguo: now the company policy it reducing the group sending emails, hah | 09:37 |
zhenguo | liusheng: but how can I know which is samll weekend | 09:38 |
zhenguo | liusheng: I don't know ,lol | 09:38 |
liusheng | zhenguo: usually, last weekend of a month | 09:38 |
zhenguo | liusheng: I may assume next week is the last week... | 09:38 |
liusheng | zhenguo: hah | 09:39 |
openstackgerrit | Merged openstack/mogan master: Add some missing logs in Mogan https://review.openstack.org/492917 | 09:39 |
*** wanghao has quit IRC | 09:40 | |
openstackgerrit | Merged openstack/mogan master: Updated from global requirements https://review.openstack.org/497039 | 09:40 |
openstackgerrit | Zhenguo Niu proposed openstack/mogan master: Leverage _detach_interface for destroying networks https://review.openstack.org/496569 | 09:48 |
zhenguo | liusheng: do you have suggestions for the addresses patch? | 09:49 |
liusheng | zhenguo: maybe use network id is trade-off | 09:50 |
zhenguo | liusheng: yes, on the dashbaord it can get the network name | 09:51 |
liusheng | zhenguo: yes | 09:52 |
zhenguo | liusheng: ok | 09:52 |
openstackgerrit | liusheng proposed openstack/python-moganclient master: Unify the commands for server updating https://review.openstack.org/497815 | 09:59 |
liusheng | zhenguo: just submitted a patch to change the "server update" command ^ | 10:01 |
zhenguo | liusheng: thanks | 10:01 |
zhenguo | liusheng: I'd like to call it a day and head home, bye! | 10:02 |
*** openstackgerrit has quit IRC | 10:02 | |
* zhenguo away | 10:03 | |
liusheng | zhenguo: hah, bye | 10:03 |
*** wanghao has joined #openstack-mogan | 10:56 | |
*** wanghao has quit IRC | 11:11 | |
*** wanghao has joined #openstack-mogan | 11:17 | |
*** liusheng has quit IRC | 11:41 | |
*** ChanServ has quit IRC | 11:41 | |
*** RuiChen has quit IRC | 11:41 | |
*** wanghao has quit IRC | 11:41 | |
*** luyao has quit IRC | 11:41 | |
*** litao__ has quit IRC | 11:41 | |
*** lin_yang has quit IRC | 11:41 | |
*** Jeffrey4l has quit IRC | 11:41 | |
*** dims has quit IRC | 11:41 | |
*** zhangyang has quit IRC | 11:41 | |
*** zhenguo has quit IRC | 11:41 | |
*** zhuli has quit IRC | 11:41 | |
*** harlowja has quit IRC | 11:41 | |
*** kong has quit IRC | 11:41 | |
*** Kevin_Zheng has quit IRC | 11:41 | |
*** Xinran has quit IRC | 11:41 | |
*** wxy has quit IRC | 11:41 | |
*** shaohe_feng has quit IRC | 11:41 | |
*** openstack has joined #openstack-mogan | 12:59 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!