| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-16 | |||
| 14:35:31 | cfriesen | what's the right channel for devstack questions? it seems to be installing the wrong version of packages for stable/queens | |
| 14:35:42 | mriedem | finucannot: leakypipes: https://review.openstack.org/#/c/553751/2 | |
| 14:35:53 | mriedem | cfriesen: -qa | |
| 14:36:05 | cfriesen | thx | |
| 14:36:28 | finucannot | mriedem: Good catch. I'll pull it out of the queue and rework | |
| 14:37:17 | finucannot | mriedem: Also, are you still using the 'tox -evenv' trick? Just install reno and save yourself a few minutes a week | |
| 14:37:36 | finucannot | ;pip install --user reno' if you don't want to pollute your system (I think) | |
| 14:37:48 | finucannot | *system Python install | |
| 14:37:54 | leakypipes | mriedem: sorry man, had no idea about that :( | |
| 14:37:55 | mriedem | i'll be damned if i'm going to change my reno creation workflow now | |
| 14:38:02 | finucannot | :D fair | |
| 14:39:12 | superdan | mriedem: ah yeah, true.. first thing it does is unqueue itself effectively.. makes sense | |
| 14:39:50 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Follow the new PTI for document build https://review.openstack.org/553751 | |
| 14:39:52 | finucannot | mriedem: as requested | |
| 14:41:27 | mriedem | finucannot: that's not using upper-constraints | |
| 14:41:30 | mriedem | see https://review.openstack.org/#/c/532971/1/tox.ini | |
| 14:41:43 | finucannot | mriedem: Neither is the standard [testenv] target | |
| 14:41:45 | finucannot | which I copied | |
| 14:42:03 | finucannot | Did I miss something? | |
| 14:42:24 | mriedem | the install_command does... | |
| 14:42:26 | mriedem | hmm | |
| 14:42:27 | finucannot | Yeah, we hack 'install_command' to do that | |
| 14:42:47 | mriedem | ok that's different from novaclient, but you're still missing runtime deps | |
| 14:42:58 | mriedem | venv is just a place to do whatever, so it should have all requs | |
| 14:42:59 | mriedem | *reqs | |
| 14:43:12 | finucannot | They weren't there before though | |
| 14:44:03 | finucannot | If '[testenv:venv] deps' wasn't defined, it would defer to '[testenv] deps' https://github.com/openstack/nova/blob/master/tox.ini#L20 | |
| 14:44:09 | mriedem | right, hmm | |
| 14:44:22 | openstackgerrit | Merged openstack/nova master: docs: Disable smartquotes https://review.openstack.org/553730 | |
| 14:44:22 | finucannot | mriedem: We use 'usedevelop' | |
| 14:44:36 | finucannot | which would install the package and all its runtime dependencies | |
| 14:44:39 | finucannot | so we're good there | |
| 14:44:48 | mriedem | ok, +2 | |
| 14:44:57 | finucannot | (y) | |
| 14:45:31 | mriedem | leakypipes: can you put a procedural -2 on https://review.openstack.org/#/c/553597/ until the spec is approved? | |
| 14:49:56 | leakypipes | mriedem: -W'd it. | |
| 14:50:24 | leakypipes | mriedem: that was mostly me just experimenting in code to see what will work best for the mirroring. basically using it to inform the spec... | |
| 14:50:31 | leakypipes | mriedem: working on the spec changes now. | |
| 14:50:33 | mriedem | yeah i understand | |
| 14:59:32 | cdent | mriedem: you recall how you imported oslo_service to get a single log_options config thing: https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/wsgi.py#L60 ? | |
| 14:59:54 | cdent | how horribly dirty is it to use a local config opt (that duplicates the oslo_service one) instead? | |
| 15:01:38 | lyaaaaaaaaaaaaar | mnaser: https://review.openstack.org/#/q/topic:bug/1744361+status:open - btw the stable changes still reference different change-id's , happy to resubmit these if you don't have time. | |
| 15:04:46 | mriedem | cdent: given i can't figure out how to add a hook into oslo.service for that, it's probably not the worst thing in the world | |
| 15:05:01 | mnaser | lyaaaaaaaaaaaaar: appreciate if you do, I’m out of the office and running around with a bunch of stuff | |
| 15:05:10 | mriedem | i think at one point when doing that i asked in the -oslo channel if i should even be doing this, i.e. piggyback on their option, and got no response | |
| 15:05:20 | lyaaaaaaaaaaaaar | mnaser: np, happy to help | |
| 15:05:42 | cdent | mriedem: in nova it's not a big deal since oslo_service is already there, but in placement it sets off a cascade of imports and requirments that is sad making. | |
| 15:06:25 | mriedem | only thing i'm not sure about is how to signal a config option change here, | |
| 15:06:29 | mriedem | because the old option isn't deprecated, | |
| 15:06:31 | mriedem | only our usage of it, | |
| 15:06:39 | mriedem | so i guess we could just log something on startup if/when it's used | |
| 15:06:48 | mriedem | to say, 'move to this other nova-specific option' | |
| 15:07:17 | mnaser | lyaaaaaaaaaaaaar: thank you very much | |
| 15:07:57 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: Revert "Refine waiting for vif plug events during _hard_reboot" https://review.openstack.org/553817 | |
| 15:08:45 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/pike: Revert "Refine waiting for vif plug events during _hard_reboot" https://review.openstack.org/553818 | |
| 15:09:07 | cdent | mriedem: I'm not sure I'm following? The option (in the config file) stays the same. What will be different is how the process has the code which makes the conf option legit and validates its value? | |
| 15:09:44 | mriedem | cdent: i don't think you can (should) re-define an option in nova.conf that is already in oslo.service, | |
| 15:09:51 | mriedem | because the oslo.service options are imported into nova.conf | |
| 15:09:56 | mriedem | s/imported/registered/ | |
| 15:10:13 | johnthetubaguy | superdan: mriedem: do we need the placeholder migrations for queens now? | |
| 15:10:16 | cdent | right, but in placement itself there is no import of oslo_service | |
| 15:10:35 | mriedem | cdent: i understand, but placement is still in nova | |
| 15:10:42 | mriedem | and it's using nova's config | |
| 15:10:43 | mriedem | so.. | |
| 15:10:52 | cdent | so I'm wondering about a sort of hack in placement that says "this is a stub for a thing that is normall in olso_service, but since it's in default it's okay" | |
| 15:11:03 | cdent | sure, but it is an indepedent process, so it doesn't really care, does it? | |
| 15:11:22 | mriedem | i defer to melwitt | |
| 15:11:40 | cdent | it's not a big deal, it just seems wasteful to import oslo_service | |
| 15:11:49 | mriedem | and i'm saying you don't have to, | |
| 15:11:53 | mriedem | if we define our own option | |
| 15:12:06 | mriedem | which is what placement would have to do anyway once it's split out | |
| 15:12:09 | mriedem | to keep using this | |
| 15:12:21 | cdent | maybe we are talking about the same thing | |
| 15:12:45 | cdent | when you say "define our own option" do you mean "an option with a different name" or "an option with the same name but defined elsewhere"? | |
| 15:12:57 | jgwentworth | Roamer`: I think you should send email to the dev mailing list with tag [nova] to ask about the possibility of the storpool imagebackend | |
| 15:13:25 | mriedem | different name (or group) | |
| 15:14:09 | cdent | huh, okay. That suggests to me that 'log_options' (which is mighty generic) is in the wrong package, but I guess we're stuck. | |
| 15:15:57 | mriedem | idk, [api]/log_option | |
| 15:16:03 | mriedem | *log_options? | |
| 15:16:23 | mriedem | [DEFAULT]/log_config | |
| 15:17:05 | Roamer` | jgwentworth, thanks, will do | |
| 15:18:00 | cdent | 'log_options' seems like a thing that plenty of process, not just ones using oslo_service might like to do and configure, if they use oslo_config. but s'okay. | |
| 15:18:37 | mriedem | johnthetubaguy: i think that's taken care of before the release | |
| 15:19:22 | mriedem | johnthetubaguy: although i don't see them | |
| 15:19:32 | johnthetubaguy | mriedem: but I don't see them in here: https://github.com/openstack/nova/tree/master/nova/db/sqlalchemy/migrate_repo/versions | |
| 15:19:43 | cdent | fried_rice: https://blueprints.launchpad.net/nova/+spec/placement-extract | |
| 15:19:50 | mriedem | johnthetubaguy: nor do i | |
| 15:19:55 | mriedem | johnthetubaguy: i think there is a script to generate them | |
| 15:20:09 | fried_rice | cdent: Cool mon, thanks. | |
| 15:20:41 | johnthetubaguy | mriedem: I think it has to be post release, so they are missing in stable, but present in master? it always confuses me | |
| 15:20:53 | mriedem | yeah in case you backport a db migration, | |
| 15:21:08 | mriedem | it then takes the placeholder spot in master | |
| 15:21:37 | fried_rice | cdent: I guess you'll be going through and tagging all your patches accordingly? | |
| 15:21:47 | fried_rice | I commented on https://review.openstack.org/#/c/553149/ | |
| 15:22:05 | cdent | fried_rice: if that's what you really want | |
| 15:22:52 | mriedem | johnthetubaguy: yikes https://review.openstack.org/#/q/file:%255Enova/db/sqlalchemy/api_migrations/migrate_repo/versions.*+status:open | |
| 15:23:16 | mriedem | https://review.openstack.org/#/q/file:%255Enova/db/sqlalchemy/migrate_repo/versions.*+status:open | |
| 15:23:27 | fried_rice | cdent: Do you feel as though that's pointless unnecessary busywork? Me, I'd like to be able to search on the topic and get the list of all the patches associated with the effort. And having the LP bot collate them in the bp whiteboard, also useful. | |
| 15:23:59 | fried_rice | cdent: I can do it if you like. Shouldn't be a big effort, eh? | |
| 15:24:20 | superdan | johnthetubaguy: oh yeah I think we do, hopefully we haven't merged any yet? | |