Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-12-19
20:19:37 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Start using direct REST in normalize tests https://review.openstack.org/626379
20:19:46 mordred Shrews: ok. I think that should take care of the issues
20:20:08 mordred tobiash: ^^
20:22:06 mordred Shrews: while I've got you here: https://review.openstack.org/#/c/626058/ is a copy of stuff clarkb did for nodepool
20:23:54 mordred slaweq: if you have a sec, another neutron patch for you: https://review.openstack.org/#/c/625381/3
20:25:53 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Drop self.conn from base.TestCase https://review.openstack.org/625115
20:37:18 slaweq mordred: looking
20:44:37 slaweq mordred: commented
20:45:12 slaweq mordred: basically this feature has only spec merged so far and I'm not sure if it's good time to merge it
20:58:24 mordred slaweq: cool- thanks! (This is why it's good to defer to subject matter experts :) )
21:01:19 slaweq mordred: yes, I agree :)
21:38:52 openstackgerrit Merged openstack/openstacksdk master: Import code for building ironic-compatible configdrives https://review.openstack.org/624441
21:53:55 openstackgerrit Merged openstack/openstacksdk master: Turn off unneeded devstack services https://review.openstack.org/626058
#openstack-sdks - 2018-12-20
00:33:51 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Drop self.conn from base.TestCase https://review.openstack.org/625115
00:33:51 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Start using direct REST in normalize tests https://review.openstack.org/626379
00:33:52 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: WIP Compute location properly in server https://review.openstack.org/626380
01:27:50 openstackgerrit Merged openstack/openstacksdk master: Properly munch for resource sub-dicts https://review.openstack.org/625923
02:07:19 openstackgerrit jacky06 proposed openstack/os-api-ref master: Remove support for py34 https://review.openstack.org/626300
06:10:02 openstackgerrit Dou Rui Yuan proposed openstack/python-openstackclient master: Remove testr.conf as it's been replaced by stestr https://review.openstack.org/626492
11:22:54 frickler shade-ansible job looks broken for a couple of days, did anyone look into that yet? http://zuul.openstack.org/builds?job_name=shade-ansible-functional-devstack
11:30:04 frickler mordred: I rebased https://review.openstack.org/526115 for you, seems that that would still be relevant to have as test coverage
12:53:31 frickler mordred: this pins to ansible==2.5.0, which seems to have a broken "user" module functionality on bionic, so this is fallout of the devstack bionic change. pinning to "ansible<2.6", which seems to have more of the intended effect anyway, solves the issue on my test machine. https://review.openstack.org/#/c/570680/1/tox.ini,unified
12:55:47 openstackgerrit Jens Harbott (frickler) proposed openstack-infra/shade master: Fix ansible stable pin in tox test https://review.openstack.org/626568
12:56:14 frickler mordred: Shrews: ^^ that should fix the test failures
13:16:42 openstackgerrit Rajat Dhasmana proposed openstack/python-openstackclient master: Fix: Restore output 'VolumeBackupsRestore' object is not iterable https://review.openstack.org/624860
13:22:21 mordred frickler: awesome! thanks
13:46:34 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: WIP Compute location properly in server https://review.openstack.org/626380
13:46:34 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Drop self.conn from base.TestCase https://review.openstack.org/625115
14:51:33 openstackgerrit Jens Harbott (frickler) proposed openstack/python-openstackclient master: Add osc repo to the base job definition https://review.openstack.org/626590
14:51:58 frickler mordred: ^ seems this is needed for the devstack change
14:56:43 mordred frickler: +A - I think that's a clear enough change
15:00:24 openstackgerrit Merged openstack/openstacksdk master: Start using direct REST in normalize tests https://review.openstack.org/626379
15:18:21 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Add possibility to override base_path for resource operations https://review.openstack.org/621153
15:21:55 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Add possibility to override base_path for resource operations https://review.openstack.org/621153
15:45:09 openstackgerrit Merged openstack-infra/shade master: Fix ansible stable pin in tox test https://review.openstack.org/626568
15:48:08 Shrews mordred: remind me why our ansible tox test is pinned?
15:50:10 Shrews oh, that's shade
15:54:24 mordred Shrews: yeah- and it was to test master of shade against stable of ansible
16:00:40 edleafe he last API-SIG Office Hour of 2018 has begun
16:00:47 edleafe *The last
16:01:23 elmiko hello/
16:01:47 edleafe hola
16:02:01 elmiko did you see the email that Artem sent to the list?
16:02:08 elmiko i think he may join us today, not sure though
16:02:14 gtema Hi, I am here
16:02:20 elmiko hey!
16:02:21 elmiko welcome =)
16:02:25 gtema thanks
16:02:46 elmiko so, as i mentioned in the email thread, we don't have a standing "meeting" anymore just these office hours
16:02:47 edleafe Hi gtema
16:03:14 gtema edleafe: hi
16:03:15 elmiko that said, if you would like to represent the sdk side of the house within the api-sig then i am all for it =)
16:03:28 gtema elmiko: it's not a problem
16:03:55 mrhillsman o/
16:03:56 gtema from what I see dtantsur is also part of API-SIG and an SDK core
16:04:07 elmiko yes
16:04:08 edleafe yes, he is
16:04:20 elmiko hey mrhillsman
16:04:57 elmiko gtema: i would imagine that we will continue with the office hours pattern in the near term, but if the need arises for us to organize more (especially around sdk work), then it seems perfectly acceptable for us to discuss starting a meeting time again
16:05:15 gtema sure, no problem
16:05:44 gtema until the Jan there would not be any real work anymore ;-)
16:06:03 edleafe gtema: what general time zone are you in?
16:06:09 elmiko i'm not sure if you or mrhillsman have any ideas about information you might want up on the api-sig wiki or specs site (i know we have lots of sdk stuff up on the web), but it would be great to create some linkages and maybe add something about sdks to the sig charter
16:06:16 gtema Germany (GMT+1/2)
16:06:41 edleafe ok, so closer to dtantsur's schedule
16:06:45 gtema yupp
16:06:47 elmiko gtema: yeah, no real work until after holidays. i was hoping we could do a meet and greet today =)
16:06:57 gtema sure
16:07:46 elmiko great, i look forward to the new year and hopefully getting some sdk activity in the sig
16:07:50 mrhillsman i am utc-6 until march 10, 2019 then i'll be utc-5
16:08:18 elmiko ack
16:08:46 elmiko mrhillsman or gtema, did either of you have any questions or ideas that we might consider for the next time we all meet up?
16:09:28 gtema I don't. But I agree there should be some plan on what to do
16:10:01 gtema what we want to achieve is clear, but what would be the steps is not
16:10:08 elmiko ++
16:10:13 mrhillsman i pretty much laid out where i stand on things in the original post; just not particularly versed at laying out the steps
16:10:23 mrhillsman yes exactly
16:10:26 edleafe Is the general idea to come up with a validation suite of tests to run against the various SDKs?
16:11:33 gtema I understand it as yes, but also to laying out results of validations to public. Isn't it mrhillsman?
16:11:33 mrhillsman https://ethercalc.org/q4nklltf21nz
16:12:11 mrhillsman that is the current items working with gophercloud we were able to come up with
16:12:47 mrhillsman the key being the outcome/scenarios in the first column
16:12:57 elmiko looks like a decent starting point
16:13:09 mrhillsman someone getting that to https://www.openstack.org/software/project-navigator/sdks
16:13:28 edleafe mrhillsman: Sure, those are reasonable expectations for any SDK. What I'm wondering is if there is any thought about something that could be run for all languages. FWIW, I have no idea how to achieve that :)
16:14:30 mrhillsman chris hoge tossed out the idea of a state machine - i am not sure what that is
16:14:34 mrhillsman but my understanding is
16:15:44 openstackgerrit Merged openstack/openstacksdk master: Drop self.conn from base.TestCase https://review.openstack.org/625115
16:16:16 mrhillsman create VM with devstack, drop SDK on it, check state of cloud, run SDKs acceptance tests, check state of cloud, validate against expected scenarios, but yes, no actual implementation has been tried
16:16:56 elmiko that sounds reasonable, i imagine some sort of zuul scenario for testing all the different permutations
16:17:09 mrhillsman i think because every SDK is different, it would be quite difficult to have something run for all languages
16:17:45 elmiko i would think you would need to make explicit tests for each sdk, is this something that the individual sdk teams might take on or would there need to be an "sdk test master" or something?
16:18:02 gtema that's clear, that one size fits all does not exist here, but I think the acceptance should try to test same things
16:18:09 elmiko right
16:18:13 edleafe mrhillsman: there would also have to be many intermediate checks, not just end state
16:18:53 mrhillsman i think there could be parameters around the end state
16:19:41 mrhillsman like for scenario create VM which links to read VM could be create VM with name cloud and then read (check) for VM with name cloud
16:19:55 edleafe One thing I would also like to see: for each action in the validation suite, a link to the docs for that SDK that explain how to do that particular action
16:20:17 mrhillsman +=
16:20:21 mrhillsman ++

Earlier   Later