Earlier  
Posted Nick Remark
#openstack-nova - 2018-01-02
21:45:06 mnaser 2x 32c was ok
21:46:10 mnaser thanks jaypipes and everyone else for the input
21:47:36 cdent mnaser, while you're hear can you clarify something for me. above you said "might be a bit difficult considering the volume of traffic at the placement api". What did you mean by that? How is/was the traffic at the api impacting your ability to make requests of it, in this case?
21:47:44 cdent sigh: s/hear/here/
21:48:09 mnaser cdent: oh, i was doing some testing on a host aggregate on our public cloud, so the volume of traffic hitting the placement api is pretty significant
21:48:24 mnaser from compute nodes reporting inventory to VMs getting booted its pretty busy and gets churned a lot
21:49:26 cdent Okay, my suggestion was, effectively, to construst the query that the scheduler was doing, yourself, so you could isolate the "no candidates returned" problem, without having to boot anything
21:50:19 mnaser cdent: yeah, i have to admit the placement api is still one of the things that i'm not as comfortable with as the rest of nova.. but this little experience added a bunch of stuff to my 'toolkit'
21:50:38 cdent I'm the opposite :)
21:52:19 mnaser :D
22:24:16 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova master: Change 'InstancePCIRequest' spec field https://review.openstack.org/449257
22:24:17 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova master: Format NIC features using os-traits definitions https://review.openstack.org/466051
22:24:17 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova master: Add Neutron port capabilities to devspec in request https://review.openstack.org/451777
22:28:07 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova master: Read Neutron port 'binding_profile' during boot https://review.openstack.org/507481
22:36:02 eandersson Is services versions supposed to be upgraded when you upgrade the version of Openstack?
23:35:20 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM driver: ovs vif https://review.openstack.org/422512
23:45:39 openstackgerrit Matt Riedemann proposed openstack/nova master: Add multi-cell negative test for cold migration with target host https://review.openstack.org/524027
23:45:39 openstackgerrit Matt Riedemann proposed openstack/nova master: Workaround CellDatabase fixture limitation when creating computes https://review.openstack.org/524264
#openstack-nova - 2018-01-03
01:11:11 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM driver: ovs vif https://review.openstack.org/422512
01:25:51 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: SEA https://review.openstack.org/523216
01:47:12 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Use neutron port_list when filtering instance by ip https://review.openstack.org/525505
02:02:25 openstackgerrit Chen Hanxiao proposed openstack/nova master: manager: more detailed info of unsupported compute driver https://review.openstack.org/530701
02:07:12 openstackgerrit Wangpan proposed openstack/nova master: Handle glance exception during rotating instance backup https://review.openstack.org/523395
06:21:26 openstackgerrit ChangBo Guo(gcb) proposed openstack/nova master: Use method validate_integer from oslo.utils https://review.openstack.org/528620
07:01:14 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: SEA https://review.openstack.org/523216
07:55:08 Roamer` johnthetubaguy, when you get back, could you please take a look at https://review.openstack.org/140733/ - is there a chance that you might remove your procedural -2 from a previous release cycle and possibly consider the almost trivial StorPool Nova volume attachment driver for inclusion in Queens? Thanks a lot in advance! Right now, with our Cinder and os-brick drivers merged, it's a bit weird -
07:55:14 Roamer` the main use case for the Cinder driver still requires manual patching :)
09:08:08 openstackgerrit Merged openstack/nova master: Deprecate API extensions policies https://review.openstack.org/526258
09:11:52 stephenfin mdbooth: Done
09:32:59 openstackgerrit Rajesh Tailor proposed openstack/nova master: Allow force-delete even if task_state is not None https://review.openstack.org/530879
10:05:11 mdbooth stephenfin: Thanks
10:34:19 ralonsoh_ stephenfin: hello, about https://review.openstack.org/#/c/449257/52/nova/pci/request.py
10:34:30 stephenfin ralonsoh_: Shoot
10:34:50 ralonsoh_ stephenfin: if I accept this suggestion, I need to refactor the whole patch
10:35:11 ralonsoh_ stephenfin: the scope of this feature is to store a list of strings in spec
10:35:25 stephenfin ralonsoh_: Yup, afraid so :( I realize
10:35:44 ralonsoh_ stephenfin: not to modify how InstacePCIRequestSpec was storing the other parameters
10:35:44 stephenfin I realize that, but as soon as we create the object that way, we're stuck with it
10:36:17 ralonsoh_ stephenfin: but "spec" was storing parameters in key=value fashion
10:36:52 stephenfin Right, but you're already modifying how the other parameters were stored
10:37:26 stephenfin Previously they were stored in a 'ListOfDictOfNullableStringsField'. Now they're stored in the 'InstancePCIRequestSpec' object
10:37:28 ralonsoh_ in a generic way. But there were no specific fields for those parameters (product, vendor, etc)
10:37:47 ralonsoh_ ok, I'll submit this modification next release
10:38:04 ralonsoh_ First, I'll submit again the spec
10:38:39 stephenfin ralonsoh_: I realize it's a good chunk of rework, but it just seems like a bad idea to not do this when we're already doing the work here
10:38:49 stephenfin I could help in the rework, but if I do then I can't review :/
10:39:02 stephenfin ralonsoh_: So that is your call
10:39:23 ralonsoh_ ok, I'll abandond the patch for now
10:39:30 openstackgerrit Lee Yarwood proposed openstack/nova stable/ocata: Don't persist could-be-stale InstanceGroup fields in RequestSpec https://review.openstack.org/528226
10:40:54 stephenfin ralonsoh_: I wouldn't, personally. Better to keep it as -W so we can see the reasoning when it's reworked
10:41:00 stephenfin But that's me
10:41:49 ralonsoh_ and then there will be another reason to refactor it again
10:43:56 stephenfin ralonsoh_: That hardly seems fair :( I'm not asking for nit-picky stuff here and I (hope) I've explained the rationale for the change as much as possible (plus offered to help where possible)
11:33:38 openstackgerrit Stephen Finucane proposed openstack/nova master: Add an online migration for PciDevice.uuid https://review.openstack.org/530905
11:33:38 openstackgerrit Stephen Finucane proposed openstack/nova master: Modify PciDevice.uuid generation code https://review.openstack.org/530487
13:02:25 openstackgerrit Silvan Kaiser proposed openstack/nova master: Added mount fstype based validation of Quobyte mounts https://review.openstack.org/522245
13:22:19 bhagyashris ianw_pto: Hi,
13:23:58 openstackgerrit Chen Hanxiao proposed openstack/nova master: manager: more detailed info of unsupported compute driver https://review.openstack.org/530701
13:50:59 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Use new-style choice values https://review.openstack.org/530924
13:50:59 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Move additional nova-net options https://review.openstack.org/530923
13:56:20 openstackgerrit Merged openstack/nova master: Add an online migration for BDM.uuid https://review.openstack.org/525599
14:33:15 jaypipes stephenfin: so is there something funky going on with zuul? I see a lot of -2V's around a dependent change failing to merge and then rechecks right after...
14:34:56 stephenfin jaypipes: I'd expect to see the -2s if a dependant, +W'd patch failed to merge. Those errors do seem more frequent than they should though
14:35:45 jaypipes well, I've noticed *you* recheck'ing a lot after those -2s (and before any other patches are merged/pushed/rebased for those series) which is why I was asking you what was up :)
14:36:31 stephenfin Aha. Nope, they're dumb rechecks. The failures are all timeouts and unrelated to the patches in question
14:44:10 ildikov mriedem: hi
14:44:21 mriedem hi
14:44:44 ildikov mriedem: just a quick note that stvnoyes is helping out with the tempest tests for multi-attach
14:45:07 mriedem i pushed up the tempest multiattach patch yesterday after a rebase, i basically had to start over
14:45:14 mriedem https://review.openstack.org/#/c/266605/
14:45:36 ildikov mriedem: yeah, I saw your ping this morning
14:46:41 ildikov mriedem: I pointed Steve to the patch yesterday, I didn't know you're planning to work on it
14:48:01 mriedem it still needs some additional test coverage, and needs to actually pass first
14:48:53 ildikov we can chat about it tomorrow on the meeting
14:49:05 ildikov I will try to catch Steve later today
14:50:25 openstackgerrit Stephen Finucane proposed openstack/nova master: Modify PciDevice.uuid generation code https://review.openstack.org/530487
14:50:26 openstackgerrit Stephen Finucane proposed openstack/nova master: Add an online migration for PciDevice.uuid https://review.openstack.org/530905
15:03:59 stephenfin jaypipes: Think this is something you could tackle before the end of the cycle? https://review.openstack.org/#/q/status:open+project:openstack/nova+topic:bp/websocket-proxy-to-host-security
15:04:39 jaypipes stephenfin: definitely not my area of expertise, but I will review just because you asked nicely.
15:04:48 stephenfin sdague had volunteered to take the blow at the PTG, but he's not about much these days. It's been about since...Kilo and would be good to finally close out
15:04:58 stephenfin jaypipes: Excellent. Appreciate it :)
15:06:44 openstackgerrit Matthew Booth proposed openstack/nova master: Add test for assignment of uuid to a deleted BDM https://review.openstack.org/530774
15:21:13 mriedem stephenfin: on that series, there is this devstack change https://review.openstack.org/#/c/396186/
15:21:23 mriedem stephenfin: is tempest already running a test to exercise any of this code?
15:21:39 mriedem i thought at one point danpb had a devstack-gate or project-config change to one of the jobs to enable this
15:22:02 mriedem this https://review.openstack.org/#/c/396289/
15:22:12 stephenfin If you're running under libvirt then some of it is exercised
15:22:53 stephenfin You're referring to this job, I imagine? https://review.openstack.org/#/c/396289/
15:23:15 mriedem i see melwitt moved that to a zuulv3 job definition within nova https://review.openstack.org/#/c/513160/4
15:23:33 mriedem however, the nova-next job is still in the openstack-zuul-jobs repo
15:24:09 stephenfin The stuff that's tested is the basic negotiation. The VeNCrypt scheme is untested without that job by melwitt
15:24:38 mriedem so, can we put some effort into getting the new stuff tested before landing the series?
15:24:39 stephenfin I had patches up to move that, I thought?
15:24:52 mriedem you had patches up to move like all jobs into the nova repo, or something close,
15:24:59 mriedem and i'd like to avoid doing a giant job migration right now
15:25:21 mriedem because, e.g. pike is blocked on the tempest-full job migration for master
15:25:53 mriedem so maybe we start with moving the nova-next job into the nova repo,
15:26:03 mriedem then tweak it on top with mel's change to flip the new bit in devstack
15:26:15 mriedem the NOVA_CONSOLE_PROXY_COMPUTE_TLS variable
15:26:33 mriedem would have been easier if https://review.openstack.org/#/c/513160/ was on the same topic branch as the rest of the series

Earlier   Later