Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-28
20:14:43 mriedem idk anymore
20:14:59 mriedem nor is there a proposed/* branch anymore
20:15:23 efried Since it's OpenStack-wide, I'll refrain from editing that page; long as I have some understanding of what the real deal is.
20:16:00 efried Mebbe I'll mention it to dhellmann
20:16:14 mriedem bauzas and stephenfin gave a talk at the summit about bug triage
20:16:21 mriedem you can blast them with your questions
20:23:44 openstackgerrit Matt Riedemann proposed openstack/nova master: Deprecate the IronicHostManager https://review.openstack.org/521648
20:23:44 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix some incorrect option references for scheduler filters https://review.openstack.org/521645
20:26:20 openstackgerrit Merged openstack/nova master: libvirt: remove extraneous retry assignment in cleanup method https://review.openstack.org/409199
20:47:39 mriedem efried: jaypipes: maybe you guys can confirm the issue i raised in this osc-placement allocations patch https://review.openstack.org/#/c/457534/10
20:47:58 mriedem but looking at how PUT /allocations/{consumer_id} works before 1.12, we can get some weird behavior
20:48:15 openstackgerrit Jay Pipes proposed openstack/nova master: placement: add nested resource providers https://review.openstack.org/377138
20:48:16 openstackgerrit Jay Pipes proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215
20:48:17 openstackgerrit Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693
20:48:17 openstackgerrit Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807
20:48:18 openstackgerrit Jay Pipes proposed openstack/nova master: Scheduler set_inventory_for_provider does nested https://review.openstack.org/520643
20:48:18 openstackgerrit Jay Pipes proposed openstack/nova master: ProviderTree.uuid_set() https://review.openstack.org/520243
20:48:19 openstackgerrit Jay Pipes proposed openstack/nova master: SchedulerReportClient._get_providers_in_tree https://review.openstack.org/520663
20:48:20 openstackgerrit Jay Pipes proposed openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756
20:48:20 openstackgerrit Jay Pipes proposed openstack/nova master: SchedulerReportClient._get_providers_in_aggregates https://review.openstack.org/521097
20:48:21 openstackgerrit Jay Pipes proposed openstack/nova master: WIP: ComputeDriver.update_provider_tree() https://review.openstack.org/521187
20:48:21 openstackgerrit Jay Pipes proposed openstack/nova master: Scheduler[Report]Client.get_provider_tree https://review.openstack.org/521098
20:48:22 openstackgerrit Jay Pipes proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246
20:48:44 jaypipes mriedem: gonna take a break for a bit, but will look at that later.
20:49:34 melwitt mriedem: about the console TLS series, you might have you skim it to see what I mean. it's an effort to break the work into chunks. an already merged patch added a base class for a SecurityProxy. the first unmerged patch in the series lays some groundwork by adding a base class and a None auth scheme. the second patch adds a vencrypt auth scheme, and the final patch adds a RFBSecurityProxy which actually does the encryption
20:49:34 mriedem smoke'em if you got'em
20:49:51 efried mriedem ack; but sounds like it oughtta be solved in the CLI - not a bug in the placement API?
20:50:15 mriedem efried: that's what i said, i think it's a limitation in the api until 1.12 and we have to handle it in the cli
20:50:42 mriedem melwitt: well, we could just hold off on approving the first unmerged patch with the new option until people are happy with the entire series
20:50:42 melwitt mriedem: so I'm not seeing a better way to do the reno except at the end https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/websocket-proxy-to-host-security
20:50:43 efried mriedem rgr. Though "limitation" might be a bit strong.
20:50:55 melwitt mriedem: okay, that works
21:00:30 openstackgerrit Merged openstack/nova master: Enable cold migration with target host(1/2) https://review.openstack.org/408955
21:25:43 melwitt weird, yet another time when it says merge conflict and I rebase locally but there was no conflict ...
21:27:29 melwitt mriedem: should I just try the rebase button on https://review.openstack.org/#/c/498983 ? it says merge conflict but there's no conflict to resolve when I pull it down and rebase locally
21:28:35 mriedem sure
21:29:07 melwitt k, trying that now
21:29:34 openstackgerrit melanie witt proposed openstack/nova master: Save updated libvirt domain XML after swapping volume https://review.openstack.org/498983
21:44:50 penick Hey folks, we're gearing up to replace our quota by flavor (and az) patches with something we could actually upstream. At the moment (based on hazy recollection of conversations at the summit) the direction i'm heading in is to do quota by custom resource class, wherein a resource class could be a combination of AZ and Flavor. Does that sound sane?
21:45:05 mriedem mlavalle: is this the neutron port binding extension that i'd want for the live migration thingy? http://paste.openstack.org/show/627643/
21:45:21 penick Wanted to see if anyone had some input before we started working on the spec.
21:45:58 melwitt penick: I think what we discussed was leveraging the quota class facility we already have and adding the ability to tag flavors with a quota class
21:47:37 penick melwitt: ah, I also have to do quota by flavor and AZ as well. Can I make that work using quota classes too?
21:47:45 mriedem mlavalle: i'm guessing it's not, since it looks like that extension is just an indication of the binding:profile stuff on the port, i.e. https://developer.openstack.org/api-ref/network/v2/index.html#port-binding-extended-attributes
21:48:02 mlavalle mriedem: it's not
21:48:26 mlavalle that is the existing extension
21:49:00 melwitt penick: this gives a high level view of what quota classes are https://docs.openstack.org/nova/pike/user/quotas.html so it's already possible to set quota on a per class basis i.e. "openstack quota set --class myclass --instances 5"
21:49:52 melwitt it's just that currently there is no way to specify a quota class with any one request. rackspace used to do it via their own custom paste middleware, IIRC
21:51:52 penick oh ok, I didn't realize that it could be custom resource classes too, not just the typical resources like instances, ram, etc
21:52:08 mriedem not the same thing
21:52:16 melwitt as for AZ, I guess to do it that way there would need to be a way to tag an AZ with a quota class
21:52:16 mriedem resource classes are a placement concept
21:52:21 gryf quota class is different thing
21:52:21 mriedem quota classes are a nova concept
21:52:59 mriedem placement doesn't have any concept of quota
21:53:20 penick Ah, that makes sense.
21:53:21 mriedem we've talked about replacing nova's quota calculation code using the consumer allocation / resource class stuff in placement at some point, but there are issues
21:53:42 mriedem because the quota usage in nova is also tracked via allocatoins in placemetn for things like vcpu/memory_mb/disk_gb
21:54:35 melwitt yeah. a quota class is a logical grouping of quotas. like you could create a 'dev class' that has certain quota limits and you could create a different 'prod class' that has different quota limits
21:54:42 mriedem penick: you could start with a backlog spec to document the problem and use case
21:54:51 mriedem w/o getting into design or implementation details
21:55:15 mriedem note that today you can create any number of custom quota classes in nova, but the only one that the code actually gives 2 shits about is the 'default' quota class
21:55:38 mriedem ala https://review.openstack.org/#/c/411035/
21:55:42 melwitt they've proposed a spec about it in the past, it got gridlocked on the implementation details
21:55:55 mriedem they = yahoo, past = juno?
21:56:22 mriedem and was it the same guy that was doing the zookeeper spec that gridlocked for 3 years?
21:56:32 melwitt I was thinking a reasonable way to actually get it done would be to use quota classes and provide a way to tag flavor with a quota class
21:56:36 mriedem or tooz or kazoo or whatever it was
21:56:37 melwitt mriedem: yes
21:57:13 penick heh
21:57:25 mriedem welp, i'd dig up the old spec i guess because i'm not familiar with the use case / problem description
21:57:32 mriedem and i'm sure that predated anything with placement
21:57:48 mriedem *plus* no chance for queens, so you'd have to tee this up for discussion in dublin
21:58:12 melwitt mriedem: this is the old spec https://review.openstack.org/#/c/206160/
21:59:11 melwitt it was agreed to be a reasonable use case, just that all of the implementation ideas were pretty hairy
21:59:29 mriedem anything involving AZs is going to be hairy as hell
21:59:35 mriedem or quotas
21:59:44 mriedem is there some way we can work boot from volume into this?
21:59:51 penick You bet your ass we can
21:59:55 melwitt being able to tag a flavor with a quota class would get us quota by flavor at least, and the same use case has come up in the preemptable instances discussions
22:01:08 melwitt that is, for preemptable instances, you could have a quota class 'preemtable' which is unlimited quota and tag preemptable instance flavors with that class. so that users booting preemptable instances don't use up their quota when they boot them
22:02:35 mriedem mlavalle: ok so i'm looking for the "binding-extended" extension per https://review.openstack.org/#/c/484389/8/neutron_lib/api/definitions/portbindings_extended.py
22:03:12 mriedem mlavalle: i'm looking at starting to build up the nova patches for this thing, and part of that is just asking neutron if the api extension is even available to do the deed
22:05:13 mlavalle mriedem: that is the extension definition. as far as the implementation, I am working on it
22:06:02 openstackgerrit Ken'ichi Ohmichi proposed openstack/nova master: Remove unnecessary spaces on JSON samples https://review.openstack.org/523543
22:06:24 penick So If I want to limit tenant $foo to 10 instances of flavor $bar, and I want to limit tenant $baz to 20 instances of flavor bar, i'd create 2 quota classes, one for tenant $foo, one for tenant $baz, then tag flavor $bar with both quota classes?
22:09:39 penick is that how the flow would go? Assuming I could tag a flavor with the quota class
22:09:42 melwitt penick: hm, no. what I was saying would only work to have 1 set of quotas for a flavor if every tenant gets the same quotas for that flavor
22:09:52 penick oh, crud
22:10:42 melwitt basically, you'd need a quota class per unique set of quota limits
22:11:14 melwitt I would think to a large extent many tenants would be able to use the same class?
22:12:23 penick i'm checking the DB on one of our prod clusters right now..
22:12:41 mriedem if we ever get limits information from keystone, doesn't that kind of throw a wrench into all of this?
22:12:50 melwitt what I mean is, you would only need one class per tenant/flavor if they were all literally different
22:12:51 mriedem because that's the eventual replacement for quota classes in nova
22:13:53 melwitt it would throw a wrench if we won't have quota classes in keystone
22:16:10 penick Ok, so i'll need to assume one class per tenant and flavor
22:16:25 melwitt hang on, let me look at this again real quick.
22:16:34 penick mriedem are limits definitely moving to keystone? Because i've heard talk about that for a year or two..and nothing's happened.
22:16:57 dansmith well, people keep getting laid off

Earlier   Later