| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-04 | |||
| 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 | |
| 21:32:07 | EmilienM | so tripleo CI can start testing upgrades | |
| 21:32:47 | EmilienM | I need to leave irc now, feel free to comment or push over the patch | |
| 21:32:52 | EmilienM | I'll catch-up later | |
| 21:34:37 | edleafe | charge/. | |
| 21:40:05 | mriedem | so reading https://docs.openstack.org/developer/pbr/#version we do postversioning since we don't have version in setup.cfg, | |
| 21:40:42 | mriedem | when pbr walks the git tree it finds the last tag, which is 15.0.2 | |
| 21:40:49 | mriedem | and gives some dev version after that i assume | |
| 21:41:17 | mriedem | A missing Sem-Ver line is equivalent to Sem-Ver: bugfix. The bugfix symbol causes a patch level increment to the version. | |
| 21:41:28 | mriedem | so i guess you'd get 15.0.3 actually | |
| 21:41:40 | mriedem | and because we're in pike, that's wrong b/c pike should be 16.0.0 | |
| 21:44:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: docs: update description for AggregateInstanceExtraSpecsFilter https://review.openstack.org/453349 | |
| 21:49:14 | mriedem | melwitt: so maybe if you have a mixed compute env, | |
| 21:49:21 | mriedem | you have to put all of the hosts into aggregates, | |
| 21:49:32 | mriedem | one for scaleio-specific, and one for non-scaleio specific, | |
| 21:49:45 | mriedem | and then all of your flavors have to have extra specs that tie them to either of the aggregates | |
| 21:50:02 | mriedem | that seems like the only way around it | |
| 22:03:19 | mriedem | melwitt: jaypipes: dansmith: i'm +2 on https://review.openstack.org/#/c/453030/ - the rest api impact section could call out the need for a microversion bump, but that could be done in a follow up, or just implied | |
| 22:04:01 | dansmith | I haven't had a chance to look at it yet | |
| 22:09:07 | edleafe | charge/.charge/. | |
| 22:09:16 | edleafe | stupid vm windows | |
| 22:17:36 | openstackgerrit | Sarafraj Singh proposed openstack/nova-specs master: Spec to add per instance timeout for LM https://review.openstack.org/442809 | |
| 22:19:56 | melwitt | mriedem: yeah, agreed. the only other thing I thought of is if we added a near copy of the AggregateInstanceExtraSpecsFilter that _doesn't_ do the empty extra_specs pass thing and operators would have to choose either/or, depending on the behavior desired | |
| 22:22:58 | mriedem | dansmith: i could use some input on this remove bdm device from api spec too, since it's getting caught up in some legacy kerfuffle https://review.openstack.org/#/c/452546/ | |
| 22:23:16 | mriedem | net is bfv with image bdm overrides f'cks it all up | |
| 22:23:38 | mriedem | but, we could remove device from volume attach api i think since that doesn't have the image bdm over bfv mess | |