19:00:47 <briancurtin> #startmeeting python-openstacksdk
19:00:48 <openstack> Meeting started Tue Aug 12 19:00:47 2014 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:51 <openstack> The meeting name has been set to 'python_openstacksdk'
19:01:19 <terrylhowe> Terry Howe, HP
19:01:28 <briancurtin> Brian Curtin, Rackspace
19:01:31 <jamielennox> Jamie Lennox, Red Hat
19:03:10 <briancurtin> #topic Current state of resources
19:03:48 <briancurtin> So right now I think we're off to a decent start, with compute, networking, and telemetry stuff in motion and mostly rolling right through review
19:04:06 <briancurtin> since the last meeting i went through and updated that swift one, which i think should be ok now: https://review.openstack.org/#/c/111807/
19:04:17 <stevelle> Steve Lewis, Rackspace
19:05:03 <briancurtin> now that we have a bunch of them done and seem to have a decent feel for how they're going to work and be built, should we take a look higher or lower at this point before we hammer them all out?
19:05:34 <stevelle> I believe we will find there are issues at this level we can still dig into
19:05:59 <terrylhowe> We don’t have a good example of a resource with a complicated url
19:06:05 <terrylhowe> like metadata on image or server
19:06:32 <stevelle> networking pool members for example
19:06:41 <terrylhowe> I think it will be fine, but I’d like to see one
19:06:50 <stevelle> +1 that also
19:07:03 <jamielennox> right, we still have problems with nested resources etc, but i don't think that precludes us from looking at the next level
19:08:15 <briancurtin> jamielennox: yep. if this swift container change is good, i want to look at objects, since that's all nested
19:10:31 <jamielennox> briancurtin: is there any concepts/WIP of what a higher level looks like at this point?
19:10:42 <terrylhowe> what do you guys have in mind for the next level up?  Honestly, I’d need some convincing we need another level.
19:10:48 <briancurtin> jamielennox: not yet
19:11:00 <jamielennox> terrylhowe: we still need a version abstraction layer
19:12:07 <terrylhowe> well, we definitely need something to sort through version, I agree with that jamielennox
19:12:27 <terrylhowe> is it a whole level though?
19:12:28 <jamielennox> one of the initial goals is to make API versions transparent to the user, so a process of discovering what's available and then using the corect resources
19:13:25 <briancurtin> terrylhowe: i would like to see if we can make something nice that doesn't require explicitly passing in a session to every single call
19:14:38 <briancurtin> it's probably a pretty thin layer, just hiding that and getting to "i want to create something that gives me swift containers and objects"
19:15:32 <briancurtin> also probably a facade to *_by_id things
19:16:08 <briancurtin> like i'd rather call get_object('myobj') than Object.get_by_id(sess, 'myobj') or something
19:16:20 <briancurtin> (maybe?)
19:16:29 <dtroyer> Dean Troyer, Nebula, late
19:17:03 <jamielennox> briancurtin: i think we discussed moving *_by_id to just regular functions
19:17:21 <jamielennox> briancurtin: but i agree, for a UX perspective the simple case shouldn't need session passing
19:17:59 <jamielennox> the 101 case of how do i create and boot a vm should be simpler than we have now
19:18:05 <briancurtin> jamielennox: we did, and i sort of looked at that for what dtroyer was talking about in his lower level but haven't completed anything there
19:20:01 <briancurtin> dtroyer: right now we're kind of just talking through where we're at with the resources, and which direction(s) to go - higher and lower. also need to work out resources for some more complex cases (e.g., nesting)
19:20:27 <dtroyer> ok, thanks for the update
19:23:02 <briancurtin> #action Create Resource classes for more complex URLs, e.g., image or server metadata, network pool members
19:23:10 <jamielennox> so are we stuck with a higher case looking like the existing clients?
19:23:18 <briancurtin> #action Swift objects and/or other nested Resources
19:23:25 <jamielennox> client.compute.images.boot()
19:23:51 <jamielennox> ah, that's wrong - but that format?
19:24:10 <dtroyer> maybe, but I would hope there is only one client in that situation, so there's a small improvement...
19:24:29 <jamielennox> dtroyer: ++ 1 client
19:25:09 <jamielennox> does client.compute.image_boot() work better? do we want to try to remove the 'compute' term altogether?
19:25:47 <dtroyer> there will be sple places you'll need to namespace things, quotas are the first thing that comes to mind
19:25:50 <jamielennox> i like the idea of removing compute, but there will be a lot of resources hanging off client otherwise
19:26:25 <jamielennox> sple?
19:26:35 <terrylhowe> I’d sooner see something more like your first example jamielennox
19:26:35 <briancurtin> i'm not sure where the client name is coming from
19:26:58 <terrylhowe> client.compute.images.list() though, not sure what a boot method would do
19:27:24 <jamielennox> terrylhowe: yea, shows you how well i know the nova api :)
19:27:34 <dtroyer> <size-question> why is there an images under compute?
19:27:44 <dtroyer> s/size/side/
19:27:53 <dtroyer> client.images.list()
19:27:56 <jamielennox> ok, i chose a really bad example
19:28:00 <dtroyer> :)
19:28:19 <jamielennox> i feel otherwise i keep bringing up keystone examples and no-one else cares :p
19:28:41 <terrylhowe> client.identity.user.list()
19:29:01 <briancurtin> jamielennox: from what you said earlier, i dont think we want to remove the 'compute' term at all
19:30:47 <jamielennox> so one of the early goals was to remove code names, my question about removing compute was 'is one of the goals to remove the concept of different services and behave like one cloud'?
19:30:55 <briancurtin> partially because then we'll have a ton of things around in the same namespace, but i think we agreed early on to keep things named properly like 'compute' is 'compute' and not 'servers' or 'nova' or anything
19:31:30 <briancurtin> i think we still need the separation, otherwise that'll be one hell of a crowded namespace
19:31:34 <jamielennox> for example when cinder split out and images moved out of nova, we from the client could adapt to a change in client.images.lits()
19:31:47 <jamielennox> briancurtin: ++ that was my first though
19:32:02 <jamielennox> (not advocating a position on any of this, just throwing ideas around)
19:32:24 <dtroyer> at what point size-wise would rolling all of these up under a client be considered too big?  Not from a keeping-it-in-memory standpoint, but from a reasonable python thing standpoint?
19:32:49 <dtroyer> then only things that need the disambiguation get it like compute_quota.verb()
19:33:01 <terrylhowe> if the
19:33:40 <stevelle> client.compute.images() for list and client.compute.images['image_id'].snapshot() for createImage ?
19:33:45 <jamielennox> yea, i don't think memory is a consideration - we can do lazy load things - and it's python
19:33:53 <terrylhowe> SDK ever covered stuff like orchestration, etc, it will get real crouded and confusing
19:34:28 <jamielennox> but would it? i'm trying to think of an example (other than quota) where the same resource name is used across services
19:34:31 <dtroyer> jamielennox: I wasn't clear…human memory, keeping it all in your mind...
19:35:17 <jamielennox> dtroyer: ah, do you think the namespacing helps there? of is it purely easier to segment and document?
19:35:55 <dtroyer> I think it helps from a doc standpoint, the breakdown helps jump to what you want
19:36:15 <dtroyer> look at the TOC on this page and imagine it flat: https://wiki.openstack.org/wiki/OpenStackClient/Commands
19:36:23 <terrylhowe> A guy was just adding Heat to OSC with commands like “stack create”, etc.  Those are really vague without context
19:36:37 <briancurtin> i have been thinking of all of this as segmented, not any client overlord in front of everything. i auth and create compute, block storage, and networking classes and work with them
19:37:21 <dtroyer> briancurtin: +1   I persoanlly needed to go down that path a bit to make sure it wasn't the Right Thing(™)
19:38:33 <jamielennox> ok, just wanted to explore the idea (though kind of like the wholistic cloud thing)
19:40:55 <jamielennox> this is possibly a good time to putting something on the MLs a request for comment or something because i know i suck at UX and people seem to have strong opinions
19:41:37 <jamielennox> also someone asked me the other day if this project was still around, so even if no-one resonds it's good for an update
19:41:53 <dtroyer> +1 to that
19:42:28 <briancurtin> that sounds good, both on the ML and probably just in general to be a blog post or something and see what people outside of openstack-dev think (as end-users)
19:42:52 <briancurtin> i can start writing something up as a bit of a status update and then an RFC on how people would want to use it
19:43:15 <dtroyer> having runnable examples to point to for specifics would be good (sez he who has no idean the current state of the examples)
19:44:35 <briancurtin> right now the examples are intentionally generic, mostly supporting the verbs. I think some service-specific examples could be helpful for this email/post/rfc
19:44:55 <terrylhowe> near as I know the examples work, but they are very generic at the moment
19:45:33 <jamielennox> generic is probably ok, we aren't going to change the current levels based on this we just want to figure out how to wrap them into something user friendly
19:46:17 <terrylhowe> well, the examples are more useful to a developer than a user
19:46:36 <briancurtin> once swift properly handles objects, it's an easy enough example to show listing containers, listing objects, downloading an object, in a relatively compact example
19:47:08 <notmyname> briancurtin: just saw your comment. what are you looking for in swift?
19:47:23 <terrylhowe> yeh, we should probably have some scenarios like that for compute and network as well
19:48:29 <briancurtin> notmyname: just building out the object resource for python-openstacksdk, have account and container done, just need to finish it up
19:49:59 <briancurtin> notmyname: FYI wasn't really a comment toward swift itself, but support of swift objects within the SDK project
19:50:08 <notmyname> understood
19:52:51 <briancurtin> so i'll start putting something of a status report together, then put together an RFC on how to move forward - will email it around within the next few days assuming some small examples can come together
19:53:44 <briancurtin> #action status report and RFC
19:53:56 <terrylhowe> I was planning on working  server metadata which might cover that one action item, but I’m not sure if it is going to fit the pattern we are looking for
19:54:26 <terrylhowe> either way, I’ll have something for server metadata and server ips
19:55:41 <briancurtin> cool, will keep an eye out for it, and let me know how i can help
19:56:25 <briancurtin> anything else in these last 5 minutes?
19:56:51 <jamielennox> i'm good
19:57:18 <terrylhowe> nothing here
19:57:45 <stevelle> same
19:58:07 <briancurtin> #endmeeting