Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-19
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 bauzas mriedem: my thoughts are :
15:26:17 jaypipes bhagyashris: hey there.
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 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:23:52 _gryf i mean that br: https://bugs.launchpad.net/nova/+bug/1656075
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
16:42:52 openstackgerrit Sujitha proposed openstack/nova: Allow finding instance with invalid regex name https://review.openstack.org/392305
16:44:39 mriedem BobBall: --concurrency=1 i think
16:45:45 esberglu markus_z: Didn't know that was the way to do it
16:45:56 BobBall Awesome - thanks. Needed an extra -- to pass the args through to pretty_tox, but yes: tox -epy27 -- --concurrency=4
16:47:00 markus_z esberglu: I'm still investigating, not yet 100% sure that's the way to go for "out-of-tree" drivers.
16:47:09 jaypipes bhagyashris: ok, sorry, meetings. alright, so to answer your question, patch 417961 doesn't update any allocations information in the placement API at all.
16:47:50 jaypipes bhagyashris: the only thing that updates allocation information currently is the nova-compute node (the resource tracker contains a scheduler reporting *client* which is badly named but doesn't actually talk to the scheduler.
16:47:50 adreznec markus_z: Part of that is an artifact of the releases repo not existing when we started, and part if it is that I haven't really seen non-official drivers using that process
16:48:39 adreznec markus_z: Not to say they can't, just haven't really seen a pattern for it
16:49:31 jaypipes bhagyashris: so, perhaps you are just confused by the fact that the "scheduler reporting client" doesn't actually talk to the scheduler :)
16:49:36 markus_z adreznec: You simply push a tagged commit to Gerrit in merge it, I assume?
16:49:44 markus_z s/in/and

Earlier   Later