| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-13 | |||
| 20:21:56 | dansmith | chicken and egg like | |
| 20:22:14 | mikal | configdrive! | |
| 20:22:23 | dansmith | yeah, but you can't update that at runtime | |
| 20:22:29 | mikal | (Which cracks me up because configdrive was meant to be long dead by now) | |
| 20:22:30 | dansmith | which is why we landed here :) | |
| 20:22:55 | mikal | So for these network types, you need to have attached the _first_ interface before the config drive is generated? | |
| 20:23:03 | mikal | But the later ones you could use metadata server for? | |
| 20:23:42 | dansmith | if you boot with two SRIOV nics and you need to know which one is public, and you can't get to metadata over them (yet), then you could use configdrive, | |
| 20:23:46 | dansmith | but then if you attach something else later, | |
| 20:24:03 | dansmith | you'd need to know that even though at boot there was no metadata server, now there is and you should use that instead | |
| 20:24:10 | dansmith | it's doable of course | |
| 20:26:23 | openstackgerrit | Ed Leafe proposed openstack/nova master: Add 'member_of' param to GET /allocation_candidates https://review.openstack.org/552098 | |
| 21:07:11 | cfriesen | just noticed something odd...the docs at https://docs.openstack.org/nova/pike/configuration/config.html specify that ram_weight_multiplier/disk_weight_multiplier/etc are under DEFAULT, but that generates a warning log since they're actually under "filter_scheduler" as far as I can tell. | |
| 21:07:42 | tssurya | dansmith : do we still plan to keep this NewtonCellsCheck Test in Rocky ? -> https://github.com/openstack/nova/blob/master/nova/tests/unit/db/test_sqlalchemy_migration.py#L356 ; since it uses a particularly older DBVersion it fails for my new DB version; not sure how to handle it because it is wrong to just update it to the new version I guess. | |
| 21:09:57 | mriedem | cfriesen: https://docs.openstack.org/nova/latest/configuration/config.html says the are under the [cells] section | |
| 21:11:13 | mriedem | nice | |
| 21:11:13 | mriedem | oh heh there are two options with the same name | |
| 21:12:39 | mriedem | cfriesen: it says it's in the [filter_scheduler] group https://docs.openstack.org/nova/latest/configuration/config.html#filter-scheduler | |
| 21:12:54 | mriedem | the 'group' you're looking at is the 'Deprecated Variations¶' | |
| 21:13:05 | mriedem | b/c deprecated_group="DEFAULT", | |
| 21:13:25 | mriedem | we can probably start cleaning up all of those aliases | |
| 21:13:28 | mriedem | they were made in 2016 | |
| 21:16:45 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add code to bind a port against a dest host during live migration https://review.openstack.org/523604 | |
| 21:16:45 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add check if neutron "binding-extended" extension is available https://review.openstack.org/523548 | |
| 21:16:46 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: libvirt: use dest host vif migrate details for live migration https://review.openstack.org/551370 | |
| 21:16:46 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add VIFMigrateData object for live migration https://review.openstack.org/515423 | |
| 21:16:47 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add "delete_port_binding" network API method https://review.openstack.org/552170 | |
| 21:16:47 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Port binding based on events during live migration https://review.openstack.org/434870 | |
| 21:16:48 | openstackgerrit | Matt Riedemann proposed openstack/nova master: conductor: use port binding extended API in during live migrate https://review.openstack.org/522537 | |
| 21:16:48 | openstackgerrit | Matt Riedemann proposed openstack/nova master: compute: use port binding extended API during live migration https://review.openstack.org/551371 | |
| 21:16:49 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Turn on new port binding extended live migrate flow https://review.openstack.org/552173 | |
| 21:20:56 | cfriesen | mriedem: yeah, I got messed up by the deprecated variations bit. my bad | |
| 21:28:46 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Make nova-cells-v1 run with neutron https://review.openstack.org/549789 | |
| 21:43:41 | openstackgerrit | Dan Smith proposed openstack/nova master: [WIP] Add --by-service to discover_hosts https://review.openstack.org/552691 | |
| 21:44:38 | openstackgerrit | Merged openstack/nova master: conf: Fix indentation of database options https://review.openstack.org/443097 | |
| 21:44:48 | openstackgerrit | Merged openstack/nova master: Re-work the metadata service docs https://review.openstack.org/550250 | |
| 23:56:37 | mriedem | so uh, getting the cells v1 job to pass with neutron was actually pretty damn easy https://review.openstack.org/#/c/549789/ | |
| #openstack-nova - 2018-03-14 | |||
| 00:09:34 | cburgess | mriedem overachiever, I take it you all are finally removing nova-network from the tree? | |
| 00:35:46 | Spaz-Home | Morning | |
| 00:58:24 | artom | Spaz-Home, you have a weird schedule ;) | |
| 01:03:30 | mnaser | is os_vif under nova or neutron's world | |
| 01:03:43 | mnaser | https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L266-L268 -- im trying to understand why the unplug under linux is noop for ovs | |
| 01:03:44 | jichen | mriedem: hi do you know where to find the etherpad that discussed in PTG to put patches of previously approved spec so that it can get more review and help? I want to put https://review.openstack.org/#/q/topic:bp/add-zvm-driver-rocky+(status:open+OR+status:merged) into it. thanks | |
| 01:09:07 | Kevin_Zheng | mriedem Hi, saw you guys discussing about the quota thing, any conclusion? | |
| 01:26:43 | openstackgerrit | Artom Lifshitz proposed openstack/nova-specs master: Live migration with CPU pinning https://review.openstack.org/552722 | |
| 02:11:21 | jianghuaw_ | jichen, is this what you're looking for? https://etherpad.openstack.org/p/rocky-nova-priorities-tracking | |
| 02:12:16 | Spaz-Home | lol indeed artom , Night shift, so I work Asia hours :p | |
| 02:14:04 | artom | Spaz-Home, ah! I did night shift in a previous life, working support for a web host. It was... interesting | |
| 02:14:43 | Spaz-Home | That it is.. i've been doing it for about 10 years.. It can be extremely unhealthy, Just in the paste 2 years or so i've started to prioritize my health in the situation. | |
| 02:14:56 | Spaz-Home | But also.. I get to bother jianghuaw_ all night, which is probably the best benefit :P | |
| 02:15:15 | jianghuaw_ | Spaz-Home, good morning:-) | |
| 02:15:31 | Spaz-Home | Welcome home, sir. | |
| 02:15:35 | artom | I only did it for a few months, it definitely messed with me, I can't imagine doing it for years. We're not cats. | |
| 02:15:47 | jichen | jianghuaw_: thanks, I missed line 98 in the etherpad... :) | |
| 02:16:04 | Spaz-Home | Hehe yes sir.. I've honestly seem people's minds go a little crazy .. some people just are not made for that transition. | |
| 02:16:08 | jianghuaw_ | jichen, np:-) | |
| 02:18:32 | jianghuaw_ | Spaz-Home, thanks. Good job on https://review.openstack.org/#/c/538415/ :-) | |
| 02:18:39 | Spaz-Home | Hey jianghuaw_ before I lose ya, Dan is asking for a Xen Subteam member to attend Nova Meeting this week for https://blueprints.launchpad.net/nova/+spec/live-migration-in-xapi-pool | |
| 02:18:45 | Spaz-Home | Haha thanks sir, made me happy | |
| 02:19:31 | jianghuaw_ | Spaz-Home, yes. Naichuan or myself will attend this week's meeting. | |
| 02:19:43 | jianghuaw_ | Hope will get that BP be approved. | |
| 02:19:47 | Spaz-Home | Sounds good. I'd also like to discuss that with you a bit today or tomorrow if you have the time | |
| 02:19:54 | Spaz-Home | I do thin kthey plan to approve | |
| 02:20:08 | jianghuaw_ | Yes, we had some discussion in the PTG. | |
| 02:20:52 | jianghuaw_ | Spaz-Home, so what do you want to to chat on that topic? | |
| 02:21:20 | Spaz-Home | Well I understand the reason for the patch and it's basically just moving away from aggregates into the more refined pools, so I cannot speak anythign bad about the patch itself as it's the same situation but a different method | |
| 02:21:31 | Spaz-Home | However I still dislike that we're forcing an optional feature into the xenapi drives for LM to work | |
| 02:22:20 | jianghuaw_ | LM? | |
| 02:22:27 | Spaz-Home | My apologies, Live Migration | |
| 02:23:09 | Spaz-Home | I guess the best example would be my own environment we work in, We do not use Aggregates or Pooling, and just allow VMs to migrate around within the same Cell | |
| 02:23:39 | Spaz-Home | Since Networks are assigned through the cell and inventory is similar.. My thought however is how common that swetup would be rather than using pooling or aggregates. | |
| 02:23:50 | jianghuaw_ | Yes, the original plan for this feature is to support XAPI pool which is the direction which we think is better than the aggregation pool. | |
| 02:23:51 | openstackgerrit | Merged openstack/nova master: Reparent placement objects to oslo_versionedobjects https://review.openstack.org/551529 | |
| 02:24:04 | Spaz-Home | I can certainly agree on that point | |
| 02:24:46 | jianghuaw_ | But later we noticed the existing aggregation pool is broken when introducing cells. | |
| 02:26:11 | Spaz-Home | Hrm. | |
| 02:27:25 | jianghuaw_ | I guess the use case you mentioned should be still supported. | |
| 02:27:47 | Spaz-Home | Well, as of right now it's definately not since it will fail pulling the aggregate, and I think it will now as well trying to pull a pool master. | |
| 02:28:00 | jianghuaw_ | As you're not using pool or aggregation, so ML should still work. | |
| 02:30:21 | Spaz-Home | yeah I don't think it will work looking at the new is_same_pool_host | |
| 02:30:29 | Spaz-Home | IT's going to look for that dest in the pool and fail just like the aggregation check does. | |
| 02:30:49 | Spaz-Home | I'll need to fire up a host to confirm that, but should throw an error | |
| 02:31:59 | Spaz-Home | I guess in the end I had two thoughts. If (when we make this final change to change the checks themselves) we could check if the pool is empty AND if CONF [cells]->Enable=True to figure out if a destination is acceptable | |
| 02:32:38 | Spaz-Home | Or if you guys do decide to jsut rely on pools, I would like to submit a followup patch to increase parity with block-migration. Right now block-migration is very much not aligned, as this is how we currently live migrate to avoid the aggregation check. | |
| 02:33:08 | Spaz-Home | That way things remain even and clean. We could use that opportunity to always run the assert_will_migrate and ensure that block-migration checks for the pool st atus as well. | |
| 02:34:40 | jianghuaw_ | Spaz-Home, https://git.openstack.org/cgit/openstack/nova/tree/nova/virt/xenapi/vmops.py#n2322 | |
| 02:34:49 | jianghuaw_ | I think it should go to this branch. | |
| 02:35:14 | jianghuaw_ | It's not able to use shared SR to speed-up live-migration. | |
| 02:36:15 | jianghuaw_ | If want to use shared SR, surely must add hosts into the same pool. | |
| 02:38:14 | jianghuaw_ | Spaz-Home, also please note we will have a follow-up patch to remove the this upcall - _ensure_host_in_aggregate. | |
| 02:38:22 | Spaz-Home | Yeah got ya | |
| 02:39:13 | Spaz-Home | It's wierd that we're using block_migration like that.. but I actually hadn't looked at this line before | |
| 02:39:33 | Spaz-Home | Sicne block_migration is intended purely for iscsi stuff.. it's itneresting that we're using it to reroute the code lol | |
| 02:41:01 | Spaz-Home | Ok.. with that line I am fine with this then sir | |
| 02:41:06 | jianghuaw_ | Indeed. I agree. At sometime we should refactor this part to make it more reasonable. | |
| 02:41:25 | Spaz-Home | I think we need to just refactor the process overall.. I was thinking in a month or so just getting a whiteboard and seeing what I can do and send you pictures lol | |
| 02:41:32 | Spaz-Home | But a project for another time | |
| 02:42:36 | jianghuaw_ | Great. yes. just ping me if you have any thoughts at any time. | |
| 02:42:52 | jianghuaw_ | I'm happy that you're interested at it. | |
| 02:42:55 | jianghuaw_ | :-) | |