| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-08 | |||
| 15:06:38 | openstackgerrit | Jackie Truong proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204 | |
| 15:06:50 | efried | jaypipes Without talking to placement... | |
| 15:07:02 | jaypipes | efried: powervm and vcenter, being virt drivers for clustered resource nodes, are going to have to handle that on their own. | |
| 15:07:17 | jaypipes | efried: zookeeper maybe? I don't know :) | |
| 15:07:45 | cdent | of just talk to the local third party agent which is talking to placement anyway, even though nova want "let" them | |
| 15:07:52 | cdent | s/want/won't/ | |
| 15:08:22 | mriedem | vcenter is no longer a clustered thing right? and powervm never was | |
| 15:08:34 | mriedem | ironic is our only 1:M virt driver | |
| 15:08:35 | efried | mriedem Clustered shared storage pool | |
| 15:08:39 | mriedem | oh | |
| 15:08:51 | efried | The quintessential shared provider case. | |
| 15:09:18 | mriedem | how would that not also affect libvirt? | |
| 15:09:18 | openstackgerrit | Claudiu Belu proposed openstack/nova master: hyper-v: autospec classes before they are instantiated https://review.openstack.org/342211 | |
| 15:09:26 | mriedem | if you're using NFS or Ceph for local disk/ | |
| 15:09:27 | mriedem | ? | |
| 15:10:29 | efried | mriedem I think because those guys are going to manage the shared provider from some other control point. | |
| 15:10:44 | cdent | mriedem: indeed. the assumption has been that "something else" is managing in that context, but I'm not sure we've really thought it all the way through | |
| 15:10:46 | efried | mriedem PowerVM (and apparently vCenter) are planning to manage the shared provider from virt. | |
| 15:12:57 | mriedem | oh | |
| 15:13:11 | mriedem | why do we care about shared storage providers right now? | |
| 15:13:21 | mriedem | because of some design point being discussed in queens? | |
| 15:13:55 | efried | mriedem Good question. | |
| 15:15:09 | efried | We've had some shared provider code in the codebase for a couple of releases, so we've been dragging it along and keeping it "working" as we've been tackling NRP et al. | |
| 15:15:45 | efried | But if we're looking for opportunities to limit scope, we did agree not to implement/declare shared provider support in Q. | |
| 15:16:22 | cdent | I think it is coming up because it was a nodal point in the discussion about whether virt drivers can or should be able to talk to placement themselves | |
| 15:16:48 | mriedem | we don't need to intentionally make something not work in the future, but for places where we expect we'll need to change things later for shared providers to work, we should just leave TODOs - dansmith did some of that with the migration allocation swap series | |
| 15:16:50 | efried | cdent Agree. But the question remains: do we need to solve this in Q? | |
| 15:17:28 | cdent | I don't think we _have_ to, no | |
| 15:17:52 | cdent | But it often feels kike we push off design discussion too often | |
| 15:17:56 | mriedem | edleafe: on https://review.openstack.org/#/c/531405/ - i pulled that down and made these changes http://paste.openstack.org/show/640953/ - if you don't think those are terrible, i could push those up | |
| 15:18:30 | mriedem | maybe CastAsCall isn't something we really want to use since it masks real api behavior that the user would see | |
| 15:18:58 | mriedem | cdent: we also have a tendency to over design and not get anything done | |
| 15:19:22 | cdent | efried: I need to change locations. I hope we can continue touching on this over time, but agree in the short term that shared providers is not something we're going to finish this cycle | |
| 15:19:37 | mriedem | s/finish/even spend time on/ | |
| 15:19:39 | efried | cdent Buzz me when you get back on, want to continue discussion. | |
| 15:19:40 | cdent | mriedem: can you say that while simultaneously affirming that we merge more code than any other openstack project :) | |
| 15:20:10 | cdent | efried: will do | |
| 15:20:35 | mriedem | i don't know how much code we merge relative to other projects | |
| 15:21:17 | efried | Perpetual challenge to strike the right balance. I don't think it's a systemic problem in either direction; just needs to be managed on a case-by-case. | |
| 15:23:37 | mriedem | i'm just commenting from the sidelines as i haven't been involved in coding or reviewing the NRP series, | |
| 15:24:04 | mriedem | i'm just concerned that we're spending a lot of time designing the end thing right now and we'll miss the boat on getting anything functional in queens | |
| 15:24:49 | efried | mriedem Well, we've already landed a *lot* of functional stuff in queens. And I think we're on track to get the rest done. (That was specifically brought up and agreed in the sched meeting.) | |
| 15:25:04 | mriedem | i'm going to try and wrap up the series of changes i've been pushing/reviewing for the last few weeks to get done this week b/c i'm out next week | |
| 15:26:06 | mriedem | bauzas: are you back to help review stuff this week? | |
| 15:30:45 | lyarwood | mdbooth: https://review.openstack.org/#/c/531233/ - FYI the bugfix from before the break | |
| 15:31:19 | mdbooth | lyarwood: Yes | |
| 15:32:00 | mdbooth | lyarwood: IIRC I preferred to attach/detach encryptors in attach/detach volume? | |
| 15:32:15 | mdbooth | Because those 2 things should always happen together | |
| 15:33:45 | lyarwood | mdbooth: yeah I think the issue with that was wiring the request context into yet more places | |
| 15:34:10 | mdbooth | lyarwood: Well lets wire away, because the alternative is a trickle of bugs | |
| 15:34:16 | mdbooth | It's probably not that many | |
| 15:35:16 | mdbooth | Hmm, I thought I had some notes on this. | |
| 15:35:34 | mdbooth | lyarwood: I literally just finished what I was doing earlier. Let me grab a coffee and look hard at this again. | |
| 15:35:49 | lyarwood | mdbooth: kk, the refactor is the patch below this btw | |
| 15:37:08 | mriedem | dansmith: want to hit this backport again? https://review.openstack.org/#/c/530982/ | |
| 15:37:28 | dansmith | you know I do | |
| 15:37:54 | hrw | mriedem: hello | |
| 15:38:04 | hrw | mriedem: https://review.openstack.org/#/c/530965/ got +1 from Zuul ;) | |
| 15:39:11 | mriedem | +2 again | |
| 15:41:30 | hrw | thanks mriedem | |
| 15:41:39 | hrw | stephenfin: your turn then ;D | |
| 15:43:37 | stephenfin | hrw: and +W here | |
| 15:43:59 | stephenfin | Cheers for the quick follow-ups on that, hrw | |
| 15:44:02 | hrw | stephenfin: ;) | |
| 15:44:47 | hrw | stephenfin: like I said yesterday - it help keeping reviewers attention ;D | |
| 15:47:28 | openstackgerrit | Merged openstack/nova master: Optionalize instance_uuid in console_auth_token_get_valid() https://review.openstack.org/481700 | |
| 15:47:36 | openstackgerrit | Merged openstack/nova master: Add ConsoleAuthToken object https://review.openstack.org/320063 | |
| 15:55:40 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add regression test for resize failing during retries https://review.openstack.org/531405 | |
| 15:55:40 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix race condition in retrying migrations https://review.openstack.org/531022 | |
| 15:55:41 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Change compute RPC to use alternates for resize https://review.openstack.org/526436 | |
| 15:55:42 | mriedem | edleafe: addressed my nits in the regression test patch, and fixed my -1 in the regression bug fix patch in the middle, rebased the series to master also ^ | |
| 15:56:38 | matrohon | mriedem: hi | |
| 15:56:47 | openstackgerrit | Stephen Finucane proposed openstack/nova master: fixup! console: introduce the VeNCrypt RFB authentication scheme https://review.openstack.org/531833 | |
| 15:56:47 | openstackgerrit | Stephen Finucane proposed openstack/nova master: console: Send bytes to sockets https://review.openstack.org/531834 | |
| 15:57:14 | stephenfin | Oops | |
| 15:58:04 | mdbooth | Hehe | |
| 15:58:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: console: introduce framework for RFB authentication https://review.openstack.org/345397 | |
| 15:58:26 | openstackgerrit | Stephen Finucane proposed openstack/nova master: console: introduce the VeNCrypt RFB authentication scheme https://review.openstack.org/345398 | |
| 15:58:26 | openstackgerrit | Stephen Finucane proposed openstack/nova master: console: Provide an RFB security proxy implementation https://review.openstack.org/345399 | |
| 15:58:27 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Document TLS security setup for noVNC proxy https://review.openstack.org/500544 | |
| 15:58:27 | openstackgerrit | Stephen Finucane proposed openstack/nova master: console: Send bytes to sockets https://review.openstack.org/531834 | |
| 15:58:31 | mriedem | matrohon: hi | |
| 15:58:51 | mriedem | dansmith: i'm +2 on edleafe's fix for the cold migration + reschedule regression (and the test patch below it) https://review.openstack.org/#/c/531022/ | |
| 15:59:42 | matrohon | mriedem: I was trying to boot a VM without an IP, but I can't find a way to do so | |
| 16:00:01 | mriedem | matrohon: use at least microversion 2.37 to create the server and pass networks='none' | |
| 16:00:32 | mriedem | see the 'networks' parameter here https://developer.openstack.org/api-ref/compute/#create-server | |
| 16:01:05 | matrohon | mriedem: great! I reported a related bug, but I'll try it the way you mention | |
| 16:01:41 | matrohon | mriedem: However, I'm not sur my bug is pointless : https://bugs.launchpad.net/nova/+bug/1741575 | |
| 16:01:42 | openstack | Launchpad bug 1741575 in OpenStack Compute (nova) "creating a VM without IP (ip_allocation=None)" [Undecided,New] | |
| 16:02:05 | mriedem | matrohon: yeah https://bugs.launchpad.net/nova/+bug/1741575 is something else | |
| 16:02:52 | mdbooth | lyarwood: Ah, yes | |
| 16:03:18 | mdbooth | lyarwood: So, we call _connect_volume in _get_guest_xml, which is pretty unambigously a bug | |
| 16:03:32 | mdbooth | But it's a bug we rely on in a couple of places | |
| 16:03:54 | mdbooth | I have some notes I made before the break about how to unwind that | |
| 16:05:06 | mdbooth | Apart from that, we'd need context in swap_volume | |
| 16:05:07 | matrohon | mriedem: I briefly discussed with carl_baldwin a long time ago, how told me he didn't finished the job on the nova side. At least, he didn't submit anything related to the case where "ip_allocation=none". | |
| 16:05:22 | lyarwood | mdbooth: for the bugfix I'm now providing that | |
| 16:05:23 | mdbooth | lyarwood: Which... we do anyway. Doesn't look like we're handling encryptors there. | |
| 16:05:47 | mdbooth | _create_domain_setup_lxc() | |
| 16:06:45 | mdbooth | lyarwood: pre_live_migration() ? | |