Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-01-29
15:31:51 dtroyer and long-term split all sdk/osc bits out of python-*client libs that are going to be used by another service
15:32:48 dtroyer or we just containerize the control plane upstream and call it a day :)
15:32:52 mordred dtroyer: heh
15:39:46 amotoki this situation happens because both SDK and CLI stuffs are provided by a single deliverable. it makes things complicated
15:40:03 amotoki neutron just needs the python binding of desginateclient, but designateclient OSC plugin depends on osc-lib....
15:40:36 mordred amotoki: yes 100%
15:40:58 amotoki this discussion raises me again a question on where python binding should be implemented.
15:41:22 dtroyer that really doens't matter as long as we do not cross the client/server streams :)
15:42:00 dtroyer really, it was my failure to imagine that client libs with OSc bits in them would be used by servers too that let this happen
15:42:08 mordred amotoki: honestly I truly believe we should delete all of the python-*client bindings - but that's a much bigger engineering effort as we'd have to unwind or rethink a ton of things we don't really have the bandwidth to rethink these days
15:42:15 dtroyer putting the OSc bits into a separate repo solves it
15:42:20 mordred dtroyer: ++
15:42:36 mordred to the osc bits in separare repo
15:42:51 amotoki yeah, but it needs project teams need to maintain more repos..
15:43:36 mordred dtroyer, amotoki: https://review.openstack.org/#/c/538951/ and then https://review.openstack.org/#/c/538695/ depends-on it
15:46:05 amotoki i hope it works
15:46:20 openstackgerrit Stephen Finucane proposed openstack/cliff master: sphinxext: Warn if namespace or command pattern invalid https://review.openstack.org/510913
15:47:30 mordred amotoki: me too
15:48:22 dtroyer I left a comment including the short- and long-term intentions
15:49:33 mordred awesome
15:50:08 mordred dtroyer: it might be worth talking through this whole thing at the PTG, too
15:53:15 dtroyer mordred: yeah, either re-affirm the assumptions or choose to change them...
15:53:24 mordred yup.
15:53:48 mordred dtroyer: btw - I think we're going to need a patch for osc master too - poking at that now
16:00:56 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Use find_ip from openstacksdk https://review.openstack.org/538958
16:13:56 mordred dtroyer: I also pushed up this to stable/pike: https://review.openstack.org/538963 Use find_ip from openstacksdk ... if it works and we cut a 3.12.1 release I think we can avoid the grenade change - I'll leave it to your judgement as to which thing you find preferrable
16:15:25 mordred dtroyer: I also think I *might* have an idea of a patch to make to sdk that could deal with the issue as well ... experimenting with that now
16:18:09 dtroyer That cleanup to OSC should happen either way so if it helps we'll push it in
16:19:40 mordred awesome
16:20:04 mordred maybe between the OSC cleanup and the sdk patch I'm working on now we can avoid the short-term grenade hacks
16:48:02 openstackgerrit Monty Taylor proposed openstack/python-openstacksdk master: Provide compatibility for people passing raw sessions https://review.openstack.org/538968
16:48:44 mordred dtroyer, amotoki: ok - I *think* that ^^ will actually fix the current issue without the grenade or osc patches ... the patch adds the neutron-grenade job just to be sure
16:49:07 mordred if that patch comes back green, then we should be able to land it and cut an sdk point release and have all the stuff work
16:50:17 mordred (and if it works, I'll make a followup patch that adds the call in to all of the places it needs to to be called
17:22:33 dtroyer mordred: do we have any idea if anything that isn't OSC does that Session thing?
17:27:06 mordred dtroyer: looking in heat right now to check
17:27:42 mordred dtroyer: it doesn't look like heat does
17:28:01 openstackgerrit Monty Taylor proposed openstack/python-openstacksdk master: Provide compatibility for people passing raw sessions https://review.openstack.org/538968
17:29:43 mordred dtroyer: so we could just call the osc patch a good enough fix
17:29:59 mordred dtroyer: I think I'm mostly just shotgunning all of the possible options I can think of right now :)
17:30:33 dtroyer sure, I'd like to avoid more special cases that will be around forever in the SDK if we can
17:31:10 mordred dtroyer: totally agree
18:07:38 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Use find_ip from openstacksdk https://review.openstack.org/538958
19:17:44 Bar_ dtroyer, hey, When is the next osc-lib package is expected to be released?
19:22:21 dtroyer Bar_: We just did what becomes the queens/stable release a week or so ago, nothing is queued up that I'm aware of
19:24:42 Bar_ dtroyer, I have proposed https://review.openstack.org/#/c/531025/ earlier this month, but it didn't make the cut. I have another patch that is dependent on that, though it is not urgent, I wanted to know what time table could i expect.
19:30:44 dtroyer That merged, but yes, not before 1.9.0 was released, gotcha
19:33:12 dtroyer Bar_: is next week soon enough? I'd like to hold off adding tot he release teams work (as small as this is) until the gate issues/backlog is cleared
19:35:58 Bar_ dtroyer, totally fine. Not urgent at all. I suspected it might take months, that's why I asked.
19:36:11 Bar_ am I correct to expect it to be v1.9.1?
19:36:27 dtroyer no, we also merged some global requirements, which force a minor rev
19:36:33 dtroyer it'll be 1.10.0
19:38:12 Bar_ dtroyer, I see. thanks. By the way, it is besides the point, but maybe we should reconsider the reliance on testtools, it hasn't seen meaninful updates for almost a year now.
19:38:54 Bar_ My patch only suppresses exceptions of functionality that is natively supported by unittest
19:39:55 Bar_ testtools breaks that functionality, and there's not much hope there.
19:57:42 mordred Bar_: subTest does not exist in python2 - it's only in python3.4 and above - have you tried testscenarios instead?
19:59:04 mordred http://git.openstack.org/cgit/openstack/python-openstacksdk/tree/openstack/tests/functional/cloud/test_devstack.py#n25
19:59:07 Bar_ mordred, sorry, I'm unfamiliar with testscenarios . We don't use it in the relevant repo
19:59:08 mordred is an example
20:00:13 mordred line 25 is key, then the scenarios attribute on line 32 lists a list of scenarios with a name for the scenario and a dict of attributes to add to the test for each scenario
20:00:33 mordred load_tests then explodes that out during unittest discovery listing to a test named for each scenario
20:00:50 mordred which means they can be scheduled across test runner backends for multi-process/parallel testing
20:02:57 mordred Bar_: if you look at http://codesearch.openstack.org/?q=testscenarios&i=nope&files=&repos= you can see it's used fairly extensively across openstack -so before we were to go trying to solve the same problem using a different tech, I'd personally like to figure out if there is a benefit to using subTest over testscenarios
20:03:02 Bar_ mordred, subtest fails with PY35 when inheriting from testtools.
20:04:28 mordred Bar_: right. but what I'm saying is that rather than trying to convince openstack to move off of testtools, you might have better luck just using testscenarios which works with both python2.7 and python3.5
20:04:49 Bar_ mordred, cool
22:25:26 mordred dtroyer: https://review.openstack.org/#/c/538963/ failed its functional tests - but the error is seems weird
22:25:28 mordred dtroyer: http://logs.openstack.org/63/538963/2/check/osc-functional-devstack/c475bfb/job-output.txt.gz#_2018-01-29_22_22_13_041554
22:25:37 mordred dtroyer: does that make the senses to you?
22:35:19 dtroyer mordred: I've never seen that before…
22:37:41 mordred dtroyer: I just pushed up https://review.openstack.org/539032 Enable cinder services explicitly
22:37:48 mordred dtroyer: just to see if that helps
22:38:04 mordred dtroyer: as we seem to be getting http://logs.openstack.org/63/538963/2/check/osc-functional-devstack/c475bfb/job-output.txt.gz#_2018-01-29_22_20_41_586456
22:38:39 mordred dtroyer: it does not make any sense to me why that would have stopped working though
22:42:21 mordred dtroyer: looking at git logs it doesn't seem like anything relevant would have changed since the last time that job worked :
22:42:23 mordred :(
23:07:55 dtroyer mordred: sorry, endless-phone-syndrome
23:08:17 dtroyer I don't recall ever seeing that level of Cinder issue, usually it's races with resources. this is different
23:10:21 dtroyer FWIW, I just +W 538958
23:11:02 mordred woot
#openstack-sdks - 2018-01-30
00:09:31 adriant mordred: as part of the sdk stuff you were going to potentially make some nice constructor functions for people using it without an underlying clouds.yaml
00:10:57 adriant there is something that sort of lets you do that, but it... still looks for underlying cloud.yaml unless you explicitly tell it not to or something.
00:11:07 adriant am trying to find where that doc was
00:16:40 adriant here: https://github.com/openstack/python-openstacksdk/blob/master/doc/source/user/connection.rst#getting-a-connection-from-python-arguments-avoiding-cloudsyaml
00:17:39 adriant you were talking about making that into a nicer callable constructor that does that, without all the pointless boiler plate
00:20:56 mordred adriant: yes indeed. I'm just now AFKing - but thanks for the reminder I can hit that first thign in the morning
00:21:14 adriant mordred: sweet, thanks :)
00:21:38 adriant and are they any docks on doing that type of thing and saying what versions of stuff you want?
00:22:09 adriant since sometimes you do want to use a specific version of a given services API when you setup something like that in code
00:22:13 adriant ...
00:22:18 adriant docs* not docks
00:23:50 adriant I'll be around tomorrow and can test/review as needed!
00:30:08 mordred adriant: the docs need to be cleaned up - the tl;dr is that you can pass args like service_type_api_version to get_one_cloud (or to Connection itself) ... or via env vars ..
00:30:53 mordred adriant: so - for instance, OS_COMPUTE_API_VERSION='2' or compute_api_version='2'
00:31:01 adriant ideally, I would love a constructor function that is basically: explicitly ignore clouds.yaml, envvars, etc, and ONLY use what I'm giving it
00:31:23 mordred adriant: nod - can do
00:31:54 adriant a consumer of that is 100% certain of exactly where the config data it gets is coming from
00:32:13 adriant which is what I'd want for using it in services type stuff
00:32:40 adriant and cool, if you can easily enough supply what versions of a given service you need that makes it ideal
00:39:44 mordred adriant: woot. for now it's BASICALLY "config = openstack.config.OpenStackConfig(load_yaml_config=False, envvar_prefix='GARBAGE').get_one(region_name='my-region', auth=dict(auth_url='http://foo.example.com', username='', password=''), compute_api_version='2', compute_interface='public') ; conn = openstack.connect(config=config)"

Earlier   Later