Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-04-16
23:23:00 mriedem ok i'll post what i have and we can sort it out tomorrow
23:23:13 mriedem dtroyer: not your fault if so b/c it's copying the busted novaclient code
23:23:19 mriedem which also says it can be a non-boolean string
23:23:22 mriedem from 2012
23:43:27 Sundar dtoyer: Thanks. So, how do we get the right 'cloud name' or user configuration name for ``connection.Connection(cloud='devstack-admin')``?
23:43:41 Sundar dtroyer: ^
23:45:23 dtroyer I don't know the exact context you are in, but that depends totally on the cloud you are calling
23:47:53 Sundar dtroyer: let me put it this way. When one project (say Cyborg) calls another (say Glance), is it appropriate to embed names like 'devstack-admin' in the caller code? One would tjhink not. So, where do I get the right name for the caller?
23:49:37 dtroyer Sundar: from the point of view of the application, it comes from the app. Most OpenStack services have a configuration value for service accounts like that, along with their DB config, etc. In that case, you probably do not want to rely on clouds.yaml for that information but create your connection from the individual pieces in your config
23:49:53 dtroyer where 'that case' is from a long-running service
23:50:44 openstackgerrit Matt Riedemann proposed openstack/python-openstackclient master: WIP: Fix openstack server create --config-drive value https://review.openstack.org/653176
23:51:21 mriedem Sundar: e.g. nova's config for talking to glance https://docs.openstack.org/nova/latest/configuration/config.html#glance
23:51:31 mriedem uses keystoneauth1 config options for building the ksa session adapter
23:51:56 mriedem efried is well versed in all of that code
23:53:25 Sundar mriedem: I am investigating the 'new' approach, newer than ksa adapter, which is to use openstack sdk with clouds.yaml.
23:53:55 Sundar mriedem: efried is advocating that new approach
23:56:19 Sundar mriedem: Along the lines of https://review.openstack.org/#/c/643664/
23:56:46 Sundar dtroyer: Got it. This should go into cyborg.conf
23:58:56 mriedem Sundar: ok i don't know why we're doing that,
23:59:03 mriedem we don't have a blueprint or anything for that in nova
#openstack-sdks - 2019-04-17
00:00:19 mriedem dtroyer: https://review.openstack.org/653176 is my wip for that --config-drive thing, problem noted within on nargs='?' which maybe you know...tomorrow
00:00:57 Sundar mriedem: One advantage, from what I see, is that it gives a uniform way for one project to talk to any other project, without having to have a separate entry in the conf file for every single callee.
03:24:51 openstackgerrit Erik Olof Gunnar Andersson proposed openstack/openstacksdk master: Actually pass on network_data when building configdrive https://review.openstack.org/653271
06:53:31 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.openstack.org/651534
06:57:58 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Add image.stage methods https://review.openstack.org/652981
07:42:17 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Actually pass on network_data when building configdrive https://review.openstack.org/653271
07:43:05 dtantsur gtema: morning, have a second for an easy approval? ^^^
07:43:49 gtema yeah, am on call now, in a few minutes
07:48:31 dtantsur thx
07:55:15 gtema wlcm
09:18:30 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Update baremetal to use proxy logger https://review.openstack.org/652083
11:53:51 openstackgerrit Merged openstack/openstacksdk master: Actually pass on network_data when building configdrive https://review.openstack.org/653271
13:28:22 cdent elmiko, edleafe, dtantsur, mordred when you have a moment please look at https://storyboard.openstack.org/#!/story/2005474 at the concept of "openstack-shard" mooted in there and the command line client issues it might present. apologies for the haphazard text there, just trying to get things written up without losing ideas
13:28:38 mordred cdent: oh goodie!
13:28:44 edleafe cdent: ack
13:28:47 mordred cdent: it's open in my browser
13:29:14 mordred cdent: also - I haven't followed the rest of the email thread about placement and docker - but I definitely want to sit down with you at the PTG and show you what we've got and how it works
13:29:30 cdent mordred++
13:29:32 mordred cdent: corvus is going to be doing a keynote on the topic too - but as a keynote, it'll obviously be missing details :)
13:30:15 cdent I will probably need to coralled in order to remember. Do not feel bad about hassling me if it comes to that. I'm not good at remembering things at large gatherings.
13:30:21 mordred I figure placement is a popular enough kid that if we get you hooked up it might serve as a good blueprint for other people - or if that doesn't work it can serve as good feedback
13:30:38 mordred cdent: me either. but I think this is a good targetted opportunity, so I'll do my best to remember
13:30:53 cdent I will endeavor as well
13:31:19 cdent btw: the docker stuff got a story too: https://storyboard.openstack.org/#!/story/2005463
13:39:54 elmiko cdent: ack, will take a look
14:47:23 elmiko cdent: are the storyboard comments an appropriate place to leave my thoughts about your idea?
14:47:47 elmiko (sorry, don't have a ton of storyboard experience)
14:48:27 cdent elmiko: If you like, but I was thinking of it more as fodder for some api-sig noodling that would then be reflected back to either to the story or a guideline if everyone loved it
14:48:49 cdent elmiko: basically if you have comments on the goal (get sharding working in placement) the story would be the right place
14:49:10 cdent but if you have coments on the concept of an 'openstack-shard: header' somewhere else might be better
14:50:42 elmiko ack, thanks!
14:51:02 elmiko at this point i'm working more at the conceptual level, athough i did follow the email thread
14:52:17 elmiko i actually find the placement stuff to be kind of exciting/invigorating for the openstack community. it's nice to see that this community can still accept projects with the potential for high impact. ++ imo
15:00:17 efried mordred, dtroyer: I had another thing I wanted to bring up about consuming the SDK in projects like nova/cyborg...
15:00:59 efried We find ourselves having a tough time with testing at several levels because of the internal magic Connection does when you instantiate it
15:01:52 efried and could really use a fixture to mock out enough of those bits that we can use Connection mostly like it's supposed to be used, just mocking e.g. response payloads for certain methods
15:03:00 efried but writing those fixtures in the consuming project is going to be either really brittle because we patch out internals that could change; or too high-level because we patch out the whole Connection and essentially rewrite the SDK framework in our fixture.
15:03:29 efried tl;dr: would you support openstacksdk publishing a ConnectionFixture for use by consumers' tests?
15:06:09 mordred efried: yes.
15:06:31 mordred efried: so - in sdk's tests, we use requests-mock and do exactly that - we only mock the HTTP interactions, not the actual connection methods
15:06:49 mordred efried: to support that, we have a bunch of fixtures and other stuff to set up keystone catalogs and endpoints and whatnot
15:07:18 efried mordred: How hard to expose some subset of those fixtures?
15:07:23 mordred I've been meaning for a WHILE to make that stuff re-consumable - because people consuming Connection should also really be mocking http not mocking methods
15:07:46 mordred it shouldn't be too hard- it'll mostly be about organization and cleanup
15:08:13 efried mordred: though I wouldn't actually mind being able to mock the object thingies rather than the raw http payloads...
15:08:16 mordred and probably making a top-level Fixture class that can be easily instantiated
15:08:38 mordred efried: the tests we inherited from the sdk codebase do that ... and I find them to be exceptionally brittle
15:09:10 mordred however - if it's a thing that people need to be able to do and someone figures out how to write it - I would not be opposed to it living in the sdk repo
15:09:27 efried So e.g. I can say mock.patch.object(conn.image, 'images', side_effect=[list, of, Image, objects, returned, by, the, generator])
15:10:01 efried that ^ wouldn't exactly work, since the return value needs to *be* the generator, but it's the general idea.
15:10:33 mordred yeah - I find it easier to do:
15:10:35 mordred dict(method='GET',
15:10:37 mordred uri='https://image.example.com/v2/images',
15:10:39 mordred json=self.fake_search_return),
15:10:43 mordred but that's just me :)
15:11:18 mordred in any case - I am very supportive of the problem you want to solve
15:11:30 mordred quibbling about impl details notwithstanding
15:11:39 efried cool. Finding someone to do the work any time in the near future, that's going to be the tough part.
15:11:49 mordred yeah. but maybe we can!
15:11:58 efried I guess I should file a story or something.
15:13:14 mordred efried: mildly related - where's the nova ptg schedule? I believe there's an sdk related topic and I want to make sure it's on my calendar so I don't forget about it
15:13:45 efried mordred: Other than slots for three or so of the xproj sessions, I haven't put it together yet.
15:14:59 mordred ok. cool. I'll keep my eyes out :)
16:06:49 efried mordred, dustinc_away: https://storyboard.openstack.org/#!/story/2005475
17:54:56 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.openstack.org/651534
18:17:52 elmiko edleafe, cdent, wanted to give you a heads up, etoews is giving a talk about the work he's doing in about 45 minutes, url for video conference https://bluejeans.com/8933049334
18:18:16 elmiko the general topic has been relayed as gitops
18:18:42 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Prevent setUpClass failures in volume v1 tests https://review.openstack.org/648760
18:18:42 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682
18:18:45 cdent blast from the past
18:18:49 elmiko yeah totally!
18:19:00 elmiko when i saw his name popup on my email i thought i had to check it out
18:19:15 elmiko i guess the openshift commons group invited him to give a talk
18:19:23 cdent In about 45 minutes I hope to be buried in my dinner
18:19:50 edleafe That's a novel way of disposing of a corpse
18:20:14 cdent need something to eat for the long journey
18:21:08 elmiko lol
18:21:30 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682
18:21:41 elmiko cdent: as a followup to your request from earlier, i think the sharding story makes sense at the level presented in the doc
18:22:02 elmiko i think there will be plenty of technical challenges, but in general i like the /idea/

Earlier   Later