| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-04-10 | |||
| 17:42:48 | dustinc | quick question fo ryou guys, perhaps this is more of a Nova question but I am working on the context of the SDK so going to ask here first.. | |
| 17:43:13 | dustinc | I am looking at https://docs.openstack.org/openstacksdk/latest/user/resources/baremetal/v1/node.html#openstack.baremetal.v1.node.Node and it sounds like the Node object only has one instance_id | |
| 17:43:44 | dustinc | I would expect that to be a list of ids of all the associated instances | |
| 17:44:10 | dustinc | is there really a 1:1 of Node:Instance? | |
| 17:55:25 | dustinc | specifically when returned by "nodes" here https://docs.openstack.org/openstacksdk/latest/user/proxies/baremetal.html | |
| 17:55:42 | dustinc | or is it returning a Node object for each Node:Instance? | |
| 18:06:07 | Shrews | dustinc: you should ask dtantsur|afk for real clarification, but when it comes to the baremetal driver, you will only have a single "instance" as nova sees it for each baremetal machine, so 1:1 seems correct to me | |
| 19:34:53 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Before writing object data to stdout, re-open it in binary mode https://review.openstack.org/573465 | |
| 21:34:50 | dustinc | Shrews: I feel silly, I was working on baremetal api but still thinking VMs in my head..thanks | |
| 22:24:01 | cyberpear | Would anyone mind reviewing an ansible PR that allows using subnetpool_id rather than use_default_subnetpool? https://github.com/ansible/ansible/pull/52608 | |
| #openstack-sdks - 2019-04-11 | |||
| 08:06:17 | openstackgerrit | Rico Lin proposed openstack/keystoneauth master: Update auth plugin name list in document https://review.openstack.org/648920 | |
| 08:35:27 | dtantsur | dustinc: instance_id in the context of nova is the server ID | |
| 08:35:46 | dtantsur | a bare metal node is not divisible, so it cannot host several instances | |
| 10:29:02 | cdent | dtroyer: with luck you are still sleeping, but when you come back to this world, you can probably help me: I want to make some tests of osc by passing a full suite of what would be the args to some entry point. Related to this: https://storyboard.openstack.org/#!/story/2005411 | |
| 10:57:49 | openstackgerrit | Merged openstack/openstacksdk master: Clarify error if no version can be found https://review.openstack.org/640835 | |
| 10:59:23 | pas-ha | cdent: can you add a noauth mode to placement? (might be useful any way) and then call openstackclient with 'noauth' auth plugin (should need just an endpoint) | |
| 10:59:45 | cdent | pas-ha: placement has support for 'noauth2' | |
| 11:00:40 | cdent | If you [api]/auth_strategy with 'noauth2' then a query with a header like 'x-auth-token: admin' will do the expected | |
| 11:00:48 | cdent | does that work? | |
| 11:01:14 | cdent | pas-ha: oh I see what you're saying, you're responding to what I said above | |
| 11:01:30 | pas-ha | yes | |
| 11:01:43 | pas-ha | on how to test w/o keystone etc running | |
| 11:01:47 | cdent | the issue isn't with auth handling, it's with not wanting to run external processes | |
| 11:01:54 | pas-ha | o, ok | |
| 11:02:10 | cdent | the PlacementFixture makes it possible to run the placement app in process (and in memory) | |
| 11:02:23 | pas-ha | but then you are not testing the thing people will actually use | |
| 11:02:31 | cdent | yes you are | |
| 11:02:32 | pas-ha | which is a CLI command | |
| 11:02:44 | cdent | if you can pass args like I'm describing | |
| 11:03:08 | cdent | in any case, the thing that is being tested is not whether openstack client can parse args | |
| 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 | |