Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-19
15:22:41 mriedem so i don't see a problem there
15:23:02 bauzas mriedem: you know that most of the time, people don't care unless we break them
15:23:16 mriedem then i guess they should care?
15:23:19 mriedem lest be broken?
15:23:26 mriedem like,
15:23:40 mriedem the ocata release notes are going to a big fat YOU NEED TO UPGRADE PLACEMENT BEFORE SCHEDULER
15:23:41 johnthetubaguy so there is a way you can fix up your release N, so you get a smooth roll to N+1
15:23:47 mriedem if you don't read that and upgrade scheduler anyway, then sorry
15:23:54 johnthetubaguy thats the important bit
15:24:17 bauzas mriedem: correct me if I'm wrong but we always assume that we can deal with N-1 versions of our components
15:24:30 johnthetubaguy from the summit the majority still turn the old one off, and then turn the new one on
15:24:38 bauzas mriedem: if so, why couldn't we assume that the scheduler has to assume a n-1 placement service ?
15:24:44 johnthetubaguy bauzas: its more because we never defined an upgrade order
15:24:56 johnthetubaguy its certainly more usual to do that
15:25:02 mriedem n-1 for computes definitely
15:25:11 mriedem n-1 for scheduler probably,
15:25:16 mriedem because n-sch is pretty standalone
15:25:28 mriedem n-1 for n-api probably, because it's just new microversions
15:25:40 mriedem but n-cond needs to be first because it deals with, well, conducting
15:26:17 jaypipes bhagyashris: hey there.
15:26:17 bauzas mriedem: my thoughts are :
15:26:35 bauzas mriedem: getting a response from the placement service is an hard requirement
15:26:40 bauzas because we say it's mandatory
15:26:56 bauzas so, getting something like EndpointNotFound should be an hard stop
15:26:57 bauzas but
15:27:18 bauzas if we get something like a microversion not supported, I'd treat that like a soft fail
15:27:25 bauzas and do the old way
15:27:34 mriedem i just posted to the ML
15:27:36 mriedem i have to run to scrum
15:28:04 mriedem vladikr: i'd like to tease the unit tests out a bit in https://review.openstack.org/#/c/405954/
15:28:44 johnthetubaguy bauzas: supporting N-1 feels like the normal thing to do, but isn't that a lot of extra code to maintain?
15:28:57 bauzas johnthetubaguy: not really
15:29:13 bauzas johnthetubaguy: we're getting the exceptions from keystone
15:29:48 bauzas if I'm getting a 400, that means I'm running an old microversion on the placement side
15:29:57 vladikr mriedem, sure, will add that, thanks
15:30:59 johnthetubaguy bauzas: its a bit tempting to see how bad it would be to support 1.0 and the latest
15:31:12 bauzas johnthetubaguy: in https://review.openstack.org/#/c/417961/10/nova/scheduler/host_manager.py@660, the or [] makes a problem with calling the placement service returning a novalidhosts
15:31:54 bauzas johnthetubaguy: I could just try to verify in the upcall whether I'm getting a 400 or something else and treat that differently
15:32:23 bauzas that would mean that operators would necessary have to run the placement service in Ocata, but they could be allowed to run the newton release of it
15:33:04 johnthetubaguy bauzas: well, that have to update placement before the turn on any new n-cpu I guess?
15:33:09 bhagyashris jaypipes: I want to discuss few points regarding the resource provider: 1. As the palcement apis are called at the scheduler side using the patch [1] https://review.openstack.org/#/c/417961 which basically updates the allocations of the resources in placement databse .
15:33:42 jaypipes bhagyashris: gimme ten minutes to read back on IRC, k? :)
15:34:28 jaypipes bauzas: FYI, Fuel definitely isn't CD :)
15:34:33 bauzas johnthetubaguy: I think it would be acceptable to get back to calling the DB if we get a 400 for knowing the list of compute nodes
15:35:16 bauzas johnthetubaguy: but we could make a stronger contract, like checking the max n-cpu version
15:35:26 bhagyashris jaypipes: so is there need to enable the periodic task (update_available_resource()) at nova compute side?
15:35:30 bauzas johnthetubaguy: and stop to be gentle if we find an ocata n-cpu
15:36:10 bhagyashris jaypipes: ok. np.
15:36:15 bauzas that way, the upgrade path would be n-cond, <other services incl. sched>, n-cpu
15:36:16 johnthetubaguy bauzas: yeah, that full solution is the one that sounds like a lot of work, although it sounds more correct
15:36:27 bauzas I can try to draft it
15:39:20 gibi mriedem: hi! I cannot participate on the team meeting today but I updated the notification subteam part of the agenda with some highlights
15:44:19 bauzas mriedem: responded to your thread with a possibility
15:46:43 openstackgerrit Gábor Antal proposed openstack/nova: Transform instance.live_migration_rollback notification https://review.openstack.org/402124
15:48:22 mriedem gibi: thanks
15:49:11 mriedem bhagyashris: update_available_resource is a required periodic task on the computes yes
15:49:24 mriedem otherwise we don't get any resource tracking into the compute nodes table that the scheduler uses for placement
15:53:27 mriedem fyi that nova ci is blocked until https://review.openstack.org/#/c/422709/ is merged
15:56:18 openstackgerrit Jay Pipes proposed openstack/nova: placement: create aggregate map in report client https://review.openstack.org/407309
15:57:28 sahid jaypipes: un tout petit reminder :)
15:57:54 jaypipes sahid: yup, will get to it today.
16:01:36 markus_z thorst: Got a minute? I'm wondering which release-model you use for nova-powervm. It looks like "Common cycle with development milestones" but I couldn't find it in your docs.
16:02:31 thorst markus_z: sure. Yeah, that's what we strive for
16:03:18 markus_z thorst: Ah, ok. There was a release missing for "4.0.0.0b1", that irritated me.
16:03:53 thorst markus_z: :-( yeah, I'll talk to esberglu, he's our guy managing / coordinating those
16:06:56 markus_z thorst: For "nova-dpm" we were also thinking about starting with the same version number as nova (15.0.0). It feels odd to me but I don't see an argument against that.
16:07:22 markus_z thorst: It would be easier to say "for nova v15.0.0 you need nova-dpm v15.0.0"
16:07:23 thorst markus_z: I believe the reason we didn't do that was because all of the projects had version numbers reflective of their current version
16:08:01 thorst we agreed with your same logic version number wise, but everyone we engaged with just talked in terms of 'mitaka', 'newton', 'ocata', etc... instead
16:08:26 thorst so we started at v1, but I don't think we felt super strong about it
16:09:06 markus_z yeah, I have to ask around in the team if there are strong opinions.
16:09:34 thorst ultimate goal is to be in nova anyway :-)
16:10:06 markus_z IIRC Nova also started with v12 in Liberty and used "v2015" in Kilo.
16:10:14 markus_z thorst: true true
16:10:31 markus_z thorst: okay, thanks for your time!
16:10:41 thorst markus_z: np
16:18:40 dims sdague : mriedem : +2A on the requirements for the new mox release.
16:18:57 mriedem dims: thanks
16:21:44 openstackgerrit Claudiu Belu proposed openstack/nova: Hyper-V PCI Passthrough https://review.openstack.org/420614
16:21:50 _gryf mriedem, hi
16:23:37 _gryf you've mentioned in the bug report that in some point we would like to have all keystoneauth stuff failure handling
16:23:52 _gryf i mean that br: https://bugs.launchpad.net/nova/+bug/1656075
16:23:52 openstack Launchpad bug 1656075 in OpenStack Compute (nova) "DiscoveryFailure when trying to get resource providers from the scheduler report client" [Low,Confirmed] - Assigned to Roman Dobosz (roman-dobosz)
16:24:19 _gryf do you think that time is now, or we want to just cover this case and do the later on pike?
16:24:36 _gryf *do the rest later
16:26:24 mriedem _gryf: i don't have a strong opinion right now
16:27:16 _gryf maybe let's patch this case with additional TODO in the code. what do you think?
16:27:59 mriedem i actually thought this was already fixed
16:28:30 openstackgerrit Pawel Koniszewski proposed openstack/nova: Move migration_downtime_steps to libvirt/migration https://review.openstack.org/407517
16:28:33 mriedem i'm fine with fixing the one thing now, and doing all in pike
16:28:38 scottda ildikov: Would you like to weigh in on this? https://review.openstack.org/#/c/422078/
16:28:39 _gryf mriedem, well, not on that side
16:28:44 openstackgerrit Pawel Koniszewski proposed openstack/nova: Change exponential function to linear https://review.openstack.org/407518
16:28:50 _gryf it will still fail if there is no keystone around
16:28:54 openstackgerrit Pawel Koniszewski proposed openstack/nova: Mark live_migration_downtime_steps as deprecated for removal https://review.openstack.org/408002
16:30:33 _gryf failure was caused by the fact, that compute was started earlier than keystone. So probably the right choice would be to make it wait a bit (using warn_limit)
16:30:50 ildikov scottda: done, thanks
16:39:02 markus_z esberglu: hey, you're the guy managing the nova-powervm releases, right? It looks like your team doesn't use the "openstack/releases" repo for that. Why is that?
16:39:42 openstackgerrit Davanum Srinivas (dims) proposed openstack/nova: [WIP] ignore me - trying experimental jobs https://review.openstack.org/421209
16:41:13 BobBall Stupid question... Is there a way to run the nova unit tests with fewer than the number of CPUs on the host? I've got a shared development host with 40 CPUs and while the unit tests finish very quickly with that number of CPUs using them all is very antisocial and wedges the rest of the system

Earlier   Later