| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-24 | |||
| 18:48:23 | dansmith | cburgess: no specifically what we were just talking about | |
| 18:48:23 | mriedem | ocata was using placement but not for claims | |
| 18:48:29 | dansmith | cburgess: placement claims stuff | |
| 18:48:38 | cburgess | Ahh ok | |
| 18:48:54 | mriedem | now we're basically redoing the resource tracker with placement, but triplicating it everywhere when things fail | |
| 18:49:10 | cburgess | That means we can blame jaypipes right? | |
| 18:49:14 | mriedem | btw chet, wtf, you just show up? | |
| 18:49:18 | dansmith | doing the allocations stuff as part of RT was a huge mistake from the beginning | |
| 18:49:22 | mriedem | in our hour of need | |
| 18:49:25 | cburgess | mriedem To... ? | |
| 18:49:29 | openstackgerrit | Ildiko Vancsa proposed openstack/nova-specs master: Add spec to use cinder's new attachment API https://review.openstack.org/497552 | |
| 18:49:31 | dansmith | it should have been all clean and separate | |
| 18:49:36 | cburgess | mriedem Oh I just looked at the back scroll yeah | |
| 18:49:52 | cburgess | I try and stay current but fail mostly so when I do see something of interested I ask. | |
| 18:50:04 | edmondsw | is there any way to toggle whether an existing flavor is public or not? I don't see an update flavor API in the API docs, and the os-flavor-access APIs don't appear to do that either based on the docs... | |
| 18:50:13 | mriedem | something interesting like me and dan crying over the state of things | |
| 18:50:31 | mriedem | edmondsw: there is no update flavors api | |
| 18:50:44 | cburgess | mriedem Well.. more specifically seeing 2 cores I have a lot of respect for seriously debating concerns around stability makes me notice. | |
| 18:50:45 | mriedem | os-flavor-access restricts access per tenant | |
| 18:50:54 | mriedem | cburgess: heh as it should :) | |
| 18:50:59 | mriedem | anyway, fixing this bug quick | |
| 18:51:04 | cburgess | I want to know why so I can better steer our plans in the future of what releases to move to and when. | |
| 18:51:04 | edmondsw | mriedem right, that's what I was afraid of... boo... | |
| 18:51:16 | dansmith | cburgess: that's stage 1 concern, stage 2 is seeing us polishing up resumes | |
| 18:51:38 | dansmith | speaking of which, has anyone seen my bottle of resume polish? | |
| 18:51:44 | cburgess | dansmith Yes... very yes. | |
| 18:52:01 | cburgess | Wait there is a polish for that? Maybe thats why I've been stuck in this same job for 6 years... :P | |
| 18:52:21 | edmondsw | seems odd that we have an API to allow you to restrict access by tenant but not to open it up to all tenants | |
| 18:52:26 | dansmith | cburgess: https://cdn.dribbble.com/users/327319/screenshots/1695561/resume_polish-01_1x.png | |
| 18:52:27 | edmondsw | oh well | |
| 18:53:16 | cburgess | dansmith OMG I'm going to have to use that on social media some how. Thats brilliant. | |
| 18:58:16 | mriedem | hmm looks like remove_provider_from_instance_allocation handles the resize to same host for me | |
| 19:30:28 | openstackgerrit | Dan Smith proposed openstack/nova master: Add uuid to migration object and migrate-on-load https://review.openstack.org/496934 | |
| 19:35:27 | mriedem | ok fix incoming | |
| 19:35:27 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Cleanup allocations in failed prep_resize https://review.openstack.org/497592 | |
| 19:35:55 | mriedem | dansmith: ^ should handle both resize to same host and different hosts, but don't have a functional test for the resize to same host case | |
| 19:35:56 | mriedem | yet | |
| 19:39:45 | mriedem | oomichi: can you help review ^ too please? | |
| 19:39:52 | mriedem | we're pretty short staffed right now | |
| 19:44:05 | dansmith | mriedem: why not do the flavor->resources conversion in the caller and then just re-use the existing migration method in the RT? | |
| 19:44:41 | dansmith | other than that the method is identical to the above in terms of functionality | |
| 19:44:49 | mriedem | because the existing method uses instance.flavor | |
| 19:44:52 | mriedem | which is not the new flavor yet | |
| 19:45:25 | mriedem | the instance.flavor = new_flavor in finish_resize | |
| 19:45:29 | dansmith | ah, I misread the first line | |
| 19:45:44 | mriedem | it's sneaky | |
| 19:46:00 | dansmith | could still refactor it to take a flavor | |
| 19:46:09 | dansmith | just seems like it's too similar to duplicate | |
| 19:46:24 | mriedem | well, the name is misleading, and the error message if it fails | |
| 19:48:19 | mriedem | cdent was doing similar dedup here https://review.openstack.org/#/c/496936/ | |
| 19:48:20 | guimaluf | hi guys, I'm getting "Instance failed network setup after 1 attempt(s)" followed by "Timed out waiting for a reply to message ID Timed out waiting for a reply to message ID". My compute node run neutron-{ovs,dhcp,metadata}-agent, and neutron-server and ml2 plugin on my neutron node. Rabbitmq is working. Any clue or direction? | |
| 19:48:51 | guimaluf | I couldn't find nothing meaningful on neutron-server logs, nor neutron-agents | |
| 20:04:39 | mriedem | cool got the resize to same host test done too | |
| 20:07:23 | cfriesen_ | guimaluf: maybe enable debug logs in neutron/nova? try to isolate whether neutron got the message, whether it processed the message, whether it sent a reply, and whether nova received the reply. | |
| 20:08:34 | guimaluf | cfriesen_, is so difficult to check neutron agents logs, cause there is an process in loop filling the screen with trash info | |
| 20:08:46 | guimaluf | cfriesen_, I've enabled the debug and trying to check it out... :/ | |
| 20:08:50 | mriedem | dansmith: i've got the func test for the resize to same host part of this, so i'll push that up quick also | |
| 20:09:06 | mriedem | and deal with merging those methods in a follow u | |
| 20:09:08 | mriedem | *up | |
| 20:10:21 | dansmith | okay | |
| 20:11:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Cleanup allocations in failed prep_resize https://review.openstack.org/497592 | |
| 20:11:02 | mriedem | there it is | |
| 20:12:20 | mriedem | if the func test refactor part bothers you i could pull the new resize test into the patch before this one | |
| 20:12:24 | mriedem | might make review cleaner | |
| 20:13:05 | dansmith | already +2d it | |
| 20:13:18 | mriedem | sweet exhaustion | |
| 20:13:34 | mriedem | now, who do we make temporary core | |
| 20:14:18 | cfriesen_ | mriedem: https://review.openstack.org/#/c/497592 looks okay (with lots of room for cleanup though). were you planning on adding that testcase in test_servers.py or leaving that for a future patch? | |
| 20:14:31 | mriedem | cfriesen_: see PS2 | |
| 20:14:55 | dansmith | mriedem: we can wait a bit and see if someone pops up and if not I can just slam it in with an emergency war declaration | |
| 20:15:18 | mriedem | ok, but keep in mind we have to backport and merge in stable/pike too before the rc2 tag | |
| 20:15:30 | dansmith | oh today is thursday huh | |
| 20:15:33 | mriedem | and dims and doug are east coast choppers | |
| 20:16:00 | dansmith | so better do it now then eh? | |
| 20:16:36 | dims | dansmith : mriedem : i will be up until say 10:30-11:00 pm my time | |
| 20:16:37 | mriedem | let cfriesen_ +1 it :) | |
| 20:17:20 | cfriesen_ | heh | |
| 20:19:55 | dansmith | ooh, oomichi for the win | |
| 20:20:23 | mriedem | dansmith: oomichi: don't forget this one in the middle https://review.openstack.org/#/c/497541/1 | |
| 20:20:30 | mriedem | the middle child is always left out | |
| 20:22:00 | dansmith | mriedem: I just slammed that one since it's just a test | |
| 20:28:58 | mriedem | ok | |
| 20:32:10 | cfriesen_ | mriedem: it seems wrong to have a test called "test_rescheduling_when_migrating_instance" that doesn't actually test anything around rescheduling. | |
| 20:32:48 | mriedem1 | starting the backport parade | |
| 20:35:58 | mriedem | dansmith: ok we've got 4 backports for stable/pike, the 3 for this series starting here https://review.openstack.org/#/c/497542/ | |
| 20:36:08 | mriedem | and this guy https://review.openstack.org/#/c/497461/ | |
| 20:36:10 | mriedem | then that's rc2 | |
| 20:36:32 | dansmith | waiting for master to merge though right? | |
| 20:36:56 | mriedem | yeah i suppose, you could line up +2s w/o approvals | |
| 20:37:00 | mriedem | or jus twait | |
| 20:37:09 | mriedem | gate seems backed up today | |
| 20:37:44 | dansmith | okay all set | |
| 20:37:46 | mriedem | queues aren't big though so not sure if it's just me | |
| 20:38:05 | mriedem | cool | |
| 20:38:11 | mriedem | i'll start the rc2 proceedings | |
| 20:38:23 | dansmith | yeah I dunno why it's so slow with a relatively low workload | |
| 20:39:07 | dansmith | that conf thing is about to blow through | |
| 20:41:11 | dansmith | mriedem: your prep resize one at the end has a bunch of fails | |
| 20:41:21 | dansmith | like pep8 even I think | |
| 20:41:43 | mriedem | https://review.openstack.org/#/c/497610/ | |