Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-04
16:09:34 cdent because if we are using allocations for usage, is a cold node supposed to count against my quota? that's not my (the user's) fault and I want to run some instances
16:09:45 cdent s/usage/quota measurment/
16:09:48 dansmith cdent: it should IMHO yeah
16:10:01 dansmith cdent: you're free to delete the instance and get the quota back
16:10:05 dansmith the flip side is,
16:10:13 dansmith if a compute node goes down, you get more quota and boot a thing,
16:10:31 dansmith when the compute node comes back, should the provider be free to nuke the instance that was running on that node since you'd now be over quota?
16:10:33 cdent hmmm. yeah. weird.
16:10:41 cdent blech
16:10:51 mriedem i think when i get some time i'll write a functional test for the local delete /allocations bug
16:11:44 mriedem back to spec review
16:19:51 openstackgerrit Artom Lifshitz proposed openstack/nova-specs master: SPICE native client support https://review.openstack.org/442040
16:22:55 openstackgerrit Balazs Gibizer proposed openstack/nova-specs master: Show persisted scheduler hints in server details https://review.openstack.org/440580
16:25:29 gibi mriedem, sdague, cdent, jaypipes, johnthetubaguy: hi! I updated the spec https://review.openstack.org/#/c/440580
16:26:08 gibi mriedem, sdague, cdent, jaypipes, johnthetubaguy: I tried to answer all the concerns comments
16:26:20 jaypipes gibi: thx Balasz!
16:26:41 cdent gibi++
16:28:24 mriedem mgagne: thanks for this https://review.openstack.org/#/c/337819/
16:28:36 mriedem mgagne: not many people take the time to update spec docs after the fact
16:29:09 mgagne mriedem: hmm, didn't get notification for that one, checking
16:29:11 johnthetubaguy cdent: you are right about limiting the crust at ingress, I think that was the question for me, should we do that first.
16:30:06 johnthetubaguy mriedem: ++ on the thank you and your comments there, it came up the other day in a bug I think
16:31:04 mgagne cool, glad to see it got merged =)
17:03:19 openstackgerrit Lee Yarwood proposed openstack/nova master: encryptors: Always default to the NoOpEncrytor https://review.openstack.org/453265
17:26:36 mriedem melwitt: on https://review.openstack.org/#/c/453041/ i know it's just a re-proposal, but most of what that spec is talking about is the old justification for doing it, i.e. rpc versioning and the like. the reason you're re-proposing it is a bit different, for cells v2. i'd like to see something in there about why this is something we want for cells v2 - what cells v2 problem does it solve, etc?
17:27:01 openstackgerrit Lee Yarwood proposed openstack/nova-specs master: Libvirt: Native LUKS file and host device decryption by QEMU https://review.openstack.org/437070
17:27:17 melwitt mriedem: okay. so add that and remove Previously-approved?
17:27:53 openstackgerrit Mathieu Gagné proposed openstack/nova-specs master: Nova support for attached volume extend https://review.openstack.org/453272
17:28:06 mriedem melwitt: previously-approved is fine
17:28:15 mriedem i'm just looking for something about cells v2 in the problem description
17:28:15 melwitt k
17:28:24 openstackgerrit Mathieu Gagné proposed openstack/nova-specs master: Nova support for attached volume extend https://review.openstack.org/453272
17:28:33 mriedem maybe that's L53... "Because the new tokens will go in the database we need to consider
17:28:34 mriedem cells v2."
17:29:19 mriedem melwitt: so maybe that paragraph answers it
17:29:25 mriedem the url contains the instance uuid
17:29:36 mriedem weren't we going to use that to lookup which cell the token was in?
17:32:11 melwitt yeah, I'm trying to see if that change happened already yet (looking at the old merged vs abandoned patches)
17:33:25 melwitt okay, so that change didn't make it https://review.openstack.org/#/c/325382/
17:37:05 mriedem do we have to worry about old connection urls that don't have the instance uuid so we can't do the lookup for the cell?
17:39:57 openstackgerrit Gábor Antal proposed openstack/nova master: Transform instance.volume_attach notification https://review.openstack.org/401992
17:44:48 melwitt mriedem: so it looks like the idea during the transition period is to have both the consoleauth service running and have new tokens stored in cell databases. so old connection urls will be served by the consoleauth service, which has the tokens globally in memcached
17:44:48 openstackgerrit Gábor Antal proposed openstack/nova master: Transform instance.volume_attach notification https://review.openstack.org/401992
17:47:51 openstackgerrit Gábor Antal proposed openstack/nova master: Transform instance.volume_attach notification https://review.openstack.org/401992
17:49:56 melwitt mriedem: and then I think through normal token expiration, eventually all of the old memcached tokens won't be used anymore, and when that happens it would be safe to stop running the consoleauth service since no outstanding connection urls will be without the server uuid
17:52:26 macsz bugs team meeting (#openstack-meeting-4) in 10 minutes, if anyone is interested
18:00:40 openstackgerrit Dan Peschman proposed openstack/nova master: Add uuid to Service model https://review.openstack.org/453025
18:05:10 mriedem melwitt: ok is that all in the spec? i didn't read the whole thing b/c i'm lazy
18:05:47 mriedem ah reading your reply
18:06:08 oomichi gmann: thanks, LGTM now
18:07:44 melwitt mriedem: it is, but it's not as detailed as my comment. I sort of derived it from looking at the abandoned patches plus the spec, since I'm not so familiar with consoles. the spec language appears to assume more knowledge
18:07:59 mriedem yeah same here
18:09:01 mriedem you need a phd like paul murray
18:09:08 mriedem anyway, approved
18:09:30 melwitt heh, yeah
18:09:34 melwitt cool, thanks!
18:10:11 openstackgerrit Mathieu Gagné proposed openstack/nova-specs master: Nova support for attached volume extend https://review.openstack.org/453272
18:29:53 openstackgerrit Artom Lifshitz proposed openstack/nova-specs master: SPICE native client support https://review.openstack.org/442040
18:41:29 mriedem cfriesen: in https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/instance-flavor-api.html how are we representing a flavor that doesn't have any extra specs? are you omitting it from the response, or returning an empty list, or None?
18:43:26 openstackgerrit melanie witt proposed openstack/nova-specs master: Add project/user association to placement https://review.openstack.org/453030
18:45:49 mriedem looks like it will be {}
18:45:51 mriedem per the api sample
19:07:01 mriedem melwitt: ever noticed that for project_id and user_id in the nova data model we allow 255?
19:07:07 mriedem but keystone only allows 64
19:09:11 melwitt mriedem: no, I didn't know we allow 255
19:11:04 mriedem ok questions in https://review.openstack.org/#/c/453030/
19:13:02 melwitt cool, thanks
19:20:48 openstackgerrit Eric Fried proposed openstack/nova master: WIP: PowerVM Driver: config drive https://review.openstack.org/409404
19:29:23 openstackgerrit Eric Fried proposed openstack/nova master: PowerVM Driver: SSP emphemeral disk support https://review.openstack.org/443189
19:32:02 mriedem f yeah down to just 1.5 pages of open spec reviews
20:00:49 mriedem sdague: this is an easy one to go through https://review.openstack.org/#/c/384261/ - if you agree with my comments, i can update it quick
20:01:24 sdague mriedem: after the TC meeting I'll try to look
20:01:35 mriedem ack
20:23:01 openstackgerrit melanie witt proposed openstack/nova-specs master: Add project/user association to placement https://review.openstack.org/453030
20:23:42 openstackgerrit John Garbutt proposed openstack/nova-specs master: Add additional-default-policy-roles spec https://review.openstack.org/427872
21:07:53 mriedem random filter question,
21:07:58 mriedem i'm sure we have something that handles this,
21:08:14 sdague mriedem: https://review.openstack.org/#/c/384261/6/specs/pike/approved/deprecate-multinic-proxy-api.rst ... yeh, I think your comments are fine there
21:08:40 mriedem but if i have a set of host aggregates with a certain storage backend that has restrictions on it, and i want my flavors tied to that, i can do it with extra specs so the flavors are tied to those host aggregates, but how to i keep other flavors that don't have the extra spec from landing on those hosts?
21:08:44 mriedem which filter does that?
21:09:13 mriedem sdague: ok i'll update it
21:09:26 mriedem sdague: although at this point in the day i suppose you're done
21:09:37 mriedem i can let alex_xu update it
21:10:23 melwitt mriedem: I thought it would be AggregateInstanceExtraSpecsFilter
21:10:47 sdague mriedem: either way, the fam is out at the store, so I have a few minutes until they get back
21:11:09 mriedem melwitt: yeah but AggregateInstanceExtraSpecsFilter returns True if the flavor doesn't have extra specs too
21:11:42 melwitt hm, I was going off the docstring "Check that the extra specs associated with the instance type match the metadata provided by aggregates. If not present return False."
21:12:22 mriedem melwitt: i think that's if the extra spec key is not in the aggregate metadata
21:12:27 mriedem if not aggregate_vals:
21:13:23 melwitt right, doesn't that mean if no match, host_passes is False? but I do see it returns True if extra_specs is entirely empty
21:14:14 mriedem yeah
21:14:28 mriedem so if the flavor has extra specs but they aren't in the aggregate meta, then host does not pass
21:14:37 mriedem if the flavor doesn't have extra specs at all, then host passes
21:14:51 mriedem that's the case i'm wondering about
21:15:07 melwitt yeah, and I remember the latter was a relatively new addition. "relatively new" meaning I remember when it got added
21:15:18 melwitt lemme see
21:15:34 mriedem so the only way to really restrict everything would be to put extra specs on all of your flavors
21:15:36 mriedem i think
21:17:19 melwitt https://review.openstack.org/#/c/241016/ was where it got added
21:17:46 mriedem crazy yahoo people

Earlier   Later