Earlier  
Posted Nick Remark
#openstack-nova - 2019-06-13
15:52:49 mriedem since those are big
15:52:50 stephenfin see line 810 in there
15:53:16 stephenfin I know, but I imagine people can guess it's not a full response
15:53:23 stephenfin as with 810, 829, etc.
15:54:06 mriedem ffs zuul restart
15:56:52 openstackgerrit Harald Jensås proposed openstack/nova master: cell_mapping - wrap IPv6 address in format_url https://review.opendev.org/664559
15:56:59 openstackgerrit Lee Yarwood proposed openstack/nova stable/stein: libvirt: Use SATA bus for cdrom devices when using Q35 machine type https://review.opendev.org/663677
15:57:21 mriedem lyarwood: why did you need to rebase ^?
15:57:26 mriedem oh i see
15:58:31 lyarwood mriedem: yeeeeeeah, I didn't notice the zuul restart, I wonder if that's going to get picked up.
15:58:44 openstackgerrit Matt Riedemann proposed openstack/nova master: Api-guide: Add Block Device Mapping https://review.opendev.org/522084
15:58:46 mriedem stephenfin: done
15:59:03 mriedem lyarwood: yeah idk, was just rechecking a bunch of other things too
15:59:30 lyarwood ah, so that change was picked up
15:59:41 stephenfin mriedem: +2. Happy for you to +W or I can
15:59:49 stephenfin thanks :)
16:01:03 mriedem i got it
16:03:57 mriedem looks like all my rechecks were dropped
16:03:59 mriedem weeeee
16:19:37 sean-k-mooney artom: i noticed you updated your numa migration stuff yesterday
16:20:07 sean-k-mooney artom: have you more changes pending or shoudl i plan to review it/test it next week
16:20:42 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Rename 'configuration drive' to 'config drive' https://review.opendev.org/641723
16:20:42 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Rework all things metadata'y https://review.opendev.org/640730
16:21:39 stephenfin efried: Think I asked you this before, but what's the chances of getting https://review.opendev.org/640730 blindly approved?
16:21:40 stephenfin It's docs only and I think it's a huge improvement, but I've no idea how to break it up more than I have without rewriting the whole darn thing
16:22:21 mriedem stephenfin: maybe ask dansmith to review it again first :)
16:22:35 stephenfin I think I've done that a few times too :(
16:22:37 mriedem since he did the most thorough review
16:23:07 dansmith stephenfin: done what a few times?
16:23:26 stephenfin dansmith: Have a look at that ridiculously big metadata doc rework patch of mine
16:23:33 stephenfin (https://review.opendev.org/640730)
16:23:43 artom sean-k-mooney, just a rebase for now, bottomg patch is WIP
16:23:57 artom To indicate that the whole series isn't ready yet
16:24:25 dansmith stephenfin: just wanted to make sure you weren't implying you had asked me to revisit a few times
16:24:31 sean-k-mooney artom: ok so saving the updated xml after the migration is still pending
16:24:56 sean-k-mooney artom: that was the main thing that needed to be fixed and the rest is cleanup right
16:26:58 stephenfin I think I may have and I get why you haven't, if so. Not intending to point fingers at all though. I'd just like to be done with it
16:28:16 artom sean-k-mooney, the XML is fine, IIRC, it's the database numa_topology that wasn't saved
16:28:46 dansmith stephenfin: point being, I'm quite sure I didn't hear anything after that review, but I'm looking at it right now
16:28:54 sean-k-mooney artom: maybe i just recall we didnt save somthing
16:29:18 stephenfin dansmith: Ah, sorry. That's my mistake so
16:29:23 stephenfin And thank you
16:36:22 dansmith mriedem: for the tenth and last time, can you hit this? https://review.opendev.org/#/c/640730/7
16:36:33 sean-k-mooney stephenfin: i personlay prefer the ... then assuming people will guess its not a full respocne but its proably fine eitehr way
16:36:57 stephenfin sean-k-mooney: Too late. mriedem already did the deed
16:37:00 stephenfin mwahaha
16:37:03 sean-k-mooney stephenfin: that was regarding mriedem change but he has updated it already
16:37:06 sean-k-mooney yep i know
16:37:18 stephenfin No take backsies
16:37:23 mriedem dansmith: lucky for y'all i just got a fresh pack of red markers
16:37:42 sean-k-mooney stephenfin: damn i have not heard that in a while
16:43:54 efried stephenfin: looking now.
16:46:01 aspiers efried: oslo.log guidelines feedback addressed, when you are looking for some light relief
16:46:29 efried ack
17:18:39 openstackgerrit melanie witt proposed openstack/nova master: Warn for duplicate host mappings during discover_hosts https://review.opendev.org/651947
17:19:14 melwitt dansmith: ^ updated
17:21:53 dansmith gdi
17:22:51 melwitt what
17:23:09 dansmith you're supposed to wait a month between all updates
17:23:29 melwitt :)
17:24:41 efried stephenfin: I'm going to wait until that sucker renders so I can at least feel I've done due diligence on the links and stuff.
17:30:10 melwitt \o\
17:50:47 artom mriedem, so https://review.opendev.org/#/c/522106/ can be abandoned
17:53:03 mriedem artom: not really
17:53:08 mriedem https://review.opendev.org/#/c/581410/ isn't really describing scheduler hints in detail,
17:53:18 mriedem it's just describing scheduler hints vs flavor extra specs
17:53:25 mriedem which is more of an admin/operator thing than end user
17:53:54 artom mriedem, are we reading the same first paragraph of https://docs.openstack.org/nova/latest/reference/scheduler-hints-vs-flavor-extra-specs.html#scheduler-hints?
17:53:59 mriedem i agree the in-tree hints are described now in the api-ref
17:54:15 mriedem artom: i wrote https://docs.openstack.org/nova/latest/reference/scheduler-hints-vs-flavor-extra-specs.html#scheduler-hints?
17:54:39 artom mriedem, I know - it's almost word for word as what's in https://review.opendev.org/#/c/522106/8/api-guide/source/server_concepts.rst, no?
17:55:12 artom OK, maybe not word for word
17:55:44 mriedem i think the api-guide would benefit from (1) a short description of what are scheduler hints, (2) an example api request, and then (3) links to the thing above (hints vs extra specs) and the server create api reference for the description of the available in-tree hints
17:56:02 mriedem our api-ref doesn't have a sample with a scheduler hint in
17:56:04 mriedem *it
17:56:13 mriedem so every time i write a test that uses one, i have to look this up
17:56:51 mriedem b/c 1. there are 2 param names accepted for hints and 2. it's at the top level of the request rather than within the server object
17:57:30 openstackgerrit Merged openstack/os-vif master: set ignore_basepython_conflict = True in tox.ini https://review.opendev.org/665034
17:57:37 artom Well, I signed up for this, might as well finish it
17:57:47 artom mriedem, same patch? Smells like a new change
17:58:59 artom Can I achieve peak arrogance by trading you reviews on https://review.opendev.org/#/c/644881/?
17:59:30 artom I guess same change to preserve review history
18:01:03 mriedem i would do the same patch for review history yes
18:01:10 mriedem add yourself as co-author
18:01:19 mriedem and because you asked for https://review.opendev.org/#/c/644881/ yet again i'm going to say i'll never review it again now
18:01:21 mriedem you're welcome
18:02:47 openstackgerrit sean mooney proposed openstack/os-vif stable/stein: set ignore_basepython_conflict = True in tox.ini https://review.opendev.org/665195
18:07:20 openstackgerrit sean mooney proposed openstack/os-vif stable/stein: Fix mock of built in "open" function in unit tests https://review.opendev.org/665196
18:08:15 mriedem artom: before you raise HR alarms downstream, i was joking
18:08:27 melwitt mriedem: this is a bit old and has a +2 from dansmith now, you're probably the best person to review since it's about nova-manage cells stuff https://review.opendev.org/651947
18:08:57 artom mriedem, you haven't touched me inappropriately (yet?), so no HR alarms
18:09:01 artom ;)
18:09:29 mriedem dansmith: you know how we have this warning about stopping nova-compute before deleting it? https://developer.openstack.org/api-ref/compute/?expanded=delete-compute-service-detail#delete-compute-service otherwise dragons? it strikes me now that the delete compute service API should just be checking if the service is up and if so, fail the request with a 409
18:10:06 sean-k-mooney artom: a +1 from zuul, how did you apise the ci gods to make that happen
18:10:15 dansmith mriedem: maybe, unless there's a reason to delete and have it recreate or something
18:10:23 artom sean-k-mooney, which patch?
18:10:35 dansmith mriedem: the other thing would be that unless you also force down, you can't stop and delete inside of a minute or whatever the service timeout is
18:11:01 sean-k-mooney artom: you have more then one with a +1 :P the hybrid_plug events one
18:11:04 mriedem yeah you'd have to force down
18:11:30 mriedem dansmith: the problem with the recreate is the new provider it will create in placement with no allocations for the instances on that host, which will f up scheduling

Earlier   Later