Earlier  
Posted Nick Remark
#openstack-nova - 2017-02-13
15:57:57 mdbooth mriedem: I checked that it had a +1 from Jenkins... are they still in use?
15:58:06 mriedem oh wait
15:58:12 mriedem that moved to xenapi library
16:02:36 mriedem nvm, sorry, +W on that one now
16:02:55 mriedem fwiw i don't trust jenkins on cleanups like this since we might not have test coverage
16:03:48 mdbooth mriedem: True, but at the same time not trusting it for things like this kinda devalues it.
16:04:38 mriedem i still value it, but i don't trust it for dead code removal
16:04:42 mriedem trusty, but verify
16:04:48 mriedem like the great reagan always said
16:04:54 mriedem *trust :)
16:11:08 sfinucan mriedem: Aye, I checked them all first :)
16:12:57 lyarwood mdbooth: yup you are correct re the stable/newton test backport btw
16:13:27 mdbooth lyarwood: Just learned you're on holiday. Go away :)
16:13:43 lyarwood \o/
16:27:31 cdent rust, but vitrify, like the great reagan always did
16:30:36 cfriesen does anyone know off the top of their head whether any code paths other than initial instance creation set task_state=task_states.SCHEDULING ?
16:40:09 openstackgerrit Pushkar Umaranikar proposed openstack/nova master: Placement api: set custom json_error_formatter in resource_provider https://review.openstack.org/433176
16:41:42 markus_z mriedem: I tried to summarize the whole newton-backport story here: https://review.openstack.org/#/c/406898/3 Is that a format which helps you?
16:42:33 mriedem oof, maybe
16:42:41 mriedem i can't digest that right now though
16:43:26 markus_z mriedem: OK, let me know when I can provide more info there.
16:57:40 openstackgerrit Pushkar Umaranikar proposed openstack/nova master: Placement api: set custom json_error_formatter in resource_provider https://review.openstack.org/433176
16:59:37 openstackgerrit Anusha Unnam proposed openstack/nova master: Reno for additional-notification-fields-for-searchlight https://review.openstack.org/428835
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 ^)

Earlier   Later