Earlier  
Posted Nick Remark
#openstack-nova - 2017-02-13
17:03:01 openstackgerrit Anusha Unnam proposed openstack/nova master: Reno for additional-notification-fields-for-searchlight https://review.openstack.org/428835
17:12:50 mriedem sdague: if we're going to bump the minimum required libvirt in pike https://review.openstack.org/#/c/432700/ to a version that exceeds what's available in trusty 14.04, do i also need to change https://github.com/openstack-dev/devstack/blob/e0a37cf21e43fbb4ba3f9f8fa5321a0a0e1bedf1/stack.sh#L195 so trusty isn't in that list?
17:12:54 mriedem at least when using libvirt
17:13:10 sdague mriedem: yeh
17:13:13 mriedem same for a few of those others
17:13:13 mriedem ok
17:13:41 sdague which is fine, xenial has been out for a year, there really is no reason for devstack to still stay on trusty
17:22:50 mriedem hmm, not sure what rhel7.1 shows up as
17:22:53 mriedem we check for 'rhel7'
17:23:11 mriedem kashyap: do you have a rhel 7.1 system handy?
17:23:23 mriedem or is rhel7 == rhel 7.0?
17:25:03 cfriesen mriedem: /etc/redhat-release has the appropriate release number...latest is 7.3.1611
17:25:13 cfriesen not sure what you're using to check the release
17:26:05 openstackgerrit John Garbutt proposed openstack/nova-specs master: WIP: spec about having observer role by default https://review.openstack.org/427872
17:27:20 mriedem cfriesen: what does "lsb_release -r -s" show?
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

Earlier   Later