Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-06
18:24:43 leakypipes lol
18:24:52 leakypipes welcome back.
18:25:12 sfinucan Ctrl + W kills tabs in HexChat also. Who knew?
18:25:18 leakypipes :)
18:25:31 openstackgerrit John Garbutt proposed openstack/nova: WIP: Add service_token for nova-cinder interaction https://review.openstack.org/397399
18:25:37 sean-k-mooney sfinucan: i opened a bug for the windows issue with os-vif https://bugs.launchpad.net/os-vif/+bug/1654616 i will try and adress it next week
18:25:37 openstack Launchpad bug 1654616 in os-vif "_plug_vif_windows uses linux net fuctions that do not work correctly on windows." [Undecided,New]
18:25:39 leakypipes sean-k-mooney: some MTU was set to 0? :(
18:26:00 sean-k-mooney leakypipes: that was the nova default until mitaka
18:26:15 sean-k-mooney leakypipes: and neutron default
18:26:25 bauwser leakypipes: oh no
18:26:31 leakypipes sean-k-mooney: I'm presuming it was meant to mean "default to whatever the PMTU is of the existing segment?"
18:26:32 bauwser leakypipes: okay, I'll rebase anyway
18:27:01 leakypipes bauwser: yeah, I have to as well :)
18:27:15 leakypipes bauwser: we're all competing for the API microversion mutex :)
18:27:40 sean-k-mooney leakypipes: no up to mitaka it was just 0 which in python ment "if mut" was false and nova and neutorn did not set one at all
18:27:46 bauwser I should write a git hook for that :)
18:27:50 bauwser leakypipes: ^
18:27:51 openstackgerrit Stephen Finucane proposed openstack/os-vif: vif_plug_ovs: Always set MTU when plugging devices https://review.openstack.org/408779
18:27:58 leakypipes sean-k-mooney: ah, ok, makes sense now.
18:28:13 leakypipes bauwser: I know, right?
18:28:35 bauwser leakypipes: something like "lemme verify the last microversion in gerrit, and if conflicting, then sed my number" :)
18:28:55 leakypipes bauwser: :)
18:29:17 sfinucan leakypipes: Let me know if that's ^ any clearer
18:29:52 sean-k-mooney leakypipes: by the way will you be at the ptg in febuary. we should grab some time to talk about what needs to be done in os-vif if people are around
18:30:04 bauwser sfinucan: call it for yourself :p
18:30:33 sean-k-mooney :)
18:30:35 leakypipes sean-k-mooney: yup, totes.
18:31:07 sean-k-mooney well in horizon there is an evacuate button that i like to press to see what happens
18:31:40 sean-k-mooney i assumed that that is waht the operator would do after marking the host as down for scheuling :)
18:35:07 leakypipes sfinucan: quick correction needed.
18:36:14 sean-k-mooney leakypipes: sfinucan: the [1] not refereing which installer it is?
18:36:21 leakypipes sean-k-mooney: the big, red, shiny red button: http://img00.deviantart.net/90a4/i/2011/258/e/8/don__t_press_the_button__stimpy_by_megbeth-d49x1oz.jpg
18:36:41 leakypipes sean-k-mooney: right, that's why I said I think you're missing a footnote :)
18:37:06 sean-k-mooney i had not reloaded yet but yes i see that comment
18:37:45 sean-k-mooney i was going to leave the same comment
18:38:02 openstackgerrit OpenStack Proposal Bot proposed openstack/nova: Updated from global requirements https://review.openstack.org/415978
18:40:50 edmondsw sdague can we merge https://review.openstack.org/#/c/398610/ as-is? Someone else could do the additional work you suggest in your comment, but I don't think this should have to wait for that
18:42:38 mriedem superdan: fyi if you didn't get the answer yet https://review.openstack.org/#/c/416401/
18:44:42 mriedem melwitt: superdan: server details list does have an extention in the latest microversion to pull host service status
18:45:12 mriedem superdan: melwitt: http://docs.openstack.org/developer/nova/api_microversion_history.html#id14
18:46:16 openstackgerrit Gábor Antal proposed openstack/nova: Transform instance.reboot.error notification https://review.openstack.org/411791
18:46:38 melwitt mriedem: thanks. we're seeing a failure where a test that calls direct to the hypervisors api is failing though too
18:47:38 mriedem sean-k-mooney: you know https://launchpad.net/~os-vif-drivers/+members doesn't mean core team right?
18:47:40 melwitt I wonder if the server listing causes an rpc connection to get cached to the wrong queue topic or something, because what we're seeing is compute not responding on the 'cells' topic
18:48:06 melwitt with cells v1, compute has to listen/respond on both the 'compute' and 'cells' topics
18:48:17 sean-k-mooney mriedem: yes i wanted to be able to do bug triage
18:48:20 mriedem ah ok
18:48:34 mriedem btw, https://review.openstack.org/#/admin/groups/1175,members i don't need to be in the core team there :)
18:48:49 mriedem i think i've reviewed maybe 2 os-vif patches
18:49:48 sean-k-mooney mriedem: leakypipes "volentold" you but if you do not want to be on it or dont feel comfortable reviewing it in general i can remove you again
18:51:11 leakypipes mriedem is an all-round amazing velvet doberman of a programmer. he is amazing. thus the desire to make him an os-vif-core.
18:51:38 mriedem sean-k-mooney: removed myself :)
18:52:59 sean-k-mooney mriedem: no worries, leakypipes looks like we need to up our flattery game.
18:53:42 sean-k-mooney ok i have to run so ill talk to everyone later
18:53:42 mriedem heh, i just can't handle the pressure
18:56:44 leakypipes boo :(
18:59:36 melwitt looks like that host service status is just a servicegroup api query for up/down so shouldn't be related
19:02:40 cdent I'm finding myself wishing I could create nameless resource providers over the api. But it is really only for testing, not real life, so I guess that doesn't count.
19:05:33 mriedem leakypipes: superdan: i'm cool with https://review.openstack.org/#/c/410471/ now
19:07:17 mriedem bauwser: leakypipes: i was at lunch and missed the discussion about the placement client stuff - was the decision to NOT pull that out and instead just re-use the scheduler report client stuff in the host manager?
19:11:23 leakypipes mriedem, superdan: Wallaby'd.
19:12:11 leakypipes mriedem, bauwser: well, what I was saying was to not create a placement client and instead do raw calls into the placement API in the same vein as the scheduler report client.
19:13:35 mriedem leakypipes: superdan: got a problem in this https://review.openstack.org/#/c/410472/
19:13:50 superdan mriedem: leakypipes thanks
19:14:40 mriedem leakypipes: oh, ok...well....we'd have that same pattern in 3 places in nova then...
19:14:47 mriedem scheduler report client, nova-status, and then the host manager
19:15:06 mriedem and as seen with the 401 issue this week, if we have a bug in one we have to check all of the others
19:16:22 leakypipes mriedem, bauwser: I'd be cool pulling the very basic safe_connect() and get/put/delete/post methods into a base class, I suppose, but nothing more than that.
19:16:50 bauwser leakypipes: I already wrote that, lemme upload it
19:17:01 bauwser leakypipes: I just want to not wait for that
19:17:09 mriedem leakypipes: that's what this does https://review.openstack.org/#/c/417111/2/nova/scheduler/client/__init__.py
19:17:13 leakypipes mriedem, bauwser: i.e. I don't want to hold up progress putting together an object-oriented placementclient-type thing.
19:17:21 bauwser exactly
19:17:24 mriedem yeah i agree with not holding it up
19:17:27 bauwser the change is becoming huge
19:17:30 mriedem but...if it's a simple lieft
19:17:34 mriedem *lift
19:17:40 mriedem bauwser: what is huge about it? the tests?
19:17:41 bauwser so I'll write the scheduler modification before that change
19:17:44 bauwser mriedem: zacvtly
19:17:57 bauwser mriedem: and because I copy/paste a lot
19:18:06 bauwser creating a new module
19:18:11 leakypipes bauwser: yeah, I don't see that patch being too big?
19:18:20 bauwser leakypipes: mriedem: you'll see
19:18:33 bauwser just rebasing the API change and you'll see, folks
19:18:35 openstackgerrit John Garbutt proposed openstack/nova: WIP: Objectify _validate_requested_network_ids https://review.openstack.org/411950
19:18:39 leakypipes ok
19:19:55 leakypipes bauwser: the only thing I'd like to see is the use of encapsulation instead of inheritance there.
19:19:57 mriedem bauwser: so the alternative is just using the existing stuff in the scheduler report client class right?
19:20:19 leakypipes bauwser: in other words, just have the scheduler report client contain an instance of PlacementClient.
19:20:31 bauwser leakypipes: yup
19:20:32 mriedem if it's just a matter of using the scheduler report client right now because it's available and easy, then just do that and we can split apart and cleanup later
19:20:49 bauwser leakypipes: I wrote an encapsulation like cdent asked
19:20:56 leakypipes k
19:21:07 bauwser leakypipes: I wrote an inheritance because I was lazy
19:23:15 bauwser mriedem: just a question : we created a stable 14.0.2 pin but we have a DB migration in it, which requires a db sync, shouldn't we have created a 14.1.0 ?
19:23:36 jroll mriedem: I see you in my meeting agenda, are you attening or did you just want me to say words about that
19:23:46 jroll I'm up to date on the statuses of those things
19:25:46 leakypipes superdan: your eyeballs on https://review.openstack.org/#/c/415031/ would be appreciated. I know it's a blocker for mlavalle :)

Earlier   Later