| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-13 | |||
| 17:28:20 | mriedem | i assume just 7.3.1611 | |
| 17:28:37 | mriedem | so we treat all minor versions of rhel 7 the same | |
| 17:28:39 | mriedem | in devstack | |
| 17:29:06 | cfriesen | controller-1:~$ ./lsb_release -r -s | |
| 17:29:08 | cfriesen | 7.3.1611 | |
| 17:30:04 | cfriesen | mriedem: on CentOS 7.2 it shows 7.2.1511 | |
| 17:30:15 | mriedem | yeah, we treat those all as rhel7 in devstack | |
| 17:30:20 | mriedem | answers my question though, thanks | |
| 17:35:06 | openstackgerrit | Maciej Szankin proposed openstack/nova master: conf: mark glance.api_servers opt as required https://review.openstack.org/428241 | |
| 17:38:08 | mriedem | sdague: is the 7.0 in that list for oracle linux? | |
| 17:38:16 | mriedem | still trying to find when that was added | |
| 17:38:49 | mriedem | if you don't know that's fine, i'm digging | |
| 17:43:31 | mriedem | oh i guess it's debian 7.0 | |
| 17:53:59 | mriedem | BobBall: does the xen ci use this? https://github.com/openstack-dev/devstack/blob/master/tools/xen/xenrc#L66 | |
| 17:54:20 | BobBall | *hangs his head in shame* | |
| 17:54:30 | mriedem | or can that be changed to xenial? | |
| 17:54:33 | BobBall | I don't want to answer that... | |
| 17:54:34 | BobBall | :D | |
| 17:54:57 | BobBall | We actually have a work item to change to Xenial which is something we're looking at currently | |
| 17:55:29 | mriedem | ok, i guess we'll see if https://review.openstack.org/#/c/433218/ blows up the xen ci | |
| 17:55:32 | BobBall | The Cinder breakage a few weeks ago didn't affect infra because it was already using Xenial (and therefore a new enough version of lvm) | |
| 17:56:21 | BobBall | It *may* blow up, but it might not... we did specify FORCE=yes for a while; not sure if we removed that or not. | |
| 17:56:57 | BobBall | It's therefore possible that this is just the "start" of random breakages until we have upgraded to Xenial | |
| 17:57:07 | mriedem | ok, it's -WIP for now | |
| 17:59:34 | BobBall | http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/01/432001/8/check/dsvm-tempest-neutron-network/7e28db3/logs/localrc.txt.gz contains FORCE=yes (although the comment is ages old because the original CI was using saucy!) | |
| 18:00:10 | BobBall | so I think it probably won't break the CI... but definitely something that increases the urgency of upgrading to Xenial. | |
| 18:03:49 | sdague | mriedem: should probably remove f23 at the same time | |
| 18:03:57 | sdague | that's no longer distro supported | |
| 18:08:10 | sdague | mriedem: I tweaked it | |
| 18:09:53 | mriedem | sdague: ok, sort of unrelated, along with adding zesty, but i can mention that in the commit message | |
| 18:10:29 | sdague | yeh, it's just mostly an adjustment to the current cycle distros | |
| 18:12:33 | mriedem | melwitt: dansmith: jaypipes: how much are we going to try and get this into rc2? or can it be backported? https://review.openstack.org/#/q/topic:fix-bfv-boot-resources | |
| 18:12:58 | jaypipes | mriedem: happy to review those, sure. | |
| 18:14:10 | dansmith | mriedem: they wouldn't be reasonable for a backport, IMHO, because the scheduler will send instances to computes that wouldn't take them because their claims code isn't updated | |
| 18:14:25 | dansmith | mriedem: haven't looked to see if they're accounting for newton computes even | |
| 18:14:32 | dansmith | seems like a large and risky thing for an rc2 to me | |
| 18:15:26 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Add policy-project-checks spec https://review.openstack.org/433037 | |
| 18:15:36 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: WIP: spec about having observer role by default https://review.openstack.org/427872 | |
| 18:16:32 | mriedem | these patches aren't accounting for newton computes | |
| 18:16:46 | johnthetubaguy | sdague: I split up the policy spec into more manageable chunks | |
| 18:17:16 | johnthetubaguy | sdague: if you get chance pre PTG for a quick check, that would be awesome | |
| 18:18:23 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hardware: Flatten functions https://review.openstack.org/367470 | |
| 18:18:24 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Standardize '_get_XXX_constraints' functions https://review.openstack.org/385071 | |
| 18:18:24 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Rename '_numa_get_constraints_XXX' functions https://review.openstack.org/385072 | |
| 18:18:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: De-duplicate _numa_get_flavor_XXX_map_list https://review.openstack.org/385074 | |
| 18:18:38 | macsz | gcb: are you working on python3 support and removing mox? | |
| 18:19:12 | mriedem | johnthetubaguy: i see this backport popped up for ocata https://review.openstack.org/#/c/432954/ is that something we should get into rc2? | |
| 18:19:19 | mriedem | it adds a config option for the placement endpoint | |
| 18:19:31 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Fix suggested database migration command https://review.openstack.org/420060 | |
| 18:20:13 | johnthetubaguy | mriedem: I am tempted to add it, although it is a bit feature-like, it does mean users can use their service catalog in their normal way for placement | |
| 18:21:19 | mriedem | johnthetubaguy: checking config options, i guess you can do this same thing more or less for connecting to glance/cinder/neutron/ironic too | |
| 18:22:02 | johnthetubaguy | mriedem: the other ones have URL over-rides that do a similar (but worse) thing | |
| 18:22:39 | mriedem | yeah | |
| 18:23:27 | johnthetubaguy | mriedem: its a bit like this I guess: https://github.com/openstack/nova/blob/8de0c648c218dd748c2076551d1d9819dbeb3bd6/nova/conf/cinder.py#L25 | |
| 18:23:52 | mriedem | yeah | |
| 18:24:15 | mriedem | it will be fun when someone wants to not call the endpoint "placement" in their service catalog | |
| 18:25:02 | mriedem | oh also, this missed nova-status | |
| 18:25:18 | mriedem | https://github.com/openstack/nova/blob/master/nova/cmd/status.py#L182 | |
| 18:25:25 | johnthetubaguy | mriedem: there is some follow up work from that service token stuff, where we should fix up what we do with all that | |
| 18:25:46 | johnthetubaguy | mriedem: dang, that bit got missed | |
| 18:25:50 | mriedem | johnthetubaguy: as far as pike bp? | |
| 18:26:41 | johnthetubaguy | mriedem: I haven't created a BP for that, probably worth doing (tells raj_singh so there are two folks trying to remember that ^) | |
| 18:26:45 | mriedem | johnthetubaguy: https://blueprints.launchpad.net/nova/+spec/use-service-tokens-pike | |
| 18:26:48 | mriedem | it's already done | |
| 18:26:55 | johnthetubaguy | its more follow on from that I guess | |
| 18:27:18 | johnthetubaguy | like glance doesn't use the service catalog at all right now | |
| 18:27:24 | mriedem | yeah i know | |
| 18:27:33 | mriedem | the patch to use ksa was approved but tests were failing | |
| 18:27:41 | mriedem | b/c of the global variables being mocked | |
| 18:27:58 | mriedem | anyway, the pike bp is approved | |
| 18:28:22 | mriedem | no unit test for this? https://review.openstack.org/#/c/426163/ | |
| 18:28:23 | mriedem | gah | |
| 18:28:43 | raj_singh | mriedem: I think we fixed the tests for that, let me take a look. | |
| 18:29:14 | johnthetubaguy | mriedem: :S yeah, no tests, not sure how I missed that, grrr | |
| 18:29:28 | mriedem | i can add tests and also fix the nova-status thing, | |
| 18:29:41 | mriedem | but if we're going to backport the config option change, we should have the other stuff (unit test and nova-status | |
| 18:29:58 | mriedem | plus i'm also procrastinating on dealing with https://etherpad.openstack.org/p/nova-ptg-pike | |
| 18:30:11 | johnthetubaguy | good to get both fixed for sure | |
| 18:30:13 | raj_singh | mriedem: https://review.openstack.org/#/c/412634/ Can you take your -2 off. | |
| 18:30:31 | mriedem | raj_singh: done | |
| 18:30:47 | raj_singh | thx, you are welcome to replace it with -1 :) | |
| 18:30:51 | johnthetubaguy | the others could be post release, worst case, but thats probably a bad idea | |
| 18:31:19 | mriedem | well if we land the one but nova-status doesn't use it, nova-status could fail since it's pusing the wrong endpoint | |
| 18:31:26 | mriedem | *using | |
| 18:31:37 | mriedem | assuming people are going to use nova-status, but i hope they do | |
| 18:32:21 | johnthetubaguy | yeah, it sucks to have that broken | |
| 18:32:29 | openstackgerrit | Anusha Unnam proposed openstack/nova master: Reno for additional-notification-fields-for-searchlight https://review.openstack.org/428835 | |
| 18:32:40 | mriedem | raj_singh: did you see this gem? https://review.openstack.org/#/c/431713/ | |
| 18:33:01 | raj_singh | mriedem: you rock! | |
| 18:35:42 | openstackgerrit | Pushkar Umaranikar proposed openstack/nova master: Placement api: set custom json_error_formatter in aggregate and usage https://review.openstack.org/433224 | |
| 18:39:08 | melwitt | dansmith, mriedem: what's "newton computes" mean? | |
| 18:39:27 | dansmith | melwitt: compute nodes still running n-cpu from newton | |
| 18:39:41 | melwitt | oh, okay | |
| 18:42:08 | sterdnotshaken | With regard to regions, is it required to have replica's of Cinder, Neutron, Nova, etc within each region? I know that all the separate regions share Horizon and Keystone instances, but I'm just wondering if we can get away with not duplicating some of these services in each region… | |
| 18:43:13 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Add policy-project-checks spec https://review.openstack.org/433037 | |
| 18:47:08 | oomichi | sdague: johnthetubaguy: hi, about api-ref thing: Which do you prefer: "Including object name in parameter" or not (like addFixedIp.networkId vs networkId) | |
| 18:47:44 | oomichi | sdague: johnthetubaguy: I am reviewing https://review.openstack.org/#/c/338606/18/api-ref/source/servers-action-fixed-ip.inc | |
| 18:48:23 | oomichi | addFixedIp.networkId seems easy to understand the structures of requrest/response of APIs | |
| 18:49:12 | johnthetubaguy | oomichi: I thought we only did that if it was unclear which bit of the request/response we were talking about | |
| 18:49:47 | johnthetubaguy | oomichi: so for host.host, we needed it for all of them | |