Earlier  
Posted Nick Remark
#openstack-sdks - 2018-09-19
16:10:06 mordred since the user gave us the endpoint
16:10:11 dtantsur aha, and this is something that I think I changed in the API SIG patch ;)
16:10:18 mordred heh
16:10:25 dtantsur because that means we're still stuck with versioned endpoints everywhere
16:10:39 dtantsur aaaand microversion discovery also?
16:10:51 mordred yeah- we need to figure out when it is the correct thing to do to do the discovery logic even with an endpoint override
16:11:01 dtantsur man we need to dedicate a whole day in Berlin in November just to sit down and go through this mess
16:11:06 mordred for microversion discovery it will do the fetch on the endpoint override
16:11:12 mordred dtantsur: ++
16:11:13 mordred seriouslyu
16:11:27 mordred because therea re like 12 competing use cases
16:11:32 dtantsur yep
16:12:22 dtantsur ideally, I'd prefer to endpoint-override to be unversioned (but support versioned ones too)
16:12:32 dtantsur my head hurts just from thinking about it..
16:16:20 mordred dtantsur: yeah. such awesomeness
16:16:56 dtantsur the next two functions are also awesome: they handle the fact that some API use empty string instead of null :)
16:17:08 dtantsur which is not an issue for Python but a big issue for a statically typed language :D
16:32:18 mordred dtantsur|afk: ok. I think I have the versioned/unversioned thing handled
16:35:13 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Use discovery instead of config to create proxies https://review.openstack.org/600292
19:33:03 openstackgerrit Merged openstack/openstacksdk master: Explicitly set logging levels for external libs https://review.openstack.org/602085
21:33:39 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Run all tasks through the threadpool https://review.openstack.org/603739
23:47:10 openstackgerrit Merged openstack/openstacksdk master: Update baremetal objects with fields added up to Rocky https://review.openstack.org/599420
#openstack-sdks - 2018-09-20
06:34:48 AJaeger Shrews, mordred, can you approve https://review.openstack.org/#/c/594393/ , please?
06:35:27 AJaeger please also review https://review.openstack.org/#/c/603563/ - that finishes python3-first goal
12:45:23 Shrews AJaeger: mordred: why does that shade job need to be in stable/queens branch when the job itself requires shade master?
12:46:09 AJaeger Shrews: that job is *today* configured this way in project-config. If it's wrong, good that we figure that one finally out ;)
12:46:47 Shrews i don't see that job in project config, only a reference to it for ansible/ansible
12:47:13 AJaeger Shrews: let's double check - which job exactly do you mean?
12:47:22 mordred Shrews: oh, good point - I don't think it needs to be there
12:47:23 Shrews shade-ansible-stable-2.5-functional-devstack
12:47:53 AJaeger Shrews: ah, we can remove it as well completely.
12:47:58 mordred AJaeger, Shrews: lemme fix real quick
12:49:06 AJaeger mordred, Shrews - indeed, why was it added there?
12:50:19 AJaeger Shrews: ah see, it - mordred changed shade-ansible-functional-devstack which was in-repo... We could remove that one as well...
12:50:37 mordred AJaeger, Shrews: remote: https://review.openstack.org/594393 import zuul job settings from project-config
12:51:36 AJaeger LGTM, want to +2A directly?
12:53:11 mordred wfm - look good to you Shrews ?
12:53:24 Shrews looking
12:55:19 AJaeger mordred: want to +2A https://review.openstack.org/#/c/597579 as well? I expect dhellmann to remove his WIP from it once 594393 merged...
12:55:53 Shrews where is openstack-cover-jobs template?
12:56:45 AJaeger Shrews: in openstack-zuul-jobs - as announed in openstack-dev mailing list
12:56:53 AJaeger bbl
12:57:16 Shrews oh, my repo wasn't up-to-date
12:57:17 Shrews :)
12:57:34 Shrews +3
13:30:48 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Use discovery instead of config to create proxies https://review.openstack.org/600292
13:55:28 AJaeger mordred: do you know why https://review.openstack.org/600941 fails?
13:56:25 mordred AJaeger: I'm going to blame elves
13:57:09 mordred AJaeger: lots of timeout exceptions - maybe just got a super slow node?
13:57:12 AJaeger so, recheck again?
13:57:29 mordred yeah. :(
13:57:40 AJaeger ok, thanks
14:05:37 openstackgerrit Merged openstack/openstacksdk master: Update .zuul.yaml https://review.openstack.org/603563
14:29:49 openstackgerrit LIU Yulong proposed openstack/openstacksdk master: Support firewall service for SDK https://review.openstack.org/592303
15:08:19 mnaser mordred: i remember you mentioning there was a way to get an 'http client' for the placement service using openstacksdk :(
15:08:23 mnaser but i cant remember where or how
15:09:03 mnaser it was something that even if there is no placement support, doing something got you an http client
15:18:11 mordred mnaser: conn.placement should be an http client for placement
15:18:44 mordred mnaser: so conn.placement.get('/some/url') should return you a Response object
15:18:55 mnaser mordred: wonderful, i'll give that a shot. writing tooling to do an audit of placement/nova
15:19:33 mordred cool! we should probably add real placement support
15:19:46 mordred maybe one day I'll sucker cdent into doing that
15:19:51 mnaser mordred: mriedem made osc-placement so it cant be that much work
15:20:14 cdent andrey and a few others did a lot of that work
15:20:24 cdent mordred: curl and/or gabbi 4evah
15:23:42 mnaser mordred: http://paste.openstack.org/show/730447/ shucks
15:23:45 mnaser i remember us talking about this
15:23:53 mnaser maybe the fix wasn't released
15:24:04 mnaser cdent pushed up something about this too
15:25:51 mriedem yeah i only reviewed osc-placement...
15:26:11 cdent mnaser: you thinking of this: https://review.openstack.org/#/c/575117/ ?
15:26:32 mriedem cdent: no,
15:26:34 mriedem more about,
15:26:34 mnaser cdent: ah yes
15:26:47 mnaser this is a queens deployment
15:26:47 mriedem oh - i think what mnaser is looking for is a tool to look for orphans in placement
15:27:02 mriedem e.g. orphaned providers or allocations for things that don't actually exist in nova anymore
15:27:05 mriedem like compute nodes and instances
15:27:09 mnaser well that's what im trying to write if i get a working client :p
15:27:29 cdent it's fun to "yes" and "no" to the same thing
15:27:31 mriedem personally i think that should live in nova-manage placement *
15:27:51 mordred mnaser: ah - that hasn't landed yet :(
15:27:53 mnaser i dont mind adding that in
15:28:02 mriedem but as i said yesterday, we can't know if the providers/allocations in placement are for nova things really without consumer types
15:28:16 mriedem although we can probably glean that from knowing if the provider has VCPU inventory
15:28:35 mordred oh - wait - I can't read - it did land
15:28:39 mriedem (1) is it root (2) does it have vcpu inventory, then it's likely a compute node
15:28:54 mnaser mordred: landed on the API side in rocky, i dont think sdk works around this somehow locally
15:29:35 mordred mnaser: yah - I do not believe it has any local workarounds. we could maybe make one? I think the best workaround would be to put in a placement_endpoint_override
15:29:39 mnaser mriedem: i was going to assume it was a compute node all the time (because in my use case it always is) but i guess adding those stuff can be trivial
15:29:56 mordred in your clouds.yaml or whatever - so that we don't try to run discovery and fail due to lack of status
15:30:16 mnaser im totally using env variables out of lazyness
15:30:22 mnaser so i assume OS_PLACEMENT_ENDPOINT_OVERRIDE ?
15:30:46 mordred yah
15:32:24 cdent mriedem: speaking of "does it have vcpu inventory" I made https://review.openstack.org/#/c/600016/ in response to digging in some of the placement-db using nova-manage and nova-status stuff
15:33:23 mnaser mordred: yay that worked, i'll workaround with that and then maybe i'll ask for help from mriedem to bring that into nova-manage
15:33:36 mordred coolio
15:33:40 mnaser merci beaucoup
15:33:44 mordred \o/
17:04:28 edleafe cdent: elmiko: dtantsur: https://etherpad.openstack.org/p/api-sig-newsletter is ready for your review

Earlier   Later