19:00:25 <briancurtin> #startmeeting python-openstacksdk
19:00:25 <openstack> Meeting started Tue Aug 19 19:00:25 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:26 <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:01:01 <briancurtin> if you're here for the python-openstacksdk meeting, say hi
19:01:04 <terrylhowe> Terry Howe, HP
19:01:06 <briancurtin> Brian Curtin, Rackspace
19:02:29 <stevelle> Steve Lewis, Rackspace
19:02:45 <jamielennox> Jamie Lennox, Red Hat
19:03:42 <briancurtin> i don't have a ton to talk about other than thinking about these more complex resources that we're hitting now (that's basically all the agenda has: https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-08-12_1900_UTC)
19:04:18 <briancurtin> i have started a scratch pad of ideas for updating openstack-dev, but want to have some of these things more fleshed out when we go to ask about people's input on higher level views
19:04:52 <terrylhowe> I marked that ServerInterface review WIP because I realized I didn’t have any tests
19:06:34 <terrylhowe> ServerInterface has the path_args in it
19:07:19 <briancurtin> terrylhowe: now that we're on to needing extra info like in that ServerInterface change, it feels like it's going to be a hassle to build on top of while targeting a simple command line script
19:07:35 <briancurtin> but i guess that's a consequence of the spot we're in
19:08:09 <briancurtin> everything works relatively nicely right now running stuff out of the examples dir, which is cool
19:08:38 <jamielennox> so what is the complex resource you are hitting and what do we need to solve?
19:08:47 <terrylhowe> yeh, it is kind of complicated.  It may be better to try it with an Idnetity example
19:08:51 <terrylhowe> https://review.openstack.org/#/c/115047/
19:09:33 <terrylhowe> I put together an implementation and *then* realized I didn’t have it available to functional test
19:10:15 <terrylhowe> Instead of path_args, maybe there should be some sort of url args or url builder
19:10:31 <jamielennox> the identity one i know is a user and role are top level concepts, but a user has roles ie /user/X/roles/Y and IMO that should be a role object
19:11:53 <stevelle> I'm beginning to block on similar issues with ceilometer meter samples and alarm history
19:11:56 <terrylhowe> Yeh, I’d have access to that at least
19:13:01 <briancurtin> terrylhowe: i kind of just wish a lot of this stuff wasn't classmethods. would make some of the url building easier
19:14:34 <jamielennox> briancurtin: we talked about this and it's probably a good idea to make it so
19:14:48 * briancurtin forgot to mention - i need to leave this meeting in roughly 35 min for a doctor appointment
19:15:46 <terrylhowe> stevelle: since most of the oddball ceilomter calls don’t have full crud, maybe they could just be methods of the related resource
19:16:22 <briancurtin> jamielennox: yeah. maybe i'll take a hack at that next, because i wasn't liking the way i was working with swift objects (after i un-hardcoded a bunch of stuff, hah)
19:17:36 <jamielennox> briancurtin: i was thinking about it, and i don't know how yet but our objects should be just containers for data
19:17:40 <stevelle> terrylhowe:  the properties of samples and alarm are very different from the resources they are nested under, they need to be a different model, trying to make that work.
19:18:09 <jamielennox> i don't know if there should be any inbuilt knowledge of how you get that data
19:18:19 <terrylhowe> stevelle: maybe a one off like ServerIP
19:18:44 <jamielennox> so in my previous example a Role (something consistent with the format) at any sub-url should be a role object
19:19:44 <stevelle> terrylhowe: that was the model I was working on today
19:20:36 <terrylhowe> stevelle: that is probably a good approach on those
19:21:03 <stevelle> terrylhowe: I suspect it will look funny but we can bring it to review
19:21:44 <briancurtin> jamielennox: yeah i bounce back and forth between containers and having some knowledge. i flip back and forth enough times i think i just need to hack a few different ways instead of thinking so much
19:22:25 <jamielennox> briancurtin: yea, i know exactly what you mean, there is definitely an argument for both
19:22:35 <terrylhowe> as far as the path_args thing, does anyone have any other ideas on that?  should there be a get_path class method for resources for example?
19:22:50 <jamielennox> the idea was to be kind of sqlalchemy-ish but i don't think the mappings are as 1-to-1 here
19:25:09 <terrylhowe> well, maybe implementing Role will help with ideas
19:25:11 <briancurtin> terrylhowe: i dont really have a great suggestion yet. it just feels wrong, but i dont have enough experience working on top of it to say exactly how to change it. kind of a half-assed response
19:25:19 <jamielennox> briancurtin: a part of my concern here is that if we do need a layer above the resource objects, then that's getting close to managers and i've wasted a lot of people's time by advocating away from them
19:26:33 <briancurtin> jamielennox: i think a potential layer above would mostly solve having to pass in a session to every call, and maybe that's where we bridge together these nested resources. or something
19:26:44 <briancurtin> i imagine it being fairly thin
19:28:20 <terrylhowe> As Dean would say, we need a strawman to beat on for that
19:28:40 <terrylhowe> Once we have something on that though, it might resemble a real product
19:29:57 <terrylhowe> jamielennox: dod you have anything in the works with identity?
19:30:32 <jamielennox> terrylhowe: not as yet, i got started last week as you saw but didn't get futher than that
19:30:55 <jamielennox> terrylhowe: have been meaning to get back and just keep adding a few a week
19:31:00 <terrylhowe> well, as long as it is okay with you, maybe I’ll try Role later in the week then
19:31:06 <jamielennox> terrylhowe: sure
19:31:13 <terrylhowe> cool
19:31:49 <terrylhowe> back to higher level stuff, are there any baby steps we can take for that?
19:33:28 <briancurtin> terrylhowe: i dont know if its a good idea or not, but i kind of want to just write a thin layer for swift and then back it out into something perhaps more generic, and see what it looks like
19:33:55 <briancurtin> that'll let me see how to get the container into the object class from that higher level
19:34:19 <briancurtin> and whatever other niceties we may get out of that higher level view
19:35:47 <terrylhowe> doesn’t seem like a baby step, but I have no better ideas
19:36:48 <terrylhowe> I don’t think it will that bad though
19:37:28 <briancurtin> fwiw, i'm at the CloudOpen conference this week so i wont have a ton of time, but i'll try to hack a bit
19:42:14 <briancurtin> i have to take off in a few minutes, but does anyone have anything else? sorry for this not being super productive, i guess we just have to try a bunch of stuff and see where it goes
19:42:35 <terrylhowe> nothing here
19:44:04 <jamielennox> i'm good
19:44:11 <stevelle> nothing more
19:44:41 <briancurtin> cool, thanks everyone. i'll still keep an eye on reviews while i'm at this conf and try to sneak in some hacking
19:45:04 <briancurtin> #endmeeting