| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-09 | |||
| 19:00:17 | EmilienM | we are having hard time in tripleo to understand when to run it (at the end of deployment I guess) but it's racy because we can't control the nova-compute registration | |
| 19:03:26 | EmilienM | dansmith: do you know how many time (roughly) would take a discover_hosts with ~100 hosts? | |
| 19:03:32 | mriedem | EmilienM: then enable the auto discovery in the scheduler | |
| 19:03:45 | openstackgerrit | Anusha Unnam proposed openstack/nova master: Disassociate floating ip when fixed ip is removed https://review.openstack.org/350299 | |
| 19:03:54 | dansmith | EmilienM: loading 100 rows from the database is pretty fast | |
| 19:04:14 | EmilienM | mriedem: it's not suggested by nova if I read the code | |
| 19:04:26 | mriedem | EmilienM: i think that means like CERN | |
| 19:04:40 | mriedem | 10's of thousands of hosts | |
| 19:04:43 | mriedem | but dansmith can correct me | |
| 19:05:02 | dansmith | mriedem: nah, fewer per cell | |
| 19:05:09 | dansmith | mriedem: a few hundred at most I think | |
| 19:05:12 | mriedem | oh right | |
| 19:05:18 | EmilienM | mriedem: https://github.com/openstack/nova/blob/master/nova/conf/scheduler.py#L138-L143 | |
| 19:05:19 | dansmith | which at host add time is.. not a problem | |
| 19:05:52 | mriedem | i'd think 100 hosts per cell is small enough | |
| 19:06:00 | mriedem | but i assume there is also some hedging in there | |
| 19:06:03 | mriedem | given it came in late | |
| 19:06:09 | EmilienM | dansmith: would it be acceptable in TripleO / Director to use discover_hosts_in_cells_interval ? | |
| 19:06:24 | EmilienM | you can say no, but I need to find another way to run this command after all computes are run then | |
| 19:06:36 | dansmith | EmilienM: I think you'll just race with it, and I don't understand why you can't run this after everything is setup | |
| 19:07:06 | mriedem | tripleo doesn't have some kind of post-deploy hook? | |
| 19:07:13 | EmilienM | dansmith: because nova-compute start at step 5 (last step) | |
| 19:07:20 | mriedem | so add a step 6? | |
| 19:07:34 | EmilienM | that's an option but it adds runtime in deployment | |
| 19:08:28 | EmilienM | mriedem: we have post-deploy | |
| 19:08:40 | EmilienM | mriedem: we're currently investigating if it fits in there | |
| 19:16:14 | cfriesen | does nova handle modifying extra-specs on flavors that are currently in-use by instances? If so, is there any way to retrieve the flavor extra specs that were actually used to boot a given instance? | |
| 19:25:14 | mriedem | cfriesen: the flavor, along with it's extra specs, are stored with the instance after it's created | |
| 19:25:19 | mriedem | in the instance_extra table | |
| 19:25:28 | mriedem | so you can delete the original flavor and still resize/migrate the instance | |
| 19:26:06 | mriedem | cfriesen: as for the 2nd part of your question, i think you can pull deleted flavors if you're an admin | |
| 19:26:31 | mriedem | i.e. i think you get the flavor id via the server GET, and then can GET /flavors/id | |
| 19:26:36 | mriedem | which will read deleted flavors | |
| 19:26:55 | mriedem | but you have to be admin to read deleted flavors | |
| 19:28:15 | cfriesen | mriedem: if I boot an instance with a flavor, then admin changes extra specs on that flavor, is there any way for me to dump the extra-specs that were used when I booted the instance? | |
| 19:29:10 | mriedem | cfriesen: not via the REST API i don't think so | |
| 19:29:16 | mriedem | we had a spec proposed in mitaka for this... | |
| 19:29:18 | mriedem | i'll dig it up | |
| 19:29:21 | openstackgerrit | Dan Smith proposed openstack/nova master: Remove main_db flavor compatibility https://review.openstack.org/431722 | |
| 19:29:51 | mriedem | cfriesen: https://review.openstack.org/#/c/265282/ | |
| 19:30:05 | mriedem | basically i think the idea was, add GET /servers/<server_id>/flavor | |
| 19:30:37 | mriedem | cfriesen: mayhap you want to dust that off for pike | |
| 19:31:56 | cfriesen | mriedem: sweet, thanks. | |
| 19:32:46 | mriedem | let me know if you want me to restore that | |
| 19:33:43 | openstackgerrit | Ken'ichi Ohmichi proposed openstack/nova master: Remove unused validation code from block_device https://review.openstack.org/410006 | |
| 19:34:13 | cfriesen | mriedem: I'll have to talk to some folks here. looks useful though. | |
| 19:34:33 | mriedem | cfriesen: it might be easier than whatever fork you're cooking up :) | |
| 19:35:15 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Run api sample tests against 2.latest https://review.openstack.org/430352 | |
| 19:35:15 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Use unique volume id in fake_volume https://review.openstack.org/431723 | |
| 19:36:12 | cfriesen | mriedem: we've got a longstanding private patch to prevent deleting or modifying flavors that are in-use, was just wondering if it was worth porting it. I like that spec better long-term. | |
| 19:36:39 | mriedem | cfriesen: why would deleting or modifying them if they are in use matter since nova stores the original? | |
| 19:37:00 | openstackgerrit | Ken'ichi Ohmichi proposed openstack/nova master: Update hacking version https://review.openstack.org/389338 | |
| 19:37:20 | cfriesen | mriedem: the patch was originally introduced before nova stored the original, so stuff actually broke. currently it's mostly there to allow end users to see what the instance actually booted with since something like that spec doesn't exist yet. | |
| 19:37:35 | mriedem | ok | |
| 19:37:45 | mriedem | cfriesen: did you guys just get to newton? | |
| 19:37:54 | dansmith | cfriesen: nova never allowed you to update flavors | |
| 19:37:56 | mriedem | because you know we dropped api extensions in newton right? | |
| 19:38:02 | cfriesen | mriedem: yep, and yep | |
| 19:38:03 | mriedem | dansmith: i think he means extra specs | |
| 19:38:04 | dansmith | cfriesen: you could only soft-delete and re-create | |
| 19:38:07 | dansmith | ah | |
| 19:38:11 | mriedem | cfriesen: so you guys reverted the extension disabled patch? | |
| 19:38:38 | mriedem | you don't have to answer, but i'm interested | |
| 19:38:44 | mriedem | because i figured people would do that | |
| 19:38:49 | dansmith | hah | |
| 19:38:50 | dansmith | I can rephrase if you want | |
| 19:39:03 | dansmith | cfriesen: so you guys are officially committing original openstack sin now right? | |
| 19:39:15 | cfriesen | mriedem: It's actually been other guys doing the port, I'm just starting to look at it. Not actually sure what they did. | |
| 19:39:26 | mriedem | it's always the other guys | |
| 19:39:27 | mriedem | psh | |
| 19:39:29 | mriedem | :P | |
| 19:39:31 | cfriesen | dansmith: private patches? | |
| 19:39:38 | dansmith | cfriesen: against the api? yeah :) | |
| 19:39:52 | mriedem | changing the api is interop sin | |
| 19:40:00 | mriedem | if you don't care about interop, then sin away | |
| 19:40:13 | mriedem | we all know canada is rife with sinners | |
| 19:40:19 | dansmith | and if you don't care about killing the rest of the world's interop bunnies | |
| 19:40:26 | dansmith | mriedem: true story | |
| 19:40:38 | mriedem | sinners that just can't get enough denim! | |
| 19:41:03 | cfriesen | dansmith: mriedem: yeah, I know. currently interop isn't a bit deal, the people that want the extra features are already locking themselves in. Personally I want to add an orthogonal vendor API microversion so that we would give vanilla behavior to vanilla clients. Havent' got resources for it though. | |
| 19:42:29 | cfriesen | mriedem: do you know if sdague ever had code for that Mitaka spec? | |
| 19:43:15 | sdague | cfriesen: I did not, we kept kind of going around in circles about the data stored in it | |
| 19:43:28 | melwitt | I had been thinking extra_specs showed on a 'nova show'. guess not | |
| 19:43:32 | mriedem | oomichi: on https://review.openstack.org/#/c/410006/ i don't see an existing test that handles the bdm boot_index schema | |
| 19:43:58 | sdague | because, after looking into it more in depth, it was actually going to be less API calls, less wire data, and less confusing to just include those attributes inline in the server response | |
| 19:44:36 | cfriesen | melwitt: sdague: yes, was wondering about that...just adding the extra-specs to the "nova show" output | |
| 19:44:38 | sdague | although, I guess if we had extra specs merged in it might get messy | |
| 19:44:55 | sdague | I don't know full, it needs someone to ponder the implications | |
| 19:44:59 | mriedem | plus aren't extra specs hidden from non-admin? | |
| 19:45:08 | mriedem | maybe that doesn't matter here | |
| 19:45:23 | sdague | mriedem: it's fine if there are multiple visibility layers here I think | |
| 19:45:23 | mriedem | we're going to show them or not show them regardless of where we dump the flavor | |
| 19:45:30 | sdague | right | |
| 19:45:34 | melwitt | could still make it admin on a nova show, if that's the case | |
| 19:45:38 | mriedem | yeah | |
| 19:45:51 | mriedem | i like to say things before i think | |
| 19:46:28 | melwitt | I can't remember if we ever updated 'nova show' to show the flavor stored on the instance instead of looking it up | |
| 19:46:41 | mriedem | melwitt: we don't look it up | |
| 19:46:47 | melwitt | *instead of looking it up in the flavors table I mean | |
| 19:46:56 | mriedem | we pull it from the instance | |