| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-04 | |||
| 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 | |
| 22:23:48 | dansmith | oh I thought this was the one john had commented on, | |
| 22:24:01 | dansmith | but this is different | |
| 22:24:02 | mriedem | there was never a spec for this, | |
| 22:24:06 | mriedem | we've talked about it a billion times | |
| 22:24:19 | mriedem | and i thought someone was going to write a spec, but didn't, so i posted to the ML over the weekend and wrote a spec, | |
| 22:24:26 | mriedem | to which ftersin pointed out this legacy hack for ec2 | |
| 22:25:26 | dansmith | yeah | |
| 22:25:43 | mriedem | artom: do you know if, off the top of your head, we snapshot a volume backed instance that has bdm tags, do the bdm tags also go into the block_device_mapping_v2 image metadata? | |
| 22:25:58 | mriedem | so that when you boot a new server from that snapshot image, it does bfv with a tagged bdm? | |
| 22:30:41 | dansmith | guh what a mess | |
| 22:31:03 | mriedem | heh yeah totally | |
| 22:31:49 | dansmith | so I was thinking what mdbooth said before I got down and saw his comment, | |
| 22:32:01 | dansmith | but your reply doesn't make sense to me | |
| 22:32:19 | dansmith | I think his point is to just leave device_name in the api, but make it clear in all the docs that it is in no way related to the block device name in the guest | |
| 22:32:33 | dansmith | meaning, change the docs and examples to something like "disk1" and such | |
| 22:34:22 | mriedem | i meant rather than correlate on device_name, we correlate on tag | |
| 22:35:01 | mriedem | we do actually set a device_name in the bdm based on what libvirt calculates it to be | |
| 22:35:28 | dansmith | we overwrite what the user gave us? | |
| 22:35:30 | mriedem | so i think having something in the api that says this volume is attached at /dev/vdb but it's actually not, is part of the problem, and why we wanted to remove it | |
| 22:35:36 | mriedem | dansmith: yes | |
| 22:35:43 | mriedem | the libvirt driver completely ignores what the user specified | |
| 22:35:45 | mriedem | since liberty | |
| 22:35:57 | mriedem | as noted in the spec | |
| 22:36:01 | dansmith | but libvirt doesn't know what it is in the guest | |
| 22:36:26 | dansmith | it knows that it thinks it will be vdb in the guest based on where it got attached, but the guest chooses that | |
| 22:36:45 | mriedem | then why do we even call https://review.openstack.org/#/c/189632/10/nova/virt/libvirt/driver.py@6802 ? | |
| 22:37:09 | mriedem | i guess because we need to have *something* in the bdm table b/c it's used for a shitty primary key | |
| 22:37:20 | dansmith | to populate that field with something semi recognizeable, I guess | |
| 22:37:28 | dansmith | but it's definitely not the right thing even in that case | |
| 22:38:27 | mriedem | ok | |
| 22:38:33 | mriedem | so we could just throw a uuid in bdm.device_name | |
| 22:38:36 | mriedem | and it wouldn't matter | |
| 22:38:36 | dansmith | as you say we _could_ do away with all of this and use the tag for sure | |
| 22:38:42 | dansmith | right, we could | |
| 22:39:07 | dansmith | but the least amount of change would be to just be more ambiguous about what "device name" is I think | |
| 22:39:21 | dansmith | although we should ask a xenapi person, | |
| 22:39:27 | dansmith | as in xen it does actually match | |
| 22:39:32 | dansmith | or can, or did, or whatever | |
| 22:39:44 | dansmith | and libvirt with xen may try to make it match, I have no idea | |