Earlier  
Posted Nick Remark
#openstack-nova - 2017-08-28
13:18:43 openstackgerrit Merged openstack/os-traits master: doc: Switch from oslosphinx to openstackdocstheme https://review.openstack.org/479869
13:19:20 openstackgerrit Merged openstack/nova master: Refactor libvirt.utils.execute() away. https://review.openstack.org/489816
13:25:36 openstackgerrit Merged openstack/os-traits master: doc: Remove cruft from conf.py https://review.openstack.org/480090
13:26:20 sdague efried: looking
13:27:13 sdague efried: done
13:27:18 efried sdague Thanks!
13:30:08 openstackgerrit Eric Fried proposed openstack/nova master: Update PCI passthrough doc for moved options https://review.openstack.org/498461
13:30:47 edleafe Scheduler subteam meeting in 30 minutes in #openstack-meeting-alt
13:30:49 efried stephenfin ^ split out from https://review.openstack.org/#/c/493701/ as requested, and filed against a bug (https://bugs.launchpad.net/nova/+bug/1713502)
13:30:50 openstack Launchpad bug 1713502 in OpenStack Compute (nova) "PCI passthrough documentation needs updating since options moved to [pci] section" [Undecided,In progress] - Assigned to Eric Fried (efried)
13:31:18 efried Not sure who can answer whether that should be backported to at least pike
13:31:28 efried (Backport to ocata would be a non-cherry-pick, cause docs all moved)
13:32:28 stephenfin efried: Yeah, iirc they didn't version the configuration guide so there's nothing to backport to for Ocata
13:32:49 efried okay. The deprecated options still work, so it's not crucial.
13:33:04 stephenfin I think doc patches should go back to Pike though. Maybe sdague would have some thoughts on the matter?
13:33:11 stephenfin Oh, so it would actually
13:33:52 sdague stephenfin: which doc patches?
13:34:03 stephenfin sdague: https://review.openstack.org/#/c/498461/1
13:34:17 openstackgerrit Eric Fried proposed openstack/nova master: [Trivial] docstrings, typos, minor refactoring https://review.openstack.org/493701
13:34:47 efried stephenfin Rebased ^ on top
13:35:09 sdague yeh, admin guide stuff should go back as it's all published per release
13:35:38 stephenfin efried: Odd. I expected the +2 to disappear. Apparently not
13:36:15 efried stephenfin When gerrit recognizes an auto rebase, it carries code reviews forward.
13:36:23 efried Which is *almost* always okay :)
13:38:49 efried stephenfin sdague https://review.openstack.org/#/c/498463/ is the pike cherry-pick. So should I go make the change in ocata too?
13:40:06 sdague efried: no, the admin guide is not in ocata
13:40:20 efried sdague Okay, that's why I can't find it :)
13:40:24 sdague yep
13:40:26 efried That doc must have existed somewhere?
13:40:30 efried Just in spec form mebbe?
13:40:34 sdague on the openstack manuals side
13:41:07 sdague only in pike did the manuals go in tree for nova
13:42:12 efried sdague Right; so my question is whether I should go find and update that manual wherever it lived in ocata
13:44:15 stephenfin efried: I don't think they versioned the admin guide either, so there's nothing to backport to for Ocata
13:44:26 sdague yeh, I'm not sure I would bother
13:44:30 efried cool cool.
13:58:47 mriedem gmann: i'm not sure https://review.openstack.org/#/c/490722/ warrants a microversion bump
13:58:56 mriedem should probably be discussed in the nova-api meeting this week
14:00:01 cdent mriedem: i rebased your shared providers functional test again. same deal as last time: leaving the failing tests with TODOs. I did make a couple of tweaks to report client in the patch above it to get a few more things passing
14:01:53 mriedem cdent: that was pretty incomplete from what i remember
14:02:11 mriedem i know i need to abandon the wip for the fixes in the report client
14:02:26 cdent It was but there were a couple of simple syntax thingies that move it forward a bit
14:21:56 sdague mriedem: https://review.openstack.org/#/c/496515 is probably worthy of backport
14:22:31 sdague I push for pike, what do you think about ocata as well?
14:23:27 kashyap sdague: Randomly chiming in, it sounds like backport-worthy, given the description
14:24:20 mriedem seems pretty low probability
14:24:46 mriedem wouldn't this be someone creating 2 instances with the same name on separate requests ~the same time?
14:24:56 sdague mriedem: no
14:25:11 sdague there is no name uniqueness requirement
14:25:24 sdague or, it's behind a config option, off by default
14:25:41 sdague so, it is 2 different requests, but they can be at any time
14:26:26 mriedem as long as you didn't delete the other first?
14:26:58 sdague yes
14:27:05 sdague but it could be made by a different tenant
14:27:43 mriedem this is fine to backport. it's unfortunate that a 2 line code fix requires 100+ LOC change for tests
14:27:57 sdague well, they tried to be comprehensive there
14:27:58 mriedem i assume that's just because of how tightly coupled this all ways to the driver when it was moved out of the driver and into the host module
14:28:01 sdague yeh
14:28:24 kashyap Yeah, the tests seem to be trying to be a bit more comprehensive
14:28:40 sdague mriedem: before I approve this change of yours, you want to put in newlines to the output for readability - https://review.openstack.org/#/c/486660 ?
14:34:23 openstackgerrit Alex Szarka proposed openstack/nova master: Reduce code complexity - instance.py https://review.openstack.org/359878
14:41:14 openstackgerrit Elod Illes proposed openstack/nova master: Functional test: evacuate with no compute https://review.openstack.org/498482
14:47:21 mriedem sdague: it's going to be a bit
14:49:56 mriedem sdague: please redo those cherry picks using the -x option
14:59:41 openstackgerrit Artom Lifshitz proposed openstack/nova-specs master: SPICE native client support https://review.openstack.org/442040
15:00:55 dansmith cdent: it's still totes possible and should be on the radar for sure, but we've got a giant mess at the moment, and a bunch of unfinished bits that are way higher priority, IMHO
15:00:56 mriedem cdent: i don't really see any reason why placement couldn't be split out, we're doing everything over the microversions onw
15:00:57 mriedem *now
15:01:21 mriedem right, was going to say, the only thing/reason to not focus on the split right now is the existing amount of stuff we have to do
15:01:36 dansmith especially since it's its own catalog entry, I don't think it's noticeably a nova thing to any other project other than where the code lives
15:01:46 dansmith yeah
15:02:15 edleafe dansmith: one concern was the choice to shove everything in resource_providers.py
15:02:21 edleafe until the split
15:02:40 cdent dansmith: yeah, your response points to a more detailed question: if those unfinished things are going to take a while and starting on moving things will disrupt them, there’s little point to start the extraction process soonish
15:02:41 mriedem was that a conscious choice?
15:03:03 dansmith I'm not sure what the single file has to do with anything,
15:03:13 dansmith and I've complained along the way that that file is too fat already
15:03:23 mriedem if you want to create nova/objects/alternative_hosts.py that's fine
15:03:28 dansmith if splitting things out of there is helpful, then
15:03:30 dansmith right
15:04:02 edleafe mriedem: yes, because having placement in Nova was always supposed to be a temporary thing, and single file would make separation easier
15:04:29 openstackgerrit Elod Illes proposed openstack/nova master: Functional test: cold migrate to compute down https://review.openstack.org/496280
15:05:44 mriedem i don't see how it makes it really any easier
15:06:12 mriedem like, if we have 1 objects module or 10, that's not going to be the pain in the split
15:06:14 cdent assuming it is contained (down collabortion without adding up collaboration)
15:06:21 edleafe mriedem: I think the idea was it would keep us from scattering placement code throughout nova
15:06:29 cdent jinxish
15:06:29 mriedem sure that's fair
15:06:42 mriedem but that's not going to be the painful part
15:06:47 dansmith not at all
15:06:59 mriedem i imagine the db will be the hardest
15:07:01 cdent collabortion is my neologism of the day. I’ll have to figure out what it means.
15:07:20 edleafe mriedem: sure, it's just not adding to that pain
15:07:21 cdent db doesn’t have to be hardest.
15:07:25 cfriesen_ it's when you have too many people working on something and they mess it up. :)
15:07:36 cdent a) we have code for it already, b) we don’t need to use a different db
15:07:56 mriedem cdent: you don't think at some point people will want to use a placement db without the nova_api db schema?
15:08:00 mriedem like build_requests and instance_mappings?
15:08:03 cdent cfriesen_: works, thanks!
15:08:22 mriedem and have a placement user that can access that db rather than the nova user?

Earlier   Later