| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-19 | |||
| 15:21:39 | edleafe | :) | |
| 15:21:58 | bauzas | honestly, I don't want to go that way | |
| 15:22:07 | bauzas | we already claim to support N-1 services | |
| 15:22:13 | mriedem | "we can't expect them to package and manage a totally separate service right now" ? | |
| 15:22:15 | mriedem | really? | |
| 15:22:21 | bauzas | so we should support the placement service being n-1 | |
| 15:22:39 | mriedem | placement has been available since newton, it's already out there for the packaging before upgrading to ocata, | |
| 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 | 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 | |