Monday, 2014-11-24

*** stevemar has joined #openstack-sdks01:44
*** stevemar has quit IRC02:10
*** sigmavirus24_awa is now known as sigmavirus2402:12
*** tellesnobrega_ has joined #openstack-sdks02:20
*** fifieldt has joined #openstack-sdks03:19
*** glenc has quit IRC03:20
*** glenc has joined #openstack-sdks03:22
*** sigmavirus24 is now known as sigmavirus24_awa03:45
*** briancurtin has quit IRC05:39
*** stevemar has joined #openstack-sdks05:42
*** k4n0 has joined #openstack-sdks06:00
*** tellesnobrega_ has quit IRC06:37
*** stevemar has quit IRC07:16
*** f13o has quit IRC10:26
*** f13o has joined #openstack-sdks10:31
*** k4n0 has quit IRC13:00
*** jdaggett has quit IRC13:24
*** VeggieMeat_ has joined #openstack-sdks13:25
*** VeggieMeat has quit IRC13:26
*** jdaggett_ has joined #openstack-sdks13:26
*** Alex_Gaynor has quit IRC13:27
*** Alex_Gaynor_ has joined #openstack-sdks13:28
*** Alex_Gaynor_ is now known as Alex_Gaynor13:34
*** Alex_Gaynor has joined #openstack-sdks13:34
*** sigmavirus24_awa is now known as sigmavirus2413:38
*** ayoung has joined #openstack-sdks13:41
*** tellesnobrega has quit IRC14:19
*** tellesnobrega has joined #openstack-sdks14:19
*** briancurtin has joined #openstack-sdks14:28
*** ayoung is now known as ayoung-afk15:22
*** stevemar has joined #openstack-sdks15:25
*** ycombinator_ has joined #openstack-sdks15:47
*** mattfarina has joined #openstack-sdks15:52
*** VeggieMeat_ is now known as VeggieMeat15:53
*** ayoung-afk is now known as ayoung15:53
*** terrylhowe has joined #openstack-sdks16:06
openstackgerritTerry Howe proposed stackforge/python-openstacksdk: keystore proxy methods and tests
*** etoews has joined #openstack-sdks16:50
*** etoews has quit IRC17:03
*** etoews has joined #openstack-sdks17:06
openstackgerritJeremy Stanley proposed stackforge/os-client-config: Corrections to readme
briancurtinterrylhowe: 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 unversioned17:45
briancurtinbasically, i see in theory how the change itself works, just wondering how to piece it together with something real17:45
terrylhowebriancurtin: I think we need another fix to handle the situation of endpoints in the service catalog that are not versioned17:47
terrylhoweneutron is like that too, we need to pull the version out of base_path I think17:47
*** ycombinator_ has quit IRC17:47
notmynamegood morning17:48
briancurtincool, this is good as-is then17:48
notmynamewhat's the general philosophy of openstack-sdk on dependencies?17:49
terrylhoweas few as possible I think notmyname17:49
notmynameterrylhowe: good!!17:49
briancurtinif we need em, we need 'em, but we better need 'em17:49
notmynamewonderful to hear17:49
notmynameand 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
briancurtinthat 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
stevelleMy first thought it to target working with releases rather than distro packages.17:55
terrylhowetrusty and precise for sure.  I think we have several people developing on os x too.  I do some work on os x, but mostly ubuntu17:57
notmynameIMO "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
dtroyernotmyname: ++17:58
dtroyeralso consider that this is a client thing and OS/x and Windows and whatever else is liekly to be in the picture17:59
stevelleand in those cases you must use pip18:00
briancurtinyep on windows (dusts off windows laptop)18:01
notmynamebut, of course, using newer versions means that devs get access to newer features...18:01
stevellepossibly with brew on OS/x18:01
stevellebut that would be brew managing pip most likely18:02
notmynamejust to make sure I'm not assuming something that isn't true...18:12
notmynameis the openstack-sdk project ok with the swift dev community actively contributing to openstack-sdk swift support (in lieu of python-swiftclient)?18:13
briancurtin100% yes18:15
notmynameok, great :-)18:15
notmynameI'm working on writing up a short doc about what we're talking about and how it should work18:16
briancurtinideally 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 on18:16
notmynameI'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
briancurtincool, looking forward to it18:16
*** etoews has quit IRC18:43
*** etoews has joined #openstack-sdks18:49
openstackgerritTerry Howe proposed stackforge/python-openstacksdk: Reswizzle proxy tests
notmynameare there any openstack-sdk design guidelines. stuff like "this is what the interface to service X shoudl look like"?19:02
notmynameeg, 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 this19:03
briancurtinnotmyname: 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 happen19:10
briancurtinnotmyname: for example, is basically a pass-through to the resource layer, and what i did with is go a step up and make things a little easier to work with (taking string names to create containers, for example)19:11
notmynameanother 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
notmynameif we do that after setting the new API, then we have a migration path for existing python-swiftclient users19:12
briancurtinthat sounds good19:12
notmynameif 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-sdk19:12
notmynamebut 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 own19:13
notmynamesee the bottom of
notmynamewhat do you think? what am I missing?19:15
terrylhowelooks good notmyname  My concerns on the sdk side would be around header handling.  I think we could use more convenience functions around swift header magic19:24
terrylhowealso, I’m not sure how everyone feels about doing things in the SDK like chunking.  Not sure where the line gets drawn19:24
terrylhoweI think the sdk should support chunking, but that is an example where things get unclear to me19:26
briancurtinare there reasons we wouldnt want to support that or things like that?19:29
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Prepare for documentation of Resources
*** ycombinator_ has joined #openstack-sdks19:57
terrylhoweI 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
briancurtinterrylhowe: 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
terrylhoweYeh, a how-to or something in the docs might be good enough.20:06
briancurtinkind 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 library20:07
briancurtinif existing clients have already gone through that type of thing, perhaps we can skip a step(s) there and make them available somehow20:08
notmynameIMO a swift SDK should have multipart object support. give a fp and the sdk will do the right thing20:11
briancurtinnotmyname: 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 well20:14
*** ycombinator_ has quit IRC20:15
*** etoews_ has joined #openstack-sdks20:18
sigmavirus24so here's the thing, requests will handle chunking (or streaming) for you20:19
sigmavirus24we've seen poor support from wsgi based servers though when dealing with chunking20:19
terrylhowegood to know sigmavirus2420:19
sigmavirus24(which is more of a swift problem than an sdk problem)20:19
sigmavirus24If we decide to go the multipart/form-data upload route, I have a helper that will stream large files for you as well20:20
sigmavirus24it's in requests-toolbelt but that's Apache so the recipe could be copy-pasted out iirc20:20
sigmavirus24We have open issues there to allow the multipart/form-data handler to also do chunking but I haven't had the time to be honest20:20
*** etoews has quit IRC20:22
terrylhowewell, 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
sigmavirus24Ah, I misunderstood20:23
briancurtinterrylhowe: unfortunately we can't autodoc any of the resource classes since the props operate on an instance20:52
terrylhowehmm, the idea of documenting those hadn’t occurred to me, I thought people would read the code20:55
briancurtini 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 way20:58
briancurtinim 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 resource20:59
briancurtinah, figured it out. minor change to prop.__get__, but i think it's reasonable21:23
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Don't attempt to __get__ prop without instance
*** ycombinator_ has joined #openstack-sdks22:12
*** mattfarina has quit IRC22:12
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Prepare for documentation of Resources
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Prepare for documentation of Resources
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Prepare for documentation of Resources
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: container attr docs
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Add object_store resource documentation
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Add object_store resource documentation
*** ycombinator_ has quit IRC23:36
notmynameFYI tomorrow morning during my normal scheduled time with ttx I'm going to mention swift's plan to focus more on openstack-sdk23:45
briancurtinnotmyname: cool. i'll be around if you/he have any questions coming out of that23:55
notmynamebriancurtin: thanks23:58
*** torgomatic has joined #openstack-sdks23:59

Generated by 2.14.0 by Marius Gedminas - find it at!