19:00:25 <briancurtin> #startmeeting python-openstacksdk
19:00:26 <openstack> Meeting started Tue Apr 21 19:00:25 2015 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:29 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:36 <briancurtin> if you're around for the SDK meeting, say hi
19:00:45 <sigmavirus24> o/
19:00:49 <sigmavirus24> erm "hi"
19:00:50 <briancurtin> (or if i got timezones wrong, shame me...i'm in CA today)
19:01:10 <etoews> o/
19:01:20 <dtroyer> o/
19:01:34 <briancurtin> two things on the agenda to discuss and then whatever comes up after that: https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2015-04-21_1900_UTC
19:01:51 <stevelle> o/
19:02:13 <terrylhowe> o/
19:02:18 <briancurtin> #topic wait_for_status
19:02:38 <briancurtin> #link https://review.openstack.org/#/c/174980/
19:02:41 <etoews> terrylhowe: did you have a chance to read my answers to your comments?
19:02:54 <terrylhowe> no
19:03:07 <terrylhowe> sorry, lots of meetings lately
19:03:14 <etoews> i understand ;)
19:03:20 <etoews> wanna take a minute now?
19:03:24 <baffle> o/
19:03:40 <terrylhowe> yeh
19:03:52 <briancurtin> etoews: fwiw i dont like server_ -- i think value is the best we're going to get to not shadow and not do other weird-ish things
19:04:29 <etoews> ya. server_ kind of seemed like an abuse of trailing underscore.
19:05:09 <dtroyer> just looking at it for the first time here, 'value' is not too jarring, especially once you see it as a pattern everywhere.
19:05:13 <briancurtin> i dont really love value, but after applying a lot of stuff around the services, having a consistent name reads pretty well
19:05:15 <briancurtin> yep
19:05:39 * dhellmann lurks while continuing to try to send release notes
19:06:50 <terrylhowe> The ‘value’ thing is so generic, but I don’t have a better suggestion atm not a big deal
19:07:27 <terrylhowe> anyway, none of those comments are huge, more topics of discussion just like doing a wait_for method vs wait_for_status
19:08:18 <briancurtin> i'd love to call it resource, but then we run into shadowing potential again (merely potential, since calls into the resource module are moving out of the proxy classes and into the proxy base)
19:09:15 <etoews> but we'll go with value for now
19:09:27 <briancurtin> it just wouldn't work immediately. if it turns out to be something we want to change, that's probably fine. value for now seems like the best bet
19:09:56 <etoews> what does everyone think of resource.Resource._wait_for_status()
19:10:12 <briancurtin> why would it be private?
19:10:19 <etoews> read #link https://review.openstack.org/#/c/174980/4/openstack/resource.py
19:10:36 * briancurtin reading
19:10:46 <etoews> my Apr 20 5:07 PM comment
19:11:16 <dtroyer> FWIW, we're planning to sketch out a top-level OSC command that will do exactly this so writing status loops in shell is no longer a thing, so I'd love to be able to eventually use this method
19:11:47 <terrylhowe> makeing wait_for a method of Resource makes a lot of sense if we made it generic, not so stuck on the status attribute
19:12:07 <terrylhowe> I think I’m fine leaving it out of the class if we are going to have it associated with the attribute status
19:12:10 <briancurtin> etoews: i think i said something earlier about it being a function, which I think handles this purpose better than it does to make it private
19:12:16 <etoews> terrylhowe: did you read my last comment on resource.py
19:12:21 <terrylhowe> yeh
19:13:05 <terrylhowe> oh, I thought you were talking about something else, hold on
19:14:17 <briancurtin> iirc libcloud has it as a method but it's on compute-specific classes, not in the base. waiting on status is too specific to be in the base imo
19:14:27 <briancurtin> (two abbreviations in one message, everyone takes a drink)
19:14:52 <terrylhowe> yeh, I’m for leaving it out of the class
19:15:04 <etoews> okay
19:15:30 <etoews> #agreed resource.wait_for_status()
19:16:05 <etoews> terrylhowe: did you still want to discuss a generic wait_for() ?
19:17:10 <terrylhowe> nope
19:17:35 <etoews> okay. we'll just go with resource.wait_for_status() then.
19:17:48 <briancurtin> #topic common get method
19:18:15 <briancurtin> so now that the deletes are through, there's an implementation of get at #link https://review.openstack.org/#/c/164351/
19:18:19 <etoews> terrylhowe: i also wanted to ask you about your comment on https://review.openstack.org/#/c/174980/4/openstack/tests/unit/test_resource.py but that can wait until after or in #openstack-sdks
19:18:39 <briancurtin> can talk about that now if you want, i jumped the gun
19:19:20 <etoews> terrylhowe: can you give me a quick idea of what you had in mind?
19:19:26 <terrylhowe> I was just thinking make some FakeResource in the test file so the test isn’t pulling in stuff it doesn’t need /that might change
19:21:00 <briancurtin> yeah, i think test_resource should probably not involve other actual resources and just build on the FakeResource that is already there, or something else like that
19:21:02 <terrylhowe> not a big deal to me, but seems like it might be safer to not have a dependency on v2.server in test_resource
19:21:39 <etoews> okay. i'll look into that. thx.
19:22:19 <etoews> onto the common get method
19:23:26 <briancurtin> back to the common get -- perhaps i should break out that change into one or more other changes because that review creates a path that would remove the need to have find at all by leveraging kwargs passed into a  list method, and sending in the appropriate query name/value to do the find
19:23:31 <terrylhowe> On the base get method, I really want a get method that does an HTTP get
19:25:23 <briancurtin> terrylhowe: and it does that, but it handles the resource-specific logic for finding what you've sent as well. if you give it something that does exist, it just does a get and gets it. if you give it some ID or name that you want to find, it'll find it (or fail to find it) -- having to do two different methods to attempt to retreieve one thing doesn't feel
19:25:23 <briancurtin> too nice, since you then have to do a try/except dance
19:25:30 <dtroyer> I think there is value in having simplified methods for simple things and a fallback to the generalized methond (find*) when required.
19:25:58 <dtroyer> so a simple get() in parallel with a flexible find() seems good to me
19:26:17 <dtroyer> even though they are both GET requests under the hood
19:26:31 <briancurtin> dtroyer: as in get uses find, or that get only gets (or fails to get) a singular resource?
19:26:55 <dtroyer> I wouldn't have get() use find(), I'd make them peers
19:28:08 <briancurtin> i guess i'll have to look back into how to do that. we can't really make a generic find because every resource does something very different, between query params and filters, but i'll restructure the proposal to handle it with both being separate
19:28:37 <etoews> what's the use case for find? to find by name?
19:29:08 <etoews> it's a bit weird to me that the docs say "Find a resource by its name or id."
19:29:10 <dtroyer> that's one, also finding substring/regex matches (where possible, or done locally from list return)
19:29:16 <etoews> if i have the id, i'm going to do a get
19:29:43 <terrylhowe> find was modeled after the find in OSC
19:29:45 <briancurtin> i dont really know the find case other than that it has existed in the past in other places, which is why i tried to handle it in get because you want to get a resource that may or may not exist
19:29:59 <terrylhowe> it does a find by name_or_id that was the original intention at least
19:30:17 <dtroyer> find() is generally more complicated, with possibly multiple server requests doe to name->id lookups in some cases
19:30:49 <dtroyer> get() is (in my mind) basically requests.get() + auth and what else Transport adds
19:31:14 <briancurtin> yeah, there's often no way to do a find without retrieving everything and filtering locally on the response, especially if you want to do substring/regex when it's not supported (which it mostly isnt from what i can tell)
19:31:42 <dtroyer> briancurtin: right, and we are strting to do that in OSC more and more
19:31:46 <briancurtin> find is the method i think i've written and thrown away and rewritten 20 times in the last few months
19:31:56 <terrylhowe> yes
19:32:22 <briancurtin> if we concede that having to fall back to "get everything and filter locally" is sometimes acceptable, it gets a little easier
19:32:34 <etoews> with those use cases for find it makes more sense to me as separate method too.
19:32:35 <dtroyer> my gut says there are probably three variations on find() needed across the OpenStack APIs, and we shouldn't get hung up too much on the differences.  Just docuemnt those differences well to make it easy to choose
19:32:47 <terrylhowe> definitely need that briancurtin
19:33:11 <terrylhowe> It seems like we should provide the filters and if there are dups, we filter
19:33:35 <briancurtin> yeah, there's too many places where there is zero filtering capability server side. i guess maybe i'll try to tackle a better find again and look at a cleaner get
19:34:07 <terrylhowe> would it help if get returned None on 404?
19:34:53 <dtroyer> at a high level API, maybe.  at the lowest levels I'd probably want to see the error code
19:35:54 <briancurtin> terrylhowe: i think that depends on how find works and how they work together. on delete you can reasonably ignore a 404, but if you're expecting to get a flavor or a server or a container, you can't reasonably continue without those things since you're probably building on them or otherwise communicating with them
19:36:14 <briancurtin> so it is an exceptional case to not be returned what you were asking for there
19:36:27 <terrylhowe> I like it throwing a 404
19:36:40 <etoews> to me, if i'm doing a get with a specific id i'm fully expecting it to be there, otherwise it's an exception
19:36:42 <briancurtin> that's my stance as well
19:37:15 <etoews> we have NotFoundException
19:37:20 <briancurtin> find, on the other hand, would be a place that none could be returned
19:37:25 <etoews> we also have ResourceNotFound
19:37:40 <briancurtin> etoews: that's what it would be raised as (RNF)
19:37:49 <etoews> +1 None is a valid return on find
19:38:23 <etoews> what's supposed to be the diff between ResourceNotFound and NotFoundException
19:38:31 * briancurtin was just typing that
19:39:42 <briancurtin> etoews: id have to dig in, but i think the one i recently added was ResourceNotFound and it's raised when we get a 404 out of like session.get. i seem to remember NotFoundException comes from other places and is more generally for 404s not related to actually trying to work with resources (like trying to get a service catalog or something?)
19:40:13 <briancurtin> that's not really a great justification, we should look into that and confirm we need both
19:40:24 <etoews> oh wait. ResourceNotFound(NotFoundException) :P
19:40:48 <etoews> i guess it's supposed to be a more specific class of NFE
19:41:02 <etoews> that's not particularly intuitive to me
19:41:51 <etoews> my preference would be for just one
19:41:58 <dtroyer> I would expect to see NotFoundException if I hit a URL that is invalid, ResourceNotFound if the URL is correct but there is no resource by the requested id?
19:42:40 <briancurtin> i think that was the intent (i have a terrible memory, looking it up now)
19:42:55 <dtroyer> The first is more likely when a client is mis-matched with the server for some reason and doesn't know it and is issuing incorrect requests
19:43:48 <etoews> dtroyer: but would the sdk necessarily know which case you're in?
19:45:17 <dtroyer> etoews: in my mind it does ;)  but maybe not.  I'm not certain if the server response is different
19:46:23 <briancurtin> ok, from transport if we get a 404, it's a NotFoundException. if the something like get_server receives catches a NotFoundException, it re-raises as ResourceNotFound
19:47:24 <etoews> i guess the question boils down to, is there value to the client code to have both?
19:47:34 <briancurtin> so it's just turning a generic 404 into something with a bit more information about the request. teh exc message is "No %s found for %s" % (resource_type.__name__, value)
19:48:04 <dtroyer> so the difference is just that's its specifically a resource request that returned 404.  If there is additional info in the message I'd say it is worth it
19:48:24 <dtroyer> well, you can add that anyway…
19:48:37 * dtroyer goes back to counting release emails
19:49:15 <briancurtin> the only real difference between the two is the name of the exception class and that we put the resoruce type you're trying to get into the message. we could technically just reraise NotFoundException with that exception message
19:49:57 <etoews> right. RNF doesn't add a lot of value. (although i like the name more)
19:50:02 <briancurtin> (i like ResourceNotFound as a name at that point, though...not married to it yet)
19:50:03 <briancurtin> yep
19:50:25 <etoews> something to noodle on.
19:50:38 <etoews> i'd like to bring up one more thing before we break.
19:50:42 <briancurtin> go for it
19:51:00 <etoews> i'd like to see the sdk get a bit more visibility
19:51:08 <etoews> in openstack overall
19:51:28 <briancurtin> oh yeah, i submitted a cross-project...uh, thing...blanking on the name of
19:51:41 <etoews> session
19:51:42 <briancurtin> working group or meetup or something for at the summit
19:52:01 <etoews> #link form https://docs.google.com/forms/d/1LJZxdxE8P2F0WoULZEsRCXeqZP_VgH5nWUdZlbcA68M/viewform?c=0&w=1
19:52:08 <etoews> oops
19:52:13 <etoews> form #link https://docs.google.com/forms/d/1LJZxdxE8P2F0WoULZEsRCXeqZP_VgH5nWUdZlbcA68M/viewform?c=0&w=1
19:52:25 <etoews> proposals #link https://docs.google.com/spreadsheets/d/1vCTZBJKCMZ2xBhglnuK3ciKo3E8UMFo5S5lmIAYMCSE/edit#gid=827503418
19:52:44 <briancurtin> etoews: how do you want to go about more visibility. ive wanted this for a long time but i dont know when is too early (or too late), and being in the middle of stabilizing APIs feels like a time people probably don't want to toy with it
19:52:52 <etoews> looks like the sdk is row 14
19:53:20 <etoews> briancurtin: but we're getting close to stabilizing it
19:54:15 <etoews> i dunno. maybe i'm just being impatient.
19:54:37 <briancurtin> yep, and building up examples and sharing them and writing about them and all of that is stuff we'll have to do. terry and i have a talk on buildng applications on the SDK
19:55:06 <etoews> but participating in the cross-project meeting might help (when the time is right)
19:55:12 <terrylhowe> looks good.  I’d really like to get these proxy changes done soon
19:55:27 <etoews> +1
19:56:29 <etoews> what's the goal for a "1.0" release?
19:56:37 <briancurtin> same. i need to go back to the create one as well since i have work to do there as well. update is sort of similar so what we'll have discussed in create will mostly apply there
19:57:03 <etoews> or roadmap is maybe what i mean.
19:57:38 <briancurtin> etoews: i think once we get these APIs stabilized and then applied, we do a release but just bump it up one from where we're at ( so 0.4 or 0.5?) -- after getting mileage and feedback and talk around more of openstack, ironing things out of that seems like the way to 1.0. i dont really think it's all that far away
19:57:41 <terrylhowe> we need to get some sort of alpha/beta trial before 1.0
19:58:01 <etoews> it would be nice to have a "1.0" before the summit so we can go into session and try to get some traction.
19:58:23 <terrylhowe> Tokyo maybe
19:58:42 <etoews> i'm talking vancouver
19:58:53 <stevelle> I'm glad I wasn't the only one thinking Vancouver would be too soon
19:58:56 <briancurtin> if we do a 1.0 early then we're stuck with those APIs until we do a 2.0. i want to move quick on this so maybe that's not a bad thing, but i do think we need to settle down slightly after we get the APIs baked in over the next few weeks/months
20:00:01 <etoews> alright. well expect me to continue to push. frankly i'm excited to really get this out there and get people using it.
20:00:27 <briancurtin> same. haven't worked on it for like a year for nothin'
20:01:04 <briancurtin> and that's time. i have to head out to other things for a bit but i'll keep an eye on -sdks and be back later
20:01:07 <briancurtin> #endmeeting