| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-15 | |||
| 11:07:51 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add sample test for instance audit https://review.openstack.org/480955 | |
| 11:43:28 | openstackgerrit | Maciej Jozefczyk proposed openstack/nova master: Update resources once in update_available_resource https://review.openstack.org/520024 | |
| 12:17:02 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Aggregate ops on ProviderTree https://review.openstack.org/526216 | |
| 12:17:02 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Move aggregates from report client to ProviderTree https://review.openstack.org/521685 | |
| 12:17:03 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Track provider traits in report client https://review.openstack.org/521686 | |
| 12:17:03 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Track associated sharing RPs in report client https://review.openstack.org/526539 | |
| 12:17:04 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Raise on API errors getting aggregates/traits https://review.openstack.org/526540 | |
| 12:17:05 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756 | |
| 12:17:05 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Track tree-associated providers in report client https://review.openstack.org/526541 | |
| 12:17:05 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: WIP: Scheduler[Report]Client.get_provider_tree https://review.openstack.org/521098 | |
| 12:17:06 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: WIP: ComputeDriver.update_provider_tree() https://review.openstack.org/521187 | |
| 12:17:06 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246 | |
| 13:05:08 | Hanif | Hi, I have an issue with OpenStack while creating a VM. The IP address assigned to the VM is different than the IP address in the VM. I am using Layer 2, Provider network in my configuration. Has anyone encountered such an issue? | |
| 13:26:37 | Adri2000 | hello | |
| 13:27:03 | Adri2000 | is there a way to get a cell's uuid from its name using nova-manage? | |
| 13:27:45 | Adri2000 | actually I'd like to do this: create "mycell" if it doesn't exist, or update it if it does exist | |
| 13:27:53 | Adri2000 | `nova-manage cell_v2 update_cell` needs the uuid | |
| 13:28:01 | tssurya | just run nova-manage cell_v2 list_cells | |
| 13:28:16 | tssurya | it would give you a list of existing cells with their info | |
| 13:28:18 | Adri2000 | tssurya: and then parse that table? | |
| 13:28:27 | Adri2000 | I'm automating this | |
| 13:28:45 | Adri2000 | and would like to avoid sed'ing and awk'ing a table that's designed for humans to read | |
| 13:41:51 | bauzas | Adri2000: why not list_cells works for you ? | |
| 13:44:43 | maciejjozefczyk | bauzas: Hello; it looks like related test has been solved https://review.openstack.org/#/c/520024/ :) | |
| 13:44:44 | Adri2000 | bauzas: this is something I'm doing for openstack-ansible, so need a way to get that id automatically and reliably | |
| 13:45:03 | Adri2000 | bauzas: I assume a tabular output like this is nnot meant to be parsed by a script or by an ansible playbook.. | |
| 13:46:49 | Adri2000 | bauzas: openstack-ansible currrently automatically runs create_cell with the rabbitmq nodes etc as a parameter. if the list of rabbitmq nodes changes (like you add or remove a node of your rabbit cluser), the create_cell command is run again (but with different parameters because of the rabbitmq nodes list) | |
| 13:46:58 | Adri2000 | and it creates a duplicate cell | |
| 13:47:15 | Adri2000 | (https://bugs.launchpad.net/openstack-ansible/+bug/1736731 if you're interested) | |
| 13:47:15 | openstack | Launchpad bug 1736731 in openstack-ansible "os_nova might create a duplicate cell1" [High,Confirmed] - Assigned to Jean-Philippe Evrard (jean-philippe-evrard) | |
| 13:47:37 | Adri2000 | anyway, we figured openstack-ansible should check whether the cell already exists, if it does, run update_cell instead | |
| 13:47:46 | Adri2000 | and that's why I need the cell id... | |
| 13:48:58 | Adri2000 | for the record, the triple folks had a similar bug and fixed it with a beautiful | sed | awk parsing: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=ebcaabcc5c5d2840128b3609c82c4a70a81ea0a0 | |
| 13:49:47 | Adri2000 | but I'm not very happy with that solution :( | |
| 13:51:33 | Adri2000 | bauzas: does it even make sense that nova allows two different cells having the same name? | |
| 13:52:32 | bauzas | Adri2000: for your first concern, I understand your point | |
| 13:53:36 | bauzas | for the second, lemme see if it's possible | |
| 14:02:40 | mriedem | bauzas: artom's request_specs.spec column increase is ready to go imo https://review.openstack.org/#/c/528012/ | |
| 14:02:54 | bauzas | mriedem: ack, looking | |
| 14:03:32 | bauzas | mriedem: jay said litterally no performance impact for the alter, right? | |
| 14:03:49 | mriedem | that's what i think i heard yeah | |
| 14:06:54 | artom | bauzas, the caveat was that it's only for InnoDB | |
| 14:07:08 | artom | So I'm a bit worried we might be screweing over some non-InnoDB folks | |
| 14:07:36 | artom | But I understood that we only really support MySQL, and therefore InnoDB | |
| 14:09:03 | bauzas | artom: well, myisam seems weird for nova tables :p | |
| 14:09:25 | bauzas | of course, it could be for other engines but AFAIK, we only support innodb | |
| 14:10:36 | bauzas | anyway | |
| 14:10:40 | openstackgerrit | Takashi NATSUME proposed openstack/nova stable/pike: [placement] Fix an error message in API validation https://review.openstack.org/526465 | |
| 14:11:29 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: [cellv2] Improve getting BDMs in multiple cells https://review.openstack.org/521400 | |
| 14:12:06 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: [placement] Fix getting placement request ID https://review.openstack.org/523606 | |
| 14:13:17 | artom | bauzas, MyISAM seems weird for anything, really | |
| 14:13:30 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Deduplicate functional test code https://review.openstack.org/526227 | |
| 14:13:32 | artom | Is there a workload where it would actually be better? | |
| 14:14:20 | maciejjozefczyk | mriedem: Please take a look on this patch https://review.openstack.org/#/c/520024/. We spoke about it during summit | |
| 14:18:12 | mriedem | it's on my list. i see gibi has been looking at it. | |
| 14:19:09 | maciejjozefczyk | mriedem: yes, related test that failed eariler has been fixed with some change related to ironic | |
| 14:19:19 | maciejjozefczyk | thanks :) | |
| 14:20:38 | giblet | maciejjozefczyk: ahh so the failing test is not blocking it any more, that helps | |
| 14:20:45 | maciejjozefczyk | giblet: yea | |
| 14:20:51 | giblet | maciejjozefczyk: I just opened the patch will look it through shortly | |
| 14:20:59 | maciejjozefczyk | giblet: ;) | |
| 14:24:11 | bauzas | artom: FK != MyIsam ;) | |
| 14:24:31 | bauzas | so indeed :p | |
| 14:34:58 | artom | bauzas, seriously, it doens't have foreign keys? | |
| 14:35:17 | artom | I seem to recall still being able to do JOINs with MyISAM though | |
| 14:35:23 | artom | I guess those don't depend on FKs? | |
| 14:35:30 | artom | Like I said, my SQL isn't too hot | |
| 14:35:49 | bauzas | artom: of course, denormalized works | |
| 14:36:06 | bauzas | mriedem: FWIW https://stackoverflow.com/questions/3516290/any-pitfalls-of-converting-mysql-text-field-to-mediumtext | |
| 14:36:25 | bauzas | only a client possible impact about memory usage | |
| 14:36:26 | bauzas | but meh | |
| 14:36:55 | giblet | maciejjozefczyk: left a small nit in https://review.openstack.org/#/c/520024 . Ping me when you fixed it and I will +2 the patch | |
| 14:37:31 | maciejjozefczyk | giblet: ok :) thanks | |
| 14:38:44 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: update_cell allows more than once cell to have the same db/transport url https://review.openstack.org/518556 | |
| 14:41:01 | openstackgerrit | Jianghua Wang proposed openstack/nova master: XenAPI: create vGPU for instance https://review.openstack.org/516899 | |
| 14:41:44 | bauzas | artom: mriedem: +Wd with a comment | |
| 14:43:07 | mriedem | ack thanks | |
| 14:43:27 | mriedem | bauzas: so before i even think about backports and releasing this in stable branches, | |
| 14:43:59 | mriedem | let me know now before i do that what kind of freakouts your internal deployment team is going to have if it's released with the wrong version | |
| 14:44:20 | mriedem | i'm assuming they want a minor version update | |
| 14:44:23 | mriedem | so 16.1.0 for pike | |
| 14:47:13 | lyarwood | mriedem: I don't see why they would have issues with this as a release or minor bump tbh | |
| 14:47:15 | bauzas | mriedem: good point | |
| 14:47:48 | bauzas | a DB alter is at least a minor change, not a .z | |
| 14:47:56 | bauzas | but I think it's acceptable for us | |
| 14:49:25 | openstackgerrit | Maciej Jozefczyk proposed openstack/nova master: Update resources once in update_available_resource https://review.openstack.org/520024 | |
| 14:49:58 | maciejjozefczyk | giblet: ping :) you're right | |
| 14:50:03 | maciejjozefczyk | giblet: updated | |
| 14:50:09 | giblet | maciejjozefczyk: looking... | |
| 14:53:16 | artom | bauzas, lyarwood, so dansmith was saying that we can release it as a .z, and people who don't know about it won't do the db sync | |
| 14:53:28 | giblet | maciejjozefczyk: thanks, +2 | |
| 14:53:42 | artom | And they'll get the migration on their next major upgrade like everyone else | |
| 14:54:03 | artom | But people who are affected will have one more step in their .z upgrade path | |
| 14:54:07 | maciejjozefczyk | giblet: thanks too ;) | |
| 14:54:09 | lyarwood | artom: right, the NVR really doesn't change that for us, but it's still a minor release bump change as bauzas highlighted. | |
| 14:55:04 | artom | lyarwood, ah, I see | |
| 14:55:30 | artom | In any case, it's not like our deployment tooling/packaging does 'db sync' on yum update, so I think we're good | |
| 14:55:56 | lyarwood | artom: yup indeed | |
| 14:59:28 | mriedem | so after your red hat meeting, what have you agreed the rest of us must do? | |
| 14:59:31 | mriedem | minor bump? | |