Earlier  
Posted Nick Remark
#openstack-sdks - 2017-01-11
15:16:29 stevemar i am negative on that
15:16:37 stevemar untested (mostly)
15:17:15 dtroyer roger that… agreed
15:17:20 stevemar dtroyer: want to add a functional test job to osc-lib before releasing?
15:17:29 stevemar or are you comfortable enough to release?
15:17:37 stevemar i think the changes were mostly additive
15:17:44 dtroyer depends on how long it takes to get it added :)
15:18:25 dtroyer I made those compat-changes, the case I am concerned about we get in the dsvm jobs (using env vars for auth)
15:18:42 dtroyer rather, using having the comat bits in osc-lib and also in osc
15:19:08 dtroyer in one case it's doing double work and is not (should not be) harmful
15:19:27 stevemar dtroyer: looks like only one thing is failing with sdk 0.9.12 -- http://logs.openstack.org/50/418650/4/check/gate-osc-dsvm-functional-ubuntu-xenial/abbb8d4/testr_results.html.gz ?
15:20:03 dtroyer woo!
15:20:15 dtroyer qos rule type...
15:20:37 dtroyer is anyone workign on that (I just skimmed the overnight scrollback)
15:20:52 dtroyer I'll jump on it after adding the func tests and releasing osc-lib
15:20:53 stevemar dtroyer: for the functional job in osc-lib... it should test with master osc-lib and master osc?
15:21:24 dtroyer we need that combination somewhere, but I was thinking master osc-lib with released osc
15:21:42 dtroyer we've found that dsvm jobs are insufficient for validating we don't break anything
15:21:47 stevemar right
15:22:28 stevemar dtroyer: i did the combination before but i don't recall how to do it, may take a few hours
15:22:55 dtroyer release osc + master osc-lib would be the default, right?
15:23:05 dtroyer ie, no extra work
15:29:08 stevemar i think so, but we'll need to run the functional tests *in* the osc repo, so i'm not sure how that works :\
15:29:34 dtroyer ugh, right
15:31:04 stevemar dtroyer: and we'll need to probably run the master version of those tests?
15:31:26 stevemar dtroyer: you know, we could have another job in the OSC gate that tests osc-lib master and osc master
15:31:39 stevemar instead of osc-lib release and osc master
15:31:49 stevemar that'll be *really* easy
15:31:53 stevemar i think
15:32:11 dtroyer lets do it that way… in gate, check or experimental so it can go on-demand?
15:32:15 stevemar just copy+paste the old job and force it to install osc-lib in master
15:32:28 stevemar non-voting check for now i think
15:33:28 dtroyer kk
15:37:28 stevemar dtroyer: aside from copying https://github.com/openstack/python-openstackclient/blob/master/openstackclient/tests/functional/post_test_hook.sh and the 'functional' job
15:37:33 stevemar sorry
15:37:52 stevemar dtroyer: let me tell you in steps what i was going to do, see if you can think of a simpler way
15:38:00 dtroyer ok
15:38:25 stevemar 1) copy the functional job here, but call a different post_test_hook.sh, maybe post_test_osc_lib_hook.sh ? https://github.com/openstack-infra/project-config/blob/e172a5e4107f1774a77e212d82218086ed39329e/jenkins/jobs/osc.yaml#L2
15:38:58 stevemar 2) copy https://github.com/openstack/python-openstackclient/blob/master/openstackclient/tests/functional/post_test_hook.sh to the new name and have it clone and install osc-lib master
15:39:09 stevemar 3) make money
15:40:14 stevemar i could get fancy and maybe set an ENV variable somewhere that says we're using osc-lib from master, but ... i know this will work
15:41:28 dtroyer I don't know the job stuff well enough to know the shortcuts, your plan sounds like it will work
15:41:38 dtroyer should we commit the shell script first?
15:41:43 dtroyer also, stable jobs?
15:43:42 stevemar the shell script will be in osc no?
15:43:53 dtroyer yes
15:44:05 stevemar oh i thought you were asking about getting that in before osc-lib is released
15:44:07 stevemar ignore me
15:44:15 dtroyer should we also do sdk? can we do both in the same job?
15:44:21 dtroyer so many questions!
15:45:16 dtroyer a) I was thinking we'd want the new *-hook.sh merged before defining the job that calls it
15:45:43 dtroyer b) I'm still thinking through how this affects (or if it should?) stable jobs
15:46:09 dtroyer c) we should also do the sdk this way, can we do both in the same job in a sane manner?
15:47:32 stevemar dtroyer: i think we can
15:49:58 dtroyer o-c-c too?
15:50:05 dtroyer how much can we add??? :)
15:50:15 dtroyer those are the three primary break-risk libs for OSC
16:27:41 dtroyer stevemar: I just got the same results in my local OSC functional tests (same devstack-related failures) for both current and master osc-lib. Are you OK with pushing the release now or do you still want to wait intil the new job is in?
16:31:39 stevemar dtroyer: i'm OK with pushing
16:32:11 stevemar dtroyer: i'm trying to figure out the pip command to install the sdk
16:32:24 briancurtin pip install openstacksdk
16:32:35 stevemar hehe
16:32:50 stevemar briancurtin: from master instead?
16:32:58 briancurtin what?
16:33:08 stevemar i was thinking ... pip install -q -U -e "git+https://git.openstack.org/python-openstacksdk/openstacksdk.git#egg=openstacksdk"
16:33:34 briancurtin that probably works. or maybe egg=openstack. i can’t remember exactly what goes in the egg part
16:33:58 stevemar briancurtin: thats where i'm stumbling :)
16:34:20 briancurtin the PyPI package name is openstacksdk but the package that python itself deals with is called openstack, so maybe egg=openstack
16:35:12 dtroyer looks like egg=python_openstackclient is used for that case, so pypi package name?
16:35:24 dtroyer with '-' -> '_' mapping
16:36:06 stevemar dtroyer: sorta, pip install -q -U -e "git+https://git.openstack.org/openstack/osc-lib.git#egg=osc_lib" works for osc-lib
16:36:37 dtroyer so I'd expect #egg=puthon_openstacksdk to be the magic
16:37:10 dtroyer s/pu/py/
16:38:53 dtroyer pip install -q -U -e "git+https://git.openstack.org/openstack/python-openstacksdk.git#egg=python_openstacksdk"
16:38:59 dtroyer appears to have worked for me
16:40:21 stevemar *smh* i had an extra openstack in there
16:41:14 reedip_outofmemo briancurtin : ping
16:41:22 briancurtin reedip_outofmemo: what’s up
16:42:12 reedip_outofmemo briancurtin : hi , busy ?
16:42:20 openstackgerrit Steve Martinelli proposed openstack/python-openstackclient: add support for running tests with master dependencies https://review.openstack.org/419032
16:42:23 briancurtin reedip_outofmemo: no, what’s up
16:42:26 stevemar dtroyer: ^
16:42:30 reedip_outofmemo briancurtin : it was related to https://review.openstack.org/#/c/418729/
16:42:42 briancurtin yeah, what is the question?
16:43:13 reedip_outofmemo briancurtin : earlier, quota show for openstackclient ( before 0.9.12 version ) was working smoothly
16:43:29 reedip_outofmemo with 0.9.12, there has been a change and quota show now fails
16:43:39 openstack Launchpad bug 1655537 in python-openstackclient "Cannot see Network quota using "openstack quota show"" [Undecided,New] - Assigned to Reedip (reedip-banerjee)
16:43:39 reedip_outofmemo briancurtin :https://bugs.launchpad.net/python-openstackclient/+bug/1655537
16:44:23 reedip_outofmemo briancurtin: the reason is though the Compute and Volume quotas are returned as dict, network quota is returned as an object
16:44:23 briancurtin reedip_outofmemo: there was no change in 0.9.12, i think it was in 0.9.11, but this is an OSC problem and not an SDK problem
16:44:48 reedip_outofmemo briancurtin : ok , one question
16:45:03 reedip_outofmemo briancurtin : is the compute client and volume client part of Openstack SDK ?
16:45:09 briancurtin reedip_outofmemo: openstacksdk hasn’t explicitly returned dictionaries ever, though some time ago it did return objects that can act like dictionaries. compute hasn’t done that for probably 8 months
16:45:11 reedip_outofmemo briancurtin : like Network client
16:45:32 briancurtin reedip_outofmemo: I’m not sure, i don’t work on OSC. i think OSC only uses openstacksdk for the network related commands though, not for compute and volume
16:46:04 reedip_outofmemo stevemar : any suggestions related to above query ?
16:46:17 dtroyer reedip: briancurtin is correct re compute and volume quotas
16:46:41 reedip_outofmemo dtroyer : ok, so sdk is used only for Networks??????
16:46:54 dtroyer the root problem is that OSC was not ready for the 0.9.11 changes in the SDK because our functioanl tests were producing false positives for a time
16:47:00 dtroyer reedip: yes

Earlier   Later