| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-08 | |||
| 13:47:03 | ktibi | stephenfin sean-k-mooney I guess we have two solutions : 1/ disable by default this features 2/ change the detection which inscrease the trigger by detect only fail or error which does not concern quota or free IP | |
| 13:48:01 | stephenfin | ktibi: IMO, you'd be better waiting for dansmith and/or mriedem to pop up in an hour or two. I don't think you're the first person to have issues with this | |
| 13:48:12 | ktibi | because for now, I can disable all compute on a fresh install !! with a simple user. Create a network with 20 IP and spawn 90 instances ! | |
| 13:50:50 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: libvirt: Provide VGPU inventory for a single GPU type https://review.openstack.org/514763 | |
| 13:50:50 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: libvirt: create vGPU for instance https://review.openstack.org/528832 | |
| 13:50:51 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: libvirt : Force a specificly static UUID for a mediated device https://review.openstack.org/531752 | |
| 13:53:59 | hrw | stephenfin: hello ;) | |
| 13:56:36 | efried | Scheduler meeting in 4 minutes in #openstack-meeting-alt | |
| 13:57:15 | bauzas | damn, needs coffee then | |
| 14:55:46 | openstackgerrit | Merged openstack/nova master: Add index on token_hash and instance_uuid for console_auth_tokens https://review.openstack.org/531477 | |
| 15:01:13 | efried | cdent Yes, if update_provider_tree comes back with a provider removed, that means report client needs to delete that provider. | |
| 15:01:29 | cdent | efried, jaypipes it would be great if we could do some of this discussion in email, so the results end up somewhere digestible. but if that's no good, we can carry on here (I'm in cafe land again, so don't want to hang out, now, but could another time) | |
| 15:02:42 | cdent | doesn't it mean instead that it is not used in this context? If we're including sharing providers in the ProviderTree, is there weirdness? I don't know, it's hard to think about in the abstract, and without whiteboards etc | |
| 15:03:23 | mriedem | yikun: https://review.openstack.org/#/c/531633/ looks ok once some nits are addressed and you can squash it into https://review.openstack.org/#/c/330406/ | |
| 15:04:46 | efried | cdent Yeah, that's a place we'll have to tread carefully. If a virt decides it's no longer going to be associated with a sharing provider, it should remove itself from that aggregate... but should it also remove that provider? | |
| 15:05:03 | jaypipes | efried: if the provider is gone, then yeah. | |
| 15:05:23 | jaypipes | efried: but if the virt driver doesn't *own* that provider, then no. | |
| 15:05:33 | jaypipes | efried: I think this is highly dependent on the virt driver. | |
| 15:05:35 | efried | jaypipes What does "own" mean? | |
| 15:05:57 | jaypipes | efried: in the case of vCenter and PowerVM, the virt driver "owns" these shared pools of resources, right? so the virt driver can delete them. | |
| 15:05:59 | openstackgerrit | Jackie Truong proposed openstack/nova master: Add trusted_certs object https://review.openstack.org/489408 | |
| 15:06:25 | efried | jaypipes But how does the driver know it's the last one associated with the sharing provider? | |
| 15:06:26 | jaypipes | efried: but for libvirt, it doesn't own any sharing providers. something else does and therefore it shouldn't delete sharing providers. | |
| 15:06:37 | jaypipes | efried: that's up to you, baby. | |
| 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 | |