Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-04-09
17:54:08 mordred elmiko: it helps even more if you still use old internet protocols ... such as helping to run /afs/openstack.org ;)
18:01:46 elmiko haha ++
18:02:08 elmiko is anyone maintaing the openstack gopher instance? if not, maybe i could volunteer XD
18:05:25 openstackgerrit Merged openstack/keystoneauth master: Update the min version of tox https://review.openstack.org/651149
#openstack-sdks - 2019-04-10
04:53:16 openstackgerrit Thomas Bechtold proposed openstack/openstacksdk master: baremetal: Add support for mkisofs and xorrisofs for configdrive https://review.openstack.org/651193
12:14:11 openstackgerrit LIU Yulong proposed openstack/python-openstackclient master: Add floating IP Port Forwarding commands https://review.openstack.org/650062
12:36:14 frickler is anyone working on making keystoneauth get rid of the identity admin endpoint? running devstack without it still seems to explode marvelously, although keystone claims that it shouldn't be needed anymore http://logs.openstack.org/92/651492/2/check/devstack/357b6f0/controller/logs/screen-g-api.txt.gz#_Apr_10_11_28_00_915073
12:53:31 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/openstacksdk master: Add "name" filter in "list" call when retrieving a single register https://review.openstack.org/637238
13:18:56 mordred frickler: not that I know of - but it seems like a thing we should do
13:19:14 mordred frickler: are we defaulting something to operating against the admin endpoint by default or something?
13:25:12 openstackgerrit Merged openstack/openstacksdk master: baremetal: Add support for mkisofs and xorrisofs for configdrive https://review.openstack.org/651193
13:40:05 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.openstack.org/651534
13:42:06 frickler mordred: yes, but I fail to find the correct location. my first guess was this, but changing it to public doesn't fix my issue https://opendev.org/openstack/keystonemiddleware/src/branch/master/keystonemiddleware/auth_token/__init__.py#L910
13:42:53 mordred frickler: well - that definitely seems to need to be changed
13:43:52 mordred frickler: I don't see anything in ksa where we're setting anything to admin
13:44:13 mordred frickler: perhaps the job isn't actually using the proposed patch to keystonemiddleware?
13:48:07 frickler mordred: I'm testing locally, patching the installed version directly
13:48:40 mordred oh. well
13:48:48 mordred then it's likely not an installation issue
13:48:52 mordred :)
16:33:24 openstackgerrit Merged openstack/openstacksdk master: Bail earlier on a version mismatch for a supported service https://review.openstack.org/637563
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!

Earlier   Later