Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-04-11
11:03:21 cdent but whether the plugin can generate the right args and process responses properly
11:31:28 dtroyer cdent: if my barely-awake brain is parsing that story, the OSC functional test may not be quite be what you are looking for: https://opendev.org/openstack/python-openstackclient/src/branch/master/openstackclient/tests/functional/base.py#L29 still uses subprocess.
11:31:43 dtroyer but the unit tests in https://opendev.org/openstack/python-openstackclient/src/branch/master/openstackclient/tests/unit/test_shell.py may be closer to what you want
11:32:59 dtroyer that calls the shell object in-process some of the magic is actually in osc-lib
11:34:44 cdent dtroyer: I think what I'm after is awareness of the method that receives some form of sys.argv, but based on what you are saying it sounds like that might be obscured under "stuff"
11:35:45 cdent like, somewhere there is a top level main(args), and I want to call that
11:35:56 cdent but I suspect I can't...
11:59:51 openstackgerrit Tobias Rydberg proposed openstack/openstacksdk master: Removing region La1 from the list of regions. https://review.openstack.org/651770
12:21:40 dtroyer cdent: you can, it is in there, I thought the functional tests worked that way until I looked… but the unit test_shell bits do exactly that, but have the back-end mocked out. I've got a meeting at the top of the hour, I'll try to suss out a simple example after that...
12:22:31 cdent thanks dtroyer . my first glance at the links you provided above gave me mego, so I wasn't too sure
12:26:54 dtroyer and after thinking about it a bit, it may be just as straightforward to write a new top-level cliff app.App that just calls your command handlers directly, unless you need the shell parsing for some reason…
12:27:10 dtroyer you know, OSCAppFixture or something...
13:07:58 gtema mordred: I have a problem with setting "unknown" properties under "properties" in the image service. By default only string values are accepted (no dict)
13:08:36 gtema so there is no good way around of storing everything in the root of the Image
13:35:15 mordred gtema: oh - I didn't mean setting unknown properties under properties remotely ... I meant making 'properties' on the Resource object be where unknown key/values in the root of the resource go
13:37:17 mordred in the case of Image, if someone did i = Image(id) ; i.properties['foo'] = 'bar' ; i.commit() then we'd pull the things out of properties and submit them remotely as part of the body payload
13:52:00 mordred gtema: but that still might be crap of course
14:54:28 cdent pas-ha, dtroyer : I seem to be making some progress (i'm access shell.main() with my own args) but I'm encountering some difficulties with trying to make use of noauth from those args. Can you give me an example of how a normal command line, using noauth, would be constructed?
15:10:33 gtema mordred: yeah, this is also "crappy". I will try something similar to change with dynamic properties, but only local in Image
15:10:59 mordred gtema: it's a hard problem with no *good* answers :)
15:11:07 gtema so basically in the image accept everything and create a "runtime" attribute out of it (strict string)
15:16:48 gtema mordred: btw I was a bit surprised with one your change where you turned off normalization (https://review.openstack.org/#/c/650903/)
15:17:19 gtema do you intend to return simle Munches from the resource in the cloud layer? If yes I would definitely have much less problems with Image refactor
15:17:30 mordred gtema: well, the idea there is to make the underlying Resource object have the correct data model
15:17:58 gtema that's good. But what about Image? Probably it will not work good here, or?
15:18:04 mordred since Resource is a subclass of dict, it can be used just the same
15:18:21 mordred I'd like for us to get the Resource objects good enough to be able to do that
15:18:25 mordred if we can
15:18:47 gtema should we then try it for Image?
15:19:06 mordred I think so - yes - but this is where the hard problem you're working on comes in to play
15:19:37 gtema yes, those dynamic things will be in the root then
15:19:41 mordred because in the normalize/cloud layer, unknown server-side properties all get plopped into a general "properties" dict on the main dict
15:19:51 mordred so if we move them to the root, it'll break cloud-layer users
15:20:04 gtema arghh
15:20:08 mordred :)
15:20:25 mordred it's good to start with the hardest examples - everything else will be easy after Image :)
15:20:44 gtema ok, then somehow keeping such things really a "rest"
15:21:09 gtema yeah. Ok, then I'm diving for next couple of days for next round with Image :D
15:21:22 mordred I believe you can defeat it!
15:21:35 gtema sure, will take some time though
15:29:05 dtroyer cdent, you may be able to just bypass all of that using —os-token (with whatever your fixture wants to find in x-auth-token:) and —os-url (with placement endpoint)
15:29:30 cdent ah dtroyer, yeah, if that works that would be much better
15:29:56 dtroyer the more correct way of course is a null ath plugin, I have to re-constitute how to so that in my head
15:31:08 dtroyer the above options fall over when the particular command needs to see a service catalog for other reasons…
15:31:50 cdent yeah, in my case a service catalog ought to be unnecessary
15:32:00 dtroyer I was hoping that to be the case
15:38:06 cdent dtroyer: --os-token and --os-url gets me a bit closer, thank you
15:57:02 cdent new question dtroyer: in the same process I'm using different os-url (they are dynamically created) with each call, but a second request is using the first url when trying to make an http connection. Presumably there's a cached sesssion or similar somewhere. Can I flush that easily?
16:00:01 edleafe One thing you can't flush away easily: the API-SIG Office Hour!
16:00:11 elmiko lol
16:00:25 dtroyer cdent: I _think_ all state is ultimately held by the cliff App object, or decendant, so here the Shell object. need to verify
16:00:26 edleafe <sfx> trumpets playing </sfx>
16:00:52 dtroyer cdent: you are causing me to retrieve information from 3rd level offline storage… :)
16:01:26 cdent thanks dtroyer. sorry for so many question, part of it is that there are at least 6 packags involved in making an eventual request, it seems, and I'm not sure where to look or trace
16:01:54 dtroyer yeah, it is messy for sure.
16:04:10 cdent If I can get past this hump I think I'm there
16:04:19 cdent <- famouslastwords
16:05:33 edleafe cdent: I was just thinking the same thing
16:08:53 elmiko lol
16:09:28 dtroyer So, cliff.app.App (therefore OpenStackShell) owns a CommandManager instance which in turn owns all of the client objects and sdk objects that contain Session/Adapters, so each combination of —os-url/—os-token could have its own OpenStackShell safely. Now that I write that I think your real need is to just be able to change —os-url properly, right?
16:11:56 dtroyer oh, wrong above, s/CommandManager/ClientManager/
16:12:19 cdent dtroyer: as far as I can tell I'm creating a new OpenStackShell for each test and in each test I'm using a different --os-url. However, in a second test that --os-url, though present in the args, is not the thing to which an http connection is made. the value of the previous --os-url is used instead
16:13:08 dtroyer ok, then something is being passed by reference as it were… I don't think I've ever tried that althought I would have expected it to work
16:19:26 dtroyer it may be how we store the actual client objects in ClientManager. They are created through a descriptor and may not be re-created as expected… https://opendev.org/openstack/osc-lib/src/branch/master/osc_lib/clientmanager.py
16:23:14 cdent hmmm
17:01:28 elmiko take care edleafe dtantsur|afk o/
17:01:35 edleafe later dude
17:26:09 cdent dtroyer: for reference, this seems to get me what I want: http://paste.openstack.org/show/749206/
17:26:28 cdent but only maybe, now on to the next thing :)
17:27:23 cdent damn, actually, maye not
17:27:28 cdent it was a ruse!
18:07:44 openstackgerrit Merged openstack/openstacksdk master: Removing region La1 from the list of regions. https://review.openstack.org/651770
18:25:39 dtroyer cdent: and ok, I see where we have the globals… that descriptor is set in the class not in the instance. client.ClientManager gets the return from ClientCache, but it is a class var not an instance var. doh!
18:26:12 cdent dtroyer: yeah. I'm struggling to untangel that
18:26:20 dtroyer fortunately that is OSC code, not osc-lib or cliff, so theoretically you can do the right thing there with your version of that code
18:27:07 dtroyer really all you need is a ClientManager to hang your placement client object on, if even that. Our unit tests call the command handlers directly with the help of a few fakes
18:27:09 cdent what i've done so far is just hack ClientCache to always return a new instance
18:27:24 cdent just to get me on to some other errors
18:27:25 dtroyer that would work too
18:27:39 dtroyer or even eliminate it and just make a new instance there directly
18:27:50 dtroyer the reason for the cache is to reduce module loading
18:27:57 cdent I'll need to come back round and clean that out and put a different client in palce
18:28:04 cdent but I keep falling in rabbit holes :)
18:28:42 dtroyer around here thats like stumbling into a prairie dog town… ankle-breaking city
18:28:52 dtroyer holes everywhere
19:09:48 openstackgerrit Merged openstack/keystoneauth master: Update auth plugin name list in document https://review.openstack.org/648920
22:02:09 cdent dtroyer: finally got it by doing a mock/monkeypath of __get__ on ClientCache. Is the least invasive option.
#openstack-sdks - 2019-04-12
11:50:32 openstackgerrit Jens Harbott (frickler) proposed openstack/keystoneauth master: DNM: Hard override admin interface to public https://review.openstack.org/652046
13:51:38 mordred frickler: ^^ wow, still chasing that issue?
13:57:20 frickler mordred: yes, I can't seem to find the right trigger. this is what from my understanding should fix it, but it is still failing both unit tests and running with devstack https://review.openstack.org/651790
13:57:37 frickler mordred: if you could help with digging into that, that would be great
14:17:53 openstackgerrit Ilya Shakhat proposed openstack/keystoneauth master: [WIP] Add OpenTracing instrumentation https://review.openstack.org/652080
14:18:26 openstackgerrit Ilya Shakhat proposed openstack/osc-lib master: [WIP] Add OpenTracing instrumentation https://review.openstack.org/652081
14:19:22 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add logger to Proxy object https://review.openstack.org/650901
14:19:23 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Use resource layer for compute flavors https://review.openstack.org/650903
14:19:23 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Support microversion 2.61 for nova flavors https://review.openstack.org/650902
14:22:39 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Update baremetal to use proxy logger https://review.openstack.org/652083
14:22:59 mordred dtantsur: ^^ I did the followup baremetal logger patch
14:42:46 frickler mordred: so hard overriding any access to the admin endpoint to public instead works (mostly, I think the heat errors are either unrelated or some obscure special case) http://logs.openstack.org/46/652046/1/check/openstacksdk-functional-devstack-tips/b8a0433/
14:42:59 frickler now I wish I could find a sane way to achieve the same thing

Earlier   Later