| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-13 | |||
| 20:01:14 | artom | mikal_, hrmm, that's actually a good question - how does the host know what instance a request came from over vsock? | |
| 20:02:18 | mikal_ | artom: its not one vsock per instance? | |
| 20:02:32 | artom | mikal, it is, but... | |
| 20:02:46 | artom | This is where what little knowledge I have of this thing breaks down | |
| 20:02:49 | mikal | So nova knows when it sets the vsock the instance its going to wire it into... | |
| 20:03:18 | artom | But if there's only one service listening on the host side, even if there's one vsock per guest... | |
| 20:04:03 | artom | Presumably they speak TCP over that vsock, so unless every instance has its own "vsock IP" that nova knows about... | |
| 20:04:28 | artom | If berrange was here he'd probably laugh at my ignorance :/ | |
| 20:09:38 | dansmith | vsock works like AF_INET or AF_UNIX | |
| 20:09:42 | dansmith | it's a socket protocol | |
| 20:09:44 | dansmith | so no TCP or IP | |
| 20:09:59 | dansmith | it's 1:1 and uses strings as the addressing on either end | |
| 20:10:35 | dansmith | so it wouldn't "taste like normal networking" in that sense.. cloud-init would have to open an AF_VSOCK socket to some known port name and then try to speak HTTP over it or something, | |
| 20:10:55 | dansmith | which something on the host could proxy to the regular metadata API, or just emulate the metadata server | |
| 20:11:05 | dansmith | mikal: artom ^ | |
| 20:11:52 | artom | dansmith, heh, dunno if that was off the top of your head or you did the research, but thanks regardless :) | |
| 20:12:29 | cfriesen | artom: https://wiki.qemu.org/Features/VirtioVsock | |
| 20:15:04 | dansmith | artom: I had to refresh my memory on the port bit, but yeah, the rest is pretty straightforward | |
| 20:15:14 | dansmith | it's been discussed a couple times at least | |
| 20:15:16 | mikal | dansmith: it doesn't feel hard to get changes into cloud-init, but it would take a long time to propogate | |
| 20:15:34 | dansmith | mikal: yep, and we kinda have to do it first | |
| 20:15:53 | dansmith | mikal: I think it'd just be one of those "use it if it's there" sort of things anyway, so it wouldn't be too bad | |
| 20:15:59 | mikal | I've had a long term dream of getting something a bit like AWS IAMS into nova, but I don't think this is it on reflection | |
| 20:16:12 | mikal | dansmith: yeah, part of the discovery process at boot | |
| 20:16:13 | dansmith | but someone would have to write up both sides and think through a bunch of it | |
| 20:16:30 | mikal | IAMS is more like a transparent http proxy embedded into neutron | |
| 20:16:57 | mikal | So what is the advantage of vsock over the current ways? It would need to be large to be bothered making the change. | |
| 20:17:14 | dansmith | it has no addressing, and requires no networking | |
| 20:17:22 | dansmith | it's an agent transport basically, | |
| 20:17:31 | dansmith | but done in a generic POSIX-compatible way | |
| 20:18:57 | artom | Security is a big advantage, I'd htink | |
| 20:19:18 | artom | You're not sending potentially sensitive metadata over potentially unsecure proxies | |
| 20:19:19 | dansmith | I don't know | |
| 20:19:37 | artom | In a potentially sniffable by other guests way | |
| 20:19:39 | dansmith | it feels more secure but I don't think it's substantially so | |
| 20:19:50 | dansmith | no, I don't think this is less sniffable | |
| 20:20:10 | dansmith | less prone to bugs which might leak sniffability, maybe :) | |
| 20:21:25 | mikal | And instances need networking to be useful, so I guess we're talking about a before-networking-configured case here | |
| 20:21:40 | mikal | The benefits still feel marginal compared to the amount of mucking around to get them | |
| 20:21:51 | dansmith | well, this came up mostly because you need to know some things to plumb yourself for certain types of networking | |
| 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 | oh heh there are two options with the same name | |
| 21:11:13 | mriedem | nice | |
| 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 check if neutron "binding-extended" extension is available https://review.openstack.org/523548 | |
| 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:46 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add VIFMigrateData object for live migration https://review.openstack.org/515423 | |
| 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:47 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Port binding based on events during live migration https://review.openstack.org/434870 | |
| 21:16:47 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add "delete_port_binding" network API method https://review.openstack.org/552170 | |
| 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: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: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. | |