Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-19
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
16:50:31 adreznec Yep, we have our own releases team defined for the projects and handle branch creation and tag commit pushing through that ACL
16:51:06 markus_z adreznec: I see. Any major drawback with that approach?
16:52:11 adreznec markus_z: Not really that we've noticed, other than that the release cycle is completely self-enforced.
16:54:08 markus_z adreznec: yeah, sounds good enough IMO. I'll double-check with the release mgmt team though. Thanks!
16:54:27 adreznec markus_z: Ok, I'd be curious to see what feedback you get from them
16:54:44 markus_z adreznec: yep, will keep you in the loop
17:04:30 openstackgerrit Wang Qing wu proposed openstack/nova: WIP(5): Introduce base PowerVM driver (ovs vif) https://review.openstack.org/422512
17:21:26 mnestratov hi all
17:23:34 mnestratov any chances to have some cores' eyes on https://review.openstack.org/#/c/312488/ and maybe get it merged before freeze?
17:29:57 bauzas mriedem: jaypipes: FWIW, I'll need to disappear a bit tonight because of a meetup so I could miss the nova meeting
17:30:49 bauzas mriedem: my two concerns are #1 the critical bug, but the success path is found
17:31:10 bauzas mriedem: #2 the placement upcall, but the ML thread is open with my reply, so I'd love thoughts on that
17:31:20 jaypipes bauzas: just finishing up response to the ML thread.
17:32:06 bauzas jaypipes: I really need to disappear in like 2 mins, but I'll check my emails
17:34:29 jaypipes bauzas: response sent (to mwhahaha not your reply)
17:34:47 mwhahaha jaypipes: i shall read and flame appropriately :)
17:34:59 jaypipes mwhahaha: I would expect nothing less :)
17:39:16 bauzas jaypipes: roger
17:39:30 bauzas jaypipes: I made two proposals, I'd love to see your thoughts
17:40:24 bauzas jaypipes: nevermind, saw your reply
17:40:26 jaypipes bauzas: k. if you could look at https://review.openstack.org/#/c/398473/ later, would be great.
17:40:55 bauzas jaypipes: oh that one is absolutely gorgeous
17:41:06 jaypipes lol
17:41:06 bauzas I'll try to look at it when I have time
17:41:39 bauzas jaypipes: I'm a serious lover of your RT cleanup series
17:41:55 openstackgerrit Jay Pipes proposed openstack/nova: placement: create aggregate map in report client https://review.openstack.org/407309
17:42:02 openstackgerrit Roman Dobosz proposed openstack/nova: Prevent compute crash on discovery failure https://review.openstack.org/422780
17:42:02 jaypipes bauzas: cool, thx :)
17:42:25 bauzas I just need to teleport now, see you folks
17:57:13 dims sean-k-mooney : jaypipes : gah! nova/nova/network/linux_net.py has diverged from os-vif/vif_plug_linux_bridge/iptables.py the os-vif one does not have any tests and is outdated :(
17:58:18 jaypipes dims: yeah, an unfortunate side effect of not having an oslo.netutils library :(
17:58:35 sean-k-mooney dims: is there a bug for that against os-vif
17:58:36 dims :)
17:59:00 sean-k-mooney also alot of the nova/virt/libvirt/vif.py is not tested ...
17:59:01 dims i just spotted it when i tried to use linuxbridge in a py35 job sean-k-mooney (http://logs.openstack.org/09/421209/16/experimental/gate-tempest-dsvm-nova-py35-ubuntu-xenial/15a4fc7/logs/screen-n-cpu.txt.gz?level=ERROR)
18:00:09 dims so back to devstack defaults now
18:00:53 sean-k-mooney dims: so is linux bridge not deployable currently?
18:01:04 dims not on py35

Earlier   Later