| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-04 | |||
| 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 | |
| 21:17:52 | melwitt | yeah, I think you're right. I'm trying to see if the review and/or bug mention how that's supposed to be okay | |
| 21:18:00 | melwitt | heh | |
| 21:20:26 | melwitt | I guess, if the flavor has no extra_specs at all, it's like saying "this is okay anywhere" | |
| 21:20:27 | openstackgerrit | Matt Riedemann proposed openstack/nova master: nova-net: remove get_instance_nw_info from API subclass https://review.openstack.org/453336 | |
| 21:20:37 | mriedem | yeah | |
| 21:20:43 | melwitt | like, this flavor is okay to be anywhere because it has no special requirements | |
| 21:20:48 | mriedem | even if it might land on a host that can't support it | |
| 21:20:58 | mriedem | the flavor might not have requirements, but the host might | |
| 21:21:06 | melwitt | well, if it has support requirements, it would have an extra_specs of some kind, no? | |
| 21:21:11 | melwitt | oh | |
| 21:21:24 | mriedem | this is for the scaleio ephemeral backend spec, | |
| 21:21:36 | mriedem | which requires that root_gb on the flavor be in multiples of 8 | |
| 21:21:57 | mriedem | in a mixed compute environment, you'd have flavors with extra specs that fit that and have an extra spec to hit those scaleio host aggregates, | |
| 21:22:13 | mriedem | i'm trying to figure out how you get non-specific flavors for scaleio to *not* land on those host aggregates | |
| 21:22:26 | melwitt | I see | |
| 21:22:41 | mriedem | in reality anyone using this is probably using all scaleio all the time everywhere b/c they are buying a converged architecture product from EMC | |
| 21:23:05 | mriedem | and using anything else voids their support contract with EMC :) | |
| 21:23:34 | melwitt | :) | |
| 21:23:41 | openstackgerrit | Emilien Macchi proposed openstack/nova master: Add sem-ver flag so pbr generates correct version https://review.openstack.org/453338 | |
| 21:24:01 | EmilienM | mriedem: ^ is it something you would accept? | |
| 21:24:53 | mriedem | EmilienM: is there supposed to be a code change with that? | |
| 21:24:59 | EmilienM | mriedem: nope | |
| 21:25:32 | EmilienM | mriedem: https://github.com/openstack/ironic/blob/master/doc/source/dev/releasing.rst#things-to-do-before-releasing | |
| 21:25:50 | EmilienM | the semver thing is just in the commit message | |
| 21:26:08 | EmilienM | "sem-ver: feature" bumps Y | |
| 21:26:14 | EmilienM | "sem-ver: api-break" bumps X | |
| 21:26:20 | EmilienM | (if your version is X.Y) | |
| 21:26:55 | mriedem | but pike is 16.0.0 | |
| 21:26:58 | mriedem | ocata was 15.0.0 | |
| 21:27:01 | mriedem | newton is 14.0.0 | |
| 21:27:02 | mriedem | etc | |
| 21:27:51 | EmilienM | ok so we need to bump X I guess | |
| 21:28:12 | mriedem | didn't this used to all be handled in setup.cfg? | |
| 21:28:20 | openstackgerrit | Emilien Macchi proposed openstack/nova master: Add sem-ver flag so pbr generates correct version https://review.openstack.org/453338 | |
| 21:28:22 | mriedem | we also have tags in the release repo | |
| 21:28:53 | EmilienM | this thing helps us to update packages without the tag | |
| 21:29:05 | EmilienM | so our tooling can find out there is a new version from pbr | |
| 21:29:52 | EmilienM | afik historically nova was releasing only X.0.Z++ | |
| 21:30:07 | mriedem | generally yes | |
| 21:30:23 | mriedem | i think we've bumped a minor version on a stable branch when we had to pull in a new dependency | |
| 21:30:33 | mriedem | or bump a minimum dependent package version for a security fix, something like that | |
| 21:31:42 | mriedem | and you're only doing this for nova and ironic? | |
| 21:31:54 | EmilienM | I'm going to do it for all projects | |