| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-15 | |||
| 21:14:35 | cburgess | dansmith Yeah, since the product is no in sustaining mode I don't have budget to travel. I do have budget for "training" so I can swing 1 or 2 openstack events a year that way but I can do all 4 now. | |
| 21:14:44 | cburgess | s/no/now | |
| 21:14:50 | dansmith | yeah :/ | |
| 21:16:09 | cburgess | dansmith But like I said, I'm working on being in Vancouver. | |
| 21:16:25 | dansmith | well, I'll take it | |
| 21:17:37 | openstackgerrit | Merged openstack/nova master: libvirt: remove TODO on validation of scsi model https://review.openstack.org/525055 | |
| 21:23:29 | openstackgerrit | Jackie Truong proposed openstack/python-novaclient master: Microversion 2.61 - Add trusted_image_certificates https://review.openstack.org/500396 | |
| 21:23:47 | cburgess | have fun in dublin for me. Always wanted to go to Ireland. | |
| 21:24:44 | edmondsw | melwitt you asked about 3rd party CI failures... the powervm CI (and presumably others) was failing for the tinyrpc issue that is hopefully fixed by https://review.openstack.org/#/c/545033/ | |
| 21:25:05 | edmondsw | efried FYI ^ | |
| 21:27:12 | melwitt | edmondsw: ah, thanks for that info | |
| 21:27:20 | edmondsw | np | |
| 21:30:46 | edmondsw | melwitt looks like that hasn't merged yet for master, but has +W: https://review.openstack.org/#/c/545025/ | |
| 21:31:54 | melwitt | edmondsw: ack, thanks | |
| 21:31:57 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: List/show all server migration types (1/2) https://review.openstack.org/430608 | |
| 21:32:44 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: List/show all server migration types (2/2) https://review.openstack.org/459483 | |
| 21:33:25 | openstackgerrit | Merged openstack/nova master: Detach volumes when VM creation fails https://review.openstack.org/528385 | |
| 21:33:34 | openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Microversion 2.61 - List/Show all server migration types https://review.openstack.org/430839 | |
| 21:34:51 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Adds view builders for keypairs controller https://review.openstack.org/347289 | |
| 21:37:04 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional recreate test of deleting a BFV server pre-scheduling https://review.openstack.org/545123 | |
| 21:37:05 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Detach volumes when deleting a BFV server pre-scheduling https://review.openstack.org/545132 | |
| 21:37:10 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Parameter verification for servers.inc https://review.openstack.org/528201 | |
| 21:37:10 | mriedem | melwitt: mnaser: ^ thar she blar | |
| 21:37:14 | mriedem | that was actually pretty easy | |
| 21:37:46 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Example verification for servers.inc https://review.openstack.org/529520 | |
| 21:38:23 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix 500 error while passing 4-byte unicode data https://review.openstack.org/407514 | |
| 21:38:30 | melwitt | BFV + easy ... that might be a first | |
| 21:38:47 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Fix parameter order in rebuild https://review.openstack.org/529718 | |
| 21:39:16 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Transform live_migration_post_dest notification https://review.openstack.org/469784 | |
| 21:42:21 | mriedem | easy like bfv morning | |
| 21:42:41 | melwitt | lol | |
| 21:51:14 | mriedem | melwitt: replied in https://review.openstack.org/#/c/340614/ - i think it's mostly a matter of cleaning up the commit message and comments for clarity | |
| 21:51:23 | mriedem | the rest i'm OK with after mnaser sorted me out earlier today | |
| 21:52:04 | melwitt | mriedem: that's what I gathered too, thanks. just have to take another pass to try and make it not confusing. which has been surprisingly hard | |
| 21:55:36 | mriedem | dansmith: how would you like to do something exciting like go through the stable/queens backports and figure out what we want to get into RC2? | |
| 21:55:52 | mriedem | dansmith: or do you want me to take a pass, +2 what i think is safe, and then prod you | |
| 21:56:05 | dansmith | definitely the latter :P | |
| 21:56:08 | mriedem | heh i figured | |
| 21:59:16 | imacdonn | mriedem: FYI, I have been able to reproduce the issue where a rescheduled instance fails with a PortInUse exception (https://pastebin.com/6HAL944i)... on Ocata .. I guess I'll try on Pike next (in spare time) | |
| 22:02:58 | mriedem | dansmith: while i do that, mayhap you'd be so kind as to review these simple docs changes https://review.openstack.org/#/c/544090/ (and the one below it) so i can backport those to queens as well | |
| 22:05:21 | dansmith | mriedem: mayhap done | |
| 22:05:30 | mriedem | great | |
| 22:06:00 | mriedem | do you feel sufficiently up to date on volume multiattach now? | |
| 22:08:59 | dansmith | oh totes | |
| 22:13:04 | mriedem | dansmith: how do you feel about this one for queens? https://review.openstack.org/#/c/543489/ | |
| 22:13:06 | mriedem | RC2 i mean | |
| 22:13:39 | dansmith | idk, I'd like to see those backported, but they don't _have_ to be in rc2 | |
| 22:14:01 | mriedem | if it's low impact/low risk i think it's ok | |
| 22:14:25 | belmoreira | dansmith thanks for https://review.openstack.org/#/c/544585 I added few comments to clarify how we use the cell-scheduler in cellsV1 | |
| 22:16:24 | dansmith | belmoreira: I think you're probably going to have to be willing to tweak some of your current mappings to make things work, | |
| 22:16:34 | dansmith | but yes, we can have more filters with more behaviors, | |
| 22:17:02 | dansmith | and/or tweak the stuff I have proposed | |
| 22:17:15 | dansmith | belmoreira: https://review.openstack.org/#/c/545002/ | |
| 22:17:56 | dansmith | belmoreira: I would like to understand more about why aggregates are more complicated at your scale, as they're pretty much intended to simplify stuff at higher scale | |
| 22:18:11 | openstackgerrit | Merged openstack/nova master: Cleanup the manage-volumes admin doc https://review.openstack.org/544066 | |
| 22:18:14 | dansmith | maybe we can hear from you/surya in dublin about it | |
| 22:18:28 | openstackgerrit | Merged openstack/nova master: Add admin guide doc on volume multiattach support https://review.openstack.org/544090 | |
| 22:18:50 | mriedem | dansmith: ok +2s on the stuff that i thought was fine; https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/queens - mine that aren't -W are up for review also, since i can't +2 those; i also didn't do takashi's for the placement global req id since they are rather large, but could maybe convinced otherwise | |
| 22:20:52 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Cleanup the manage-volumes admin doc https://review.openstack.org/545141 | |
| 22:20:52 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Add admin guide doc on volume multiattach support https://review.openstack.org/545142 | |
| 22:20:53 | mriedem | and these ^ | |
| 22:21:05 | dansmith | okay let me hit your +2s first | |
| 22:22:52 | dansmith | ah yeah all those +2s other than the UC ones are things I had reviewed on master | |
| 22:24:52 | mnaser | melwitt: mriedem so i guess just updating the commit message remains but i'll leave that for melwitt i think she'll do a better job than i will :p | |
| 22:27:15 | belmoreira | dansmith sure, I'm willing to tweak the current mappings to work with the new scheduler schema. I just wanted to describe how we currently do it for reference | |
| 22:27:31 | dansmith | belmoreira: okay, definitely appreciate that :) | |
| 22:27:40 | mriedem | belmoreira: hard-coding projects in config is a bit odd | |
| 22:27:47 | mriedem | https://gitlab.cern.ch/belmiro/cellsv1-filters/blob/master/target_cell_project.py#L29 | |
| 22:29:59 | belmoreira | mriedem I agree, that was the initial approach. Now the cell mapping is a property of the project. Just didn't remove that old code just in case... | |
| 22:31:04 | mriedem | oh yeah i see now | |
| 22:31:05 | mriedem | cells_mapping = client_key.get_cells_mapping(instance_project_id) | |
| 22:31:13 | mriedem | if config, use those, else get the mappings from keystone | |
| 22:31:50 | belmoreira | mriedem it was kept for the transition phase, when not all the projects had the cell mapping as a property | |
| 22:32:29 | belmoreira | I have >3000 projects :) | |
| 22:34:25 | mriedem | belmoreira: i assume the complexity with host aggregates at that scale is that a lot of hosts are in a lot of different aggregates | |
| 22:34:54 | mriedem | how much of the aggregate management is automated? | |
| 22:35:13 | belmoreira | dansmith mriedem also because is very difficult to automate add/remove nodes | |
| 22:35:20 | dansmith | why | |
| 22:35:21 | dansmith | ? | |
| 22:35:31 | dansmith | (is it difficult) | |
| 22:35:53 | belmoreira | using a configuration management tool is not that safe/easy for this operations | |
| 22:36:00 | dansmith | sure, but this is done via the api | |
| 22:36:46 | belmoreira | that is one of the main reasons. The conf tool will need to have credentials for these operations | |
| 22:37:02 | mriedem | removing nodes is a problem i can see, there is no api for that really - we have delete service, but that doesn't cleanup the compute_nodes table entry | |
| 22:37:26 | dansmith | belmoreira: oh okay, I guess my point was .. maybe using conf management for this is not a good idea ;) | |
| 22:38:29 | dansmith | mriedem: removing nodes what? you can remove a node from an aggregate via the api | |
| 22:38:43 | mriedem | i assumed he was talking about dropping hosts | |
| 22:38:54 | mriedem | not add/remove aggregate members | |
| 22:39:09 | dansmith | hmm | |
| 22:39:35 | belmoreira | mriedem was talking about aggregate management using a conf management tool | |
| 22:39:38 | mriedem | which spurred the discussion the other day about delete_cell needing a --ignore-placement flag or whatever | |
| 22:39:53 | mriedem | ok, ignore me then, i'm talking about something else | |
| 22:39:59 | mriedem | 'decomissioning' nodes | |
| 22:41:13 | belmoreira | that is a one time operation. I'm not that worry if is not full automated | |
| 22:42:23 | dansmith | belmoreira: are you going to be in dublin or just tssurya? | |
| 22:42:50 | belmoreira | dansmith just tssurya | |
| 22:42:57 | dansmith | okay | |
| 22:42:59 | belmoreira | I will be Vancouver | |
| 22:43:06 | dansmith | okay | |
| 22:44:19 | belmoreira | my previous point was that if for a specific use case we need to create aggregates/add nodes it will be very difficult to manage this at scale | |