| *** stevemar has joined #openstack-sdks | 01:44 | |
| *** stevemar has quit IRC | 02:10 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 02:12 | |
| *** tellesnobrega_ has joined #openstack-sdks | 02:20 | |
| *** fifieldt has joined #openstack-sdks | 03:19 | |
| *** glenc has quit IRC | 03:20 | |
| *** glenc has joined #openstack-sdks | 03:22 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 03:45 | |
| *** briancurtin has quit IRC | 05:39 | |
| *** stevemar has joined #openstack-sdks | 05:42 | |
| *** k4n0 has joined #openstack-sdks | 06:00 | |
| *** tellesnobrega_ has quit IRC | 06:37 | |
| *** stevemar has quit IRC | 07:16 | |
| *** f13o has quit IRC | 10:26 | |
| *** f13o has joined #openstack-sdks | 10:31 | |
| *** k4n0 has quit IRC | 13:00 | |
| *** jdaggett has quit IRC | 13:24 | |
| *** VeggieMeat_ has joined #openstack-sdks | 13:25 | |
| *** VeggieMeat has quit IRC | 13:26 | |
| *** jdaggett_ has joined #openstack-sdks | 13:26 | |
| *** Alex_Gaynor has quit IRC | 13:27 | |
| *** Alex_Gaynor_ has joined #openstack-sdks | 13:28 | |
| *** Alex_Gaynor_ is now known as Alex_Gaynor | 13:34 | |
| *** Alex_Gaynor has joined #openstack-sdks | 13:34 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 13:38 | |
| *** ayoung has joined #openstack-sdks | 13:41 | |
| *** tellesnobrega has quit IRC | 14:19 | |
| *** tellesnobrega has joined #openstack-sdks | 14:19 | |
| *** briancurtin has joined #openstack-sdks | 14:28 | |
| *** ayoung is now known as ayoung-afk | 15:22 | |
| *** stevemar has joined #openstack-sdks | 15:25 | |
| *** ycombinator_ has joined #openstack-sdks | 15:47 | |
| *** mattfarina has joined #openstack-sdks | 15:52 | |
| *** VeggieMeat_ is now known as VeggieMeat | 15:53 | |
| *** ayoung-afk is now known as ayoung | 15:53 | |
| *** terrylhowe has joined #openstack-sdks | 16:06 | |
| openstackgerrit | Terry Howe proposed stackforge/python-openstacksdk: keystore proxy methods and tests https://review.openstack.org/132838 | 16:38 |
|---|---|---|
| *** etoews has joined #openstack-sdks | 16:50 | |
| *** etoews has quit IRC | 17:03 | |
| *** etoews has joined #openstack-sdks | 17:06 | |
| openstackgerrit | Jeremy Stanley proposed stackforge/os-client-config: Corrections to readme https://review.openstack.org/136831 | 17:12 |
| briancurtin | terrylhowe: the version fixes review looks fine to me, but on top of it im wondering what's the best way to use it with something like DevStack's glance endpoint which is unversioned | 17:45 |
| briancurtin | basically, i see in theory how the change itself works, just wondering how to piece it together with something real | 17:45 |
| terrylhowe | briancurtin: I think we need another fix to handle the situation of endpoints in the service catalog that are not versioned | 17:47 |
| terrylhowe | neutron is like that too, we need to pull the version out of base_path I think | 17:47 |
| *** ycombinator_ has quit IRC | 17:47 | |
| notmyname | good morning | 17:48 |
| briancurtin | cool, this is good as-is then | 17:48 |
| notmyname | what's the general philosophy of openstack-sdk on dependencies? | 17:49 |
| terrylhowe | as few as possible I think notmyname | 17:49 |
| notmyname | terrylhowe: good!! | 17:49 |
| notmyname | :-) | 17:49 |
| briancurtin | if we need em, we need 'em, but we better need 'em | 17:49 |
| notmyname | wonderful to hear | 17:49 |
| notmyname | and what specific distros? eg shoudl openstack-sdk work with distro packages in trusty? precise? or should the openstack-sdk user be expected to install newer versions of these libraries? (I'm assuming windows and os x users will have to install dependencies anyway) | 17:51 |
| briancurtin | that hasn't come up until right now, and i'm not really sure how to answer. what *should* we do in order to make sure this is useful to people? | 17:53 |
| stevelle | My first thought it to target working with releases rather than distro packages. | 17:55 |
| terrylhowe | trusty and precise for sure. I think we have several people developing on os x too. I do some work on os x, but mostly ubuntu | 17:57 |
| notmyname | IMO "less dependencies" means that it works with the older versions provided by distros in preference for bleeding edge stuff. target precise and cent6. that also makes it easier for deployers who are installing from a .deb or .rpm since they have only one context on their system (ie don't mix pip and packages) | 17:58 |
| dtroyer | notmyname: ++ | 17:58 |
| dtroyer | also consider that this is a client thing and OS/x and Windows and whatever else is liekly to be in the picture | 17:59 |
| stevelle | and in those cases you must use pip | 18:00 |
| briancurtin | yep on windows (dusts off windows laptop) | 18:01 |
| notmyname | but, of course, using newer versions means that devs get access to newer features... | 18:01 |
| stevelle | possibly with brew on OS/x | 18:01 |
| stevelle | but that would be brew managing pip most likely | 18:02 |
| notmyname | just to make sure I'm not assuming something that isn't true... | 18:12 |
| notmyname | is the openstack-sdk project ok with the swift dev community actively contributing to openstack-sdk swift support (in lieu of python-swiftclient)? | 18:13 |
| briancurtin | 100% yes | 18:15 |
| notmyname | ok, great :-) | 18:15 |
| notmyname | I'm working on writing up a short doc about what we're talking about and how it should work | 18:16 |
| briancurtin | ideally we get everyone in on this. we laid the groundwork and want to connect everything up in a nice way, just took a bit and is finally catching on | 18:16 |
| notmyname | I'll post it up for y'all to review and for the swift devs to review. I want to show it to ttx tomorrow just as a "head's up" | 18:16 |
| briancurtin | cool, looking forward to it | 18:16 |
| *** etoews has quit IRC | 18:43 | |
| *** etoews has joined #openstack-sdks | 18:49 | |
| openstackgerrit | Terry Howe proposed stackforge/python-openstacksdk: Reswizzle proxy tests https://review.openstack.org/136862 | 18:53 |
| notmyname | are there any openstack-sdk design guidelines. stuff like "this is what the interface to service X shoudl look like"? | 19:02 |
| notmyname | eg, I'm curious about your thinking about how swift and cinder (or nova or etc) will look. since one is a control/provisioning API and one is a data API, they might look different. or they might be similar. not sure what your thinking is around this | 19:03 |
| briancurtin | notmyname: that's something we're hoping to iron out right now, so it's a good time for you to have come around. ideally we want everything to look as consistent as can be, but thing do just work differently, so that'll happen | 19:10 |
| notmyname | ok | 19:10 |
| briancurtin | notmyname: for example, https://review.openstack.org/#/c/132838/3/openstack/keystore/v1/_proxy.py is basically a pass-through to the resource layer, and what i did with https://review.openstack.org/#/c/132100/4/openstack/object_store/v1/_proxy.py is go a step up and make things a little easier to work with (taking string names to create containers, for example) | 19:11 |
| notmyname | another thought I've had is that we should eventually have a migration wrapper that supports the current python-swiftclient SDK API (we have a high-level "Connection" class). | 19:11 |
| notmyname | if we do that after setting the new API, then we have a migration path for existing python-swiftclient users | 19:12 |
| briancurtin | that sounds good | 19:12 |
| notmyname | if we do it first, then we have a set of pre-existing tests in python-swiftclient that can be used to see where we are in openstack-sdk | 19:12 |
| notmyname | but I don't want the openstack-sdk implementation to be forced into the existing functionality. I'd prefer the new one can develop on its own | 19:13 |
| briancurtin | agreed | 19:14 |
| notmyname | see the bottom of https://etherpad.openstack.org/p/kilo-swift-swiftclient | 19:15 |
| notmyname | what do you think? what am I missing? | 19:15 |
| terrylhowe | looks good notmyname My concerns on the sdk side would be around header handling. I think we could use more convenience functions around swift header magic | 19:24 |
| terrylhowe | also, I’m not sure how everyone feels about doing things in the SDK like chunking. Not sure where the line gets drawn | 19:24 |
| terrylhowe | I think the sdk should support chunking, but that is an example where things get unclear to me | 19:26 |
| briancurtin | are there reasons we wouldnt want to support that or things like that? | 19:29 |
| openstackgerrit | Brian Curtin proposed stackforge/python-openstacksdk: Prepare for documentation of Resources https://review.openstack.org/136877 | 19:51 |
| *** ycombinator_ has joined #openstack-sdks | 19:57 | |
| terrylhowe | I think chunking should be supported briancurtin but how about an abstraction of multipart files? Most likely up to the application I’d guess. | 19:59 |
| briancurtin | terrylhowe: now this is a bit over my head (havent had to deal with that), but is that something we could provide a couple of "recipes" for if there are different but common ways of approaching it? | 20:04 |
| terrylhowe | Yeh, a how-to or something in the docs might be good enough. | 20:06 |
| briancurtin | kind of like how shutil.copytree came about - directory copying means a lot of things to a lot of people, so it started as an Active State Cookbook recipe, then was in the docs, then reached an (i think) reasonable home in the shutil library | 20:07 |
| briancurtin | if existing clients have already gone through that type of thing, perhaps we can skip a step(s) there and make them available somehow | 20:08 |
| notmyname | IMO a swift SDK should have multipart object support. give a fp and the sdk will do the right thing | 20:11 |
| briancurtin | notmyname: i think this is where existing client features, not necessarily interfaces, will come into play, so you already know how to handle that type of thing and people are using it, so we should take that on as well | 20:14 |
| *** ycombinator_ has quit IRC | 20:15 | |
| *** etoews_ has joined #openstack-sdks | 20:18 | |
| sigmavirus24 | so here's the thing, requests will handle chunking (or streaming) for you | 20:19 |
| sigmavirus24 | we've seen poor support from wsgi based servers though when dealing with chunking | 20:19 |
| terrylhowe | good to know sigmavirus24 | 20:19 |
| sigmavirus24 | (which is more of a swift problem than an sdk problem) | 20:19 |
| sigmavirus24 | If we decide to go the multipart/form-data upload route, I have a helper that will stream large files for you as well | 20:20 |
| sigmavirus24 | it's in requests-toolbelt but that's Apache so the recipe could be copy-pasted out iirc | 20:20 |
| sigmavirus24 | We have open issues there to allow the multipart/form-data handler to also do chunking but I haven't had the time to be honest | 20:20 |
| *** etoews has quit IRC | 20:22 | |
| terrylhowe | well, the multipart feature I was talking about was the multipart feature of swift where there is a manifest file to tie all the pieces together. | 20:22 |
| sigmavirus24 | Ah, I misunderstood | 20:23 |
| briancurtin | terrylhowe: unfortunately we can't autodoc any of the resource classes since the props operate on an instance | 20:52 |
| terrylhowe | hmm, the idea of documenting those hadn’t occurred to me, I thought people would read the code | 20:55 |
| briancurtin | i wouldn't want to depend on just the code for app developers/end-users, so want to get something up on the site. im poking around if there's another way | 20:58 |
| briancurtin | im thinking if you're looking at the high level docs and you see you can call conn.object_store.get_metadata or whateer, you're going to want to know from there how that object is formed without having to possibly pick through your site-packages folder to find the right resource | 20:59 |
| briancurtin | ah, figured it out. minor change to prop.__get__, but i think it's reasonable | 21:23 |
| openstackgerrit | Brian Curtin proposed stackforge/python-openstacksdk: Don't attempt to __get__ prop without instance https://review.openstack.org/136902 | 21:34 |
| *** ycombinator_ has joined #openstack-sdks | 22:12 | |
| *** mattfarina has quit IRC | 22:12 | |
| openstackgerrit | Brian Curtin proposed stackforge/python-openstacksdk: Prepare for documentation of Resources https://review.openstack.org/136877 | 22:18 |
| openstackgerrit | Brian Curtin proposed stackforge/python-openstacksdk: Prepare for documentation of Resources https://review.openstack.org/136877 | 22:40 |
| openstackgerrit | Brian Curtin proposed stackforge/python-openstacksdk: Prepare for documentation of Resources https://review.openstack.org/136877 | 22:42 |
| openstackgerrit | Brian Curtin proposed stackforge/python-openstacksdk: container attr docs https://review.openstack.org/136924 | 23:28 |
| openstackgerrit | Brian Curtin proposed stackforge/python-openstacksdk: Add object_store resource documentation https://review.openstack.org/136925 | 23:28 |
| openstackgerrit | Brian Curtin proposed stackforge/python-openstacksdk: Add object_store resource documentation https://review.openstack.org/136926 | 23:35 |
| *** ycombinator_ has quit IRC | 23:36 | |
| notmyname | FYI tomorrow morning during my normal scheduled time with ttx I'm going to mention swift's plan to focus more on openstack-sdk | 23:45 |
| briancurtin | notmyname: cool. i'll be around if you/he have any questions coming out of that | 23:55 |
| notmyname | briancurtin: thanks | 23:58 |
| *** torgomatic has joined #openstack-sdks | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!