| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-17 | |||
| 20:01:56 | mriedem | which i'd think we don't actually want to do that | |
| 20:02:52 | alex_xu | mriedem: actually there is plan to do that. it is jsut the people, who commit to do that, disappeared | |
| 20:03:04 | mriedem | sure, | |
| 20:03:09 | mriedem | but that was a long time ago | |
| 20:03:22 | alex_xu | yes, super long time ago | |
| 20:03:25 | mriedem | i'm not sure we need to be exposing pci details out of the compute REST API | |
| 20:04:21 | alex_xu | why? currently we really have no way to query what pci device on the host | |
| 20:06:52 | efried | Should that be a get_inventory() thing? | |
| 20:07:30 | mriedem | efried: unrelated | |
| 20:07:48 | mriedem | alex_xu: i'm sure there are other tools available to get that information from the host system | |
| 20:07:53 | mriedem | actual inventory reporting tools | |
| 20:08:16 | mriedem | alex_xu: i sort of consider this like https://docs.openstack.org/developer/nova/policies.html?highlight=metrics#metrics-gathering | |
| 20:08:43 | mriedem | years ago we thought it was a great idea for nova to be a metrics gatherer, but in newton we decided we're not so great at that | |
| 20:08:51 | mriedem | and shouldn't be in the business of doing it | |
| 20:09:23 | mriedem | i'll post to the ML about the os-pci api | |
| 20:10:09 | alex_xu | mriedem: thanks, i probably get your point. ++ for a email | |
| 20:19:53 | mriedem | http://lists.openstack.org/pipermail/openstack-dev/2017-March/114261.html | |
| 20:20:08 | mriedem | superdan: leakypipes: sdague: ^ you'd probably like to weigh in | |
| 20:21:47 | sdague | mriedem: if you need "... with fire!" sure | |
| 20:22:12 | mriedem | acks are always good | |
| 20:22:18 | mriedem | so i don't just look like a maniac | |
| 20:23:15 | superdan | I thought it was actually kindof important for the pci use case, | |
| 20:23:20 | superdan | but if it's not enabled by default, hopefully that is not true | |
| 20:23:36 | mriedem | apparently not important enough since icehouse for anyone to care to expose it | |
| 20:23:46 | mriedem | or they did via and out of tree extension/patch | |
| 20:23:55 | mriedem | cfriesen: i'm looking at you | |
| 20:24:13 | sdague | superdan: it's not just not enabled, it was never plumbed back in at all | |
| 20:24:14 | superdan | well, it'd be a packaging change, right? but yeah | |
| 20:24:29 | mriedem | it'd be a change to setup.cfg to enable it | |
| 20:24:40 | mriedem | plus a microversion at this point | |
| 20:24:40 | superdan | just removing that comment out is all you'd need to do right? | |
| 20:24:50 | mriedem | if you don't care about microversions, sure | |
| 20:25:56 | superdan | it's not enabled in our git tree, I'd have to check the actual packages to make sure it's not enabled there, | |
| 20:26:05 | superdan | but it'd be better to just get vladik or someone to chime in | |
| 20:26:19 | mriedem | i'm not following your point about packaging | |
| 20:26:33 | mriedem | like enabled in the rpm spec? | |
| 20:26:40 | mriedem | by uncommenting that line in the setup.cfg? | |
| 20:26:44 | superdan | yeah, something like that | |
| 20:26:49 | mriedem | that would be terribad | |
| 20:26:59 | sdague | so, I kind of feel like that would be a big bad on the packaging side | |
| 20:27:00 | superdan | I dunno, I have no idea, I'm just saying we should ask some pci-knowing person to make sure | |
| 20:27:08 | sdague | well, it is on the ML | |
| 20:27:12 | mriedem | "sorry developers, you didn't know it but we were supporting this b/c of code in the rpm spec all along!" | |
| 20:27:16 | superdan | yep | |
| 20:27:50 | sdague | I kind of feel like that's in the category of "you are running a fork" | |
| 20:27:54 | superdan | I'll point some people at it to make sure it gets seen | |
| 20:28:26 | sdague | even though the change looks small, it would light up a ton of dark code that has no active testing | |
| 20:28:31 | superdan | I think that it being commented out in setup.cfg would make people just assume it's not on by default | |
| 20:28:43 | superdan | but that there's not a problem enabling it | |
| 20:28:53 | superdan | does turning that on make it show up in 2.1 | |
| 20:28:54 | superdan | ? | |
| 20:28:54 | mriedem | i explain a problem with enabling it | |
| 20:29:03 | mriedem | i'm not sure | |
| 20:29:19 | mriedem | as noted in the email, we pass the json blob straight out of the db via the rest api | |
| 20:29:20 | superdan | because if so, that's a bit on us too | |
| 20:29:21 | mriedem | no whitelist | |
| 20:29:29 | openstackgerrit | Eric Fried proposed openstack/nova master: PowerVM Driver: spawn/delete #1: no-ops https://review.openstack.org/438119 | |
| 20:29:37 | superdan | mriedem: we have other (or have had other) apis that do the same thing, so that in itself doesn't mean much :) | |
| 20:29:59 | mriedem | but we shouldn't be doing that, and i'm hoping we are actively trying to clamp done on doing anything like that, | |
| 20:30:06 | mriedem | like the diagnostics API rewrite | |
| 20:30:10 | mriedem | *down | |
| 20:30:24 | openstackgerrit | christopher.uhler proposed openstack/nova master: Libvirt volume driver for Veritas HyperScale https://review.openstack.org/443951 | |
| 20:30:47 | superdan | definitely | |
| 20:31:33 | sdague | I also think we definitively had said API extensions are deprecated and not supported any more | |
| 20:32:21 | mriedem | we did, in newton | |
| 20:32:27 | mriedem | this would have to come back in as a microversion | |
| 20:32:30 | mriedem | like server tags | |
| 20:32:33 | mriedem | which was 2.26 | |
| 20:32:34 | sdague | yep | |
| 20:32:42 | mriedem | that's why cyeoh removed it and opened a bug | |
| 20:32:43 | sdague | anyway, it's on the mailing list | |
| 20:37:40 | openstackgerrit | Sujitha proposed openstack/nova master: Adding auto_disk_config field to InstancePayload https://review.openstack.org/419185 | |
| 20:38:24 | superdan | mriedem: sdague I think we're good | |
| 20:38:32 | sdague | superdan: \o/ | |
| 20:39:05 | mriedem | yay | |
| 20:39:16 | superdan | I'd let it simmer on the list for a bit, at least | |
| 20:39:25 | superdan | it would also be a candidate for interfacing with ops in boston, | |
| 20:39:31 | superdan | at least to explain it if anyone speaks up | |
| 20:39:49 | mriedem | i did post the same thing to the dev and ops list btw | |
| 20:39:53 | mriedem | but yeah i'm not removing it today | |
| 20:39:55 | superdan | okay | |
| 20:40:32 | superdan | well, we should remove it regardless of the response | |
| 20:42:10 | cuhler | Hi. I submitted a new Nova volume driver and the os-brick connector on which it depends for review for Pike. How can I make the volume driver unit tests run before the os-brick connector is approved and merged to master? Some way to configure tox/testr? | |
| 20:42:38 | cuhler | https://review.openstack.org/#/c/443951/ | |
| 20:42:44 | cuhler | https://review.openstack.org/#/c/442754/ | |
| 20:53:56 | sbezverk | mriedem: ping | |
| 20:55:09 | mriedem | sbezverk: pong | |
| 21:00:16 | openstackgerrit | Matthew Edmonds proposed openstack/nova master: fix os-volume_attachments policy checks https://review.openstack.org/389314 | |
| 21:11:13 | mriedem | superdan: we might have a problem with the services uuid in api thin | |
| 21:11:14 | mriedem | *thing | |
| 21:11:15 | mriedem | https://developer.openstack.org/api-ref/compute/#disable-scheduling-for-a-compute-service | |
| 21:11:22 | mriedem | the action APIs on the services records don't take an id | |
| 21:11:28 | mriedem | they take the host/binary | |
| 21:11:38 | mriedem | would those be enough to uniquely identify a service within a cell? | |
| 21:11:45 | superdan | yeah | |
| 21:11:46 | superdan | should be | |
| 21:12:03 | superdan | if you have two hosts with the same hostname you have scheduling problems anyway | |
| 21:12:14 | superdan | I mean, it'd be better if they used a uuid, but.. | |
| 21:12:25 | mriedem | sure | |
| 21:12:29 | mriedem | ok, i'll make a note of it in here | |