Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-01-09
15:35:00 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Extract getting connection from proxy into method https://review.openstack.org/629193
15:35:00 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Compute location properly in server https://review.openstack.org/626380
15:35:34 mordred Shrews, dtantsur: https://review.openstack.org/#/c/628969/ is green and fixes those volume tests properly
15:35:53 dtantsur cool, I'll try to get to it (crazy day though)
15:36:28 mordred dtantsur: I had one of those yesterday :)
15:37:47 mordred dtroyer: if you have a sec, https://review.openstack.org/#/c/629235/ is a devstack patch in service of dealing with the new system-scoped resources keystone is rolling out
15:37:59 openstackgerrit Merged openstack/openstacksdk master: Unpin dogpile.cache https://review.openstack.org/625759
15:39:58 Shrews mordred: what's up with the identity tests though?
15:40:27 Shrews mordred: http://logs.openstack.org/69/628969/7/check/osc-functional-devstack-tips/2fb4a33/testr_results.html.gz
15:40:49 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Use os-cloud instead of OS env vars for functional tests https://review.openstack.org/629243
15:40:50 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Use devstack-system-admin cloud for limit tests https://review.openstack.org/629203
15:41:03 mordred Shrews: that's the thing I'm working through with that ^^
15:41:07 mordred Shrews: and the devstack patch
15:41:12 Shrews gotcha
16:12:19 dtroyer mordred: +W on the devstack,
16:14:25 mordred dtroyer: sweet. thanks!
17:02:59 openstackgerrit Merged openstack/openstacksdk master: Skip v2 block-storage tests when service is not found https://review.openstack.org/628969
17:24:29 openstackgerrit Merged openstack/openstacksdk master: Stop running grenade-py3 https://review.openstack.org/629503
18:06:19 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Use devstack-system-admin cloud for limit tests https://review.openstack.org/629203
18:17:35 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Compute location properly in server https://review.openstack.org/626380
18:20:22 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Compute location properly in server https://review.openstack.org/626380
20:51:39 openstackgerrit Rajat Dhasmana proposed openstack/python-openstackclient master: Fix: Restore output 'VolumeBackupsRestore' object is not iterable https://review.openstack.org/624860
20:55:14 openstackgerrit Rajat Dhasmana proposed openstack/python-openstackclient master: Fix: Restore output 'VolumeBackupsRestore' object is not iterable https://review.openstack.org/624860
21:02:02 openstackgerrit Rajat Dhasmana proposed openstack/python-openstackclient master: Fix: Restore output 'VolumeBackupsRestore' object is not iterable https://review.openstack.org/624860
#openstack-sdks - 2019-01-10
00:13:37 openstackgerrit Bruno Haleblian proposed openstack/openstacksdk master: Bug : identity v3 Proxy role assignments only support instances. https://review.openstack.org/629690
02:17:56 openstackgerrit Kailun Qin proposed openstack/openstacksdk master: Add network segment range resource https://review.openstack.org/625381
08:36:28 openstackgerrit lijunjie proposed openstack/python-openstackclient master: Fix the misspelling of "argument" https://review.openstack.org/629785
08:42:41 openstackgerrit lijunjie proposed openstack/osc-lib master: Fix the misspelling of "argument" https://review.openstack.org/629790
12:19:59 openstackgerrit Jens Harbott (frickler) proposed openstack/python-openstackclient master: Use devstack-system-admin cloud for limit tests https://review.openstack.org/629203
12:29:51 frickler mordred: ^^ fixed some more bits. probably needs to be merged with the os-cloud patch anyway unless you want to fiddle with the jobs
14:17:27 bha_77 Hi all, I've some newby questions about repeated failures of my zuul checks, seem unrelated to my patchSet
14:21:24 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Use os-cloud instead of OS env vars for functional tests https://review.openstack.org/629243
14:21:46 mordred frickler: thanks! I fixed a pep8 error and then squashed, because yeah, you're right - otherwise it's too much to deal with
14:21:57 frickler bha_77: which patchset?
14:22:45 bha_77 629690
14:22:46 mordred bha_77: if it's python-openstackclient patches and failures related to keystone and limits, there is an issue that the patch I just pushed up *should* fix
14:23:51 mordred oh - that's an sdk patch - and that failure is new to me :(
14:24:30 frickler mordred: bha_77: indeed the failure is seen for other patches as well
14:26:41 mordred frickler: "yay"
14:27:28 frickler mordred: that doesn't sound very conviced to me, can you repeat with more effort?
14:28:47 mordred :)
14:32:11 mordred frickler: I was wondering if the devstack-system-admin patch might have broken something
14:32:26 mordred but the clouds.yaml for that patch looks fine -and I think more things would have been broken otherwise
14:34:10 frickler mordred: yeah, that failure to me seems too small for that. sadly I won't be able to dig deeper today, I can check tomorrow if you don't find anything today
14:37:53 mordred oh - wait
14:37:57 mordred I think it is related
14:38:16 mordred that test is getting an inventory for every cloud in clouds.yaml
14:41:27 bha_77 just let me know if I can help; or else just push a recheck...
14:44:03 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Restrict inventory test to devstack-admin https://review.openstack.org/629875
14:44:25 mordred bha_77: ^^ that *might* fix it - if it comes back green, we'll get it landed and you can recheck
16:00:48 edleafe API-SIG Office Hours have begun! Huzzah!
16:02:18 cdent oh hey
16:02:26 elmiko so, edleafe, dtantsur, i got a question from the sahara team yesterday about microversions =)
16:02:32 elmiko LOL
16:02:36 elmiko tosky: you around here?
16:02:40 tosky hi
16:02:42 elmiko hey
16:03:01 elmiko the sahara team is on the precipice of releasing their v2 api
16:03:10 elmiko it does not currently contain support for microversion
16:03:22 elmiko but they would like to know if it acceptable to add that support mid-cycle
16:03:35 elmiko tosky, check me if i've got that wrong
16:04:07 cdent since you have to opt in to use a later microversion it is safe to add them at any point
16:04:09 tosky that's correct, I'd just like to add that it may not be a problem in the end (the patch is in a better shape than what we originally though) but still, just to be sure
16:04:09 cdent "safe"
16:04:59 cdent and the "first" microversion is usually what's "now"
16:05:01 tosky the point is: if we merge the patch which declare APIv2 as stable today or tomorrow, would adding microversioning support before (say) M3 of this cycle break the API?
16:05:24 edleafe What cdent said. What you release now will always be the default unless otherwise requested
16:05:25 elmiko cdent: that was my position too
16:05:49 elmiko see tosky, no big deal =)
16:05:58 tosky oh, ok, thanks
16:06:18 elmiko yay, we're helping!
16:06:20 elmiko \o/
16:06:28 tosky out of curiosity, and a bit of history, why did cinder decide to bump to v3 instead of reusing v2, if their v3 is just v2+microversioning?
16:06:53 smcginnis tosky: The concern was that v2 did not have any awareness of microversions.
16:07:16 cdent and v2 had been around for a long time, yes?
16:07:24 smcginnis tosky: So conceivable someone could send a microversioned request to an older v2 deployment expencting a certain behavior, but not getting it.
16:07:35 smcginnis And having some unintended side effects that could be risky.
16:07:37 tosky oh, I see
16:08:10 smcginnis So it was decided with the addition of microversions we would also create a new v3 api that was identical, but guaranteed to be able to handle microversions correctly
16:08:12 tosky thanks, our case is a bit different because the first release of v2 in few months (two?) will have microversioning
16:08:24 smcginnis cdent: Yeah, v2 was around for quite a while.
16:09:06 edleafe smcginnis: so you didn't take advantage of the major version bump to get rid of any old cruftiness?
16:10:23 smcginnis edleafe: No, unfortunately. We weren't prepared to remove anything, and we did want to make the transition from v2 to v3 as easy as possible to make it more likely that we could drop v2 in the near future and be able to get to the point of only having one API.
16:10:49 edleafe smcginnis: fair enough
16:11:24 edleafe Although there will be clients looking to use v2 foreever...
16:11:34 edleafe forever, even
16:11:57 smcginnis It's at least marked as deprecated.
16:12:18 smcginnis I had planned on spending some time reaching out to different SDKs and helping them get over to v3, but no time.
16:13:03 elmiko edleafe: i think foreever was correct, at least the way it sounded in my head XD
16:13:27 cdent "but not time" (there it is again)
16:14:02 cdent I have a question about guidelines
16:14:12 cdent I have a couple of to do items for guidelines that need to be written
16:14:34 edleafe smcginnis: Well, even if every SDK updated to use v3 only, there are old copies in the wild being used.
16:14:38 mordred smcginnis: I really need to get a v3 layer in sdk
16:14:48 cdent But ennui has me doing a bit of a "does anyyone really read these things anymore?" so I'm not compelled
16:15:14 elmiko cdent: i can empathize
16:15:25 mordred smcginnis: the shade layer supports v3, but the sdk layer doesn't - and it's obviously stupid that this is the case
16:15:32 mordred but - yeah - time
16:16:01 mordred cdent: TAKE IT BACK!
16:16:09 cdent no backsies

Earlier   Later