19:00:44 <briancurtin> #startmeeting python-openstacksdk
19:00:44 <openstack> Meeting started Tue Apr 14 19:00:44 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:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:48 <openstack> The meeting name has been set to 'python_openstacksdk'
19:01:29 <briancurtin> if you're around for the SDK meeting, say hi. there's nothing really formal on the docket, just getting back into it after mostly a week off
19:01:39 <terrylhowe> o/
19:02:06 <etoews> o/
19:02:41 <dtroyer> o//
19:02:57 * dtroyer not a genetic mutation, still unable to type
19:03:41 <terrylhowe> fingers not fists
19:04:53 <briancurtin> so we were able to get the delete pushed through, and currently have get and create proxy implementations in there. im going to go back through the get comments this afternoon and tomorrow afternoon (flying out tomorrow morning)
19:04:53 <etoews> if there's nothing formal, should we just work through the patch queue and see what needs to be done?
19:05:16 <briancurtin> i guess one discussion i would actually like to have is what the create one should actually be doing
19:05:23 <etoews> sgtm
19:07:05 <briancurtin> so i had originally started with something like create_server(self, value=None, **attrs). if you give it a value (an instance of Server), it uses that value as the base to make the request. if you also give it attrs, it sets them on the value. if you only provide attrs, it will create a Server, set the attrs, and send it on. (cont)
19:08:37 <briancurtin> there seemed to be a thought that it should only work with one or the other - you either pass in a resource populated with the props you want, or you pass in kwargs to represent those props - not both. instead the create would have those args mutually exclusive, and something like clone_server could work with both. i dont love that, but i also dont love some
19:08:37 <briancurtin> of the awkwardness of create_server potentially having mutually exclusive args
19:09:03 <briancurtin> (that's a longer version of what terry commented on https://review.openstack.org/#/c/168448/2/openstack/compute/v2/_proxy.py
19:09:40 <briancurtin> terrylhowe: i just saw your comment on there. if we took the way from your last comment, what would be the way to create from a resource object?
19:10:55 <terrylhowe> well, if just_like_this_one was a server resource, it would clone
19:11:12 <terrylhowe> server create proxy could have logic to remove the id maybe
19:11:25 <terrylhowe> for convenience of the user
19:12:03 <briancurtin> i think that's what i originally had in mind
19:12:20 <briancurtin> maybe i'll swing it back that direction and see how that works
19:13:06 <terrylhowe> has any work been done to propogate the delete changes to other proxies?
19:13:39 <briancurtin> terrylhowe: not yet, that had been approved right around when i took off for montreal. i can throw that together within the next day
19:13:49 <briancurtin> perhaps in a bit after this meeting depending on what's going on here
19:13:53 <terrylhowe> k
19:14:03 * briancurtin is dancing back and forth between several sprints
19:15:42 <briancurtin> dtroyer: one thing i want to look more into is how SDK can provide you with a backend. what is the ideal output we could give you that you'd ingest in OSC? i seem to remember you wanted to be able to get the raw JSON without going through resource object creation and such
19:16:22 <briancurtin> and i also seem to remember you had started to hack with something - is that still around anywhere that i could try and bridge the gap between there and where SDK is at now?
19:17:23 <dtroyer> briancurtin: closer to decoded JSON, but basically that.  Plus any 'fixes' like s/tenant/project/ etc.
19:17:46 <dtroyer> The original proposal is still in gerrit, but the current implementation is what is in openstackclient.api
19:19:15 <briancurtin> dtroyer: cool, will take a look. i think i might have something. will probably get to it later in the week
19:21:06 <briancurtin> terrylhowe: on https://review.openstack.org/#/c/164061/3/openstack/orchestration/v1/stack.py the name_attribute is set to point to that stack_name, so .name will still work -- i think it maybe makes sense to do it how it is in that review
19:22:04 <terrylhowe> well, I normally think that the name of a resource will be resource.name
19:22:42 <terrylhowe> it’ll work as it is, but from the ux view
19:23:28 <briancurtin> hmm, yeah
19:23:29 <terrylhowe> etoews: ?
19:24:06 <etoews> i'm just giving this another look...
19:24:10 <etoews> it's been a while
19:25:14 <briancurtin> the only other places we use name_attribute are for keypair "fingerprint" and floating ip's "floating_ip_address" -- i guess this could just go directly to being the name prop
19:26:03 <etoews> hold on
19:26:55 <etoews> but note how above that i did `name_attribute = 'stack_name'`
19:27:24 <etoews> so you still wind up using stack.name
19:27:43 <briancurtin> and you additionally have stack.stack_name
19:28:02 <etoews> do we want to hide that?
19:28:26 <briancurtin> however, that's not unique to this - the other two examples i said also have it, so now i'm trying to wrap my head around it
19:28:59 <etoews> i just looked at that too
19:29:45 <etoews> keypair.py and floating_ip.py both have it
19:30:42 <etoews> it would be particularly weird to not have floating_ip_address in FloatingIP
19:31:05 <terrylhowe> yeh, maybe it doesn’t matter because it may be that stack.name and stack.stack_name will both work
19:31:13 <briancurtin> and it ends up being used by find, and i get why it's used there - that method is sort of in flux with the other API stuff we're doing, but that'll live somewhere if not where it is. so i guess we need it. having both isn't awesome, but it's effectively an alias we need to know about internally
19:31:32 <briancurtin> so maybe this is all fine as it is in the review
19:31:56 <terrylhowe> yeh, we do need some tests on the create method though
19:32:11 <briancurtin> true
19:33:10 <terrylhowe> hah, jamie is in there now
19:34:13 <etoews> i'm not 100% sure what you mean. can you point me to a good example of tests on the create method in another resource please?
19:34:14 <briancurtin> yeah, good points - and we've gotten rid of those redundancies anywhere else
19:35:32 <etoews> i'm missing something.
19:35:39 <etoews> jamie is where?
19:35:49 <etoews> what redundancies?
19:35:50 <briancurtin> etoews: https://review.openstack.org/#/c/164061/
19:36:00 <briancurtin> etoews: stack_ prefix on a few otehr things
19:36:51 <etoews> ah
19:36:59 <briancurtin> etoews: so s/stack_status/status and s/stack_status_reason/status_reason -- we've trimmed a few other things like that around other services. blanking on an example off the top of my head though
19:37:29 <etoews> okay. but do we keep stack_name though?
19:38:48 <briancurtin> name = resource.prop("stack_name") is better in that it doesn't have the duplication. i gues i need to research the full reason of why we have name_attribute in case it's anything outside of the Resource.find
19:39:27 <briancurtin> it doesn't seem like it, and it looks mostly like a convenience thing, although a convenience we don't totally need since you can just set name directly
19:39:55 <briancurtin> it seems like it's there to make sure everything has a name, but everything can have a name if you just set a name
19:40:43 <briancurtin> it's like the opposite of id_attribute, which is set to name on the object_store stuff since they don't actually have the traditional ID values other things do
19:40:50 <terrylhowe> https://github.com/stackforge/python-openstacksdk/blob/master/openstack/tests/unit/compute/v2/test_server_meta.py#L50
19:40:55 <terrylhowe> ^^ create test
19:42:07 <etoews> thx terrylhowe
19:42:07 <terrylhowe> I originally added name_attribute just for find, there wasn’t a name method I don’t think at the time
19:42:30 <etoews> name_attribute is used in a handful of methods in resource.py
19:42:46 <etoews> the name methods, from_name, and find
19:43:13 <terrylhowe> anyway, https://review.openstack.org/#/c/170343/ are we ready?
19:43:34 <etoews> i am :)
19:43:50 <briancurtin> from_name is probably going away, and we don't really need the name methods, and find sort of has to change. i know that's thinking further ahead, but i think name=prop('stack_name") is the way
19:44:02 <briancurtin> terrylhowe, etoews let me double check, i think i'm ready on it
19:44:46 <terrylhowe> yeh agreed briancurtin on all that name stuff, it needs some attention as does find
19:45:05 <etoews> just to confirm. this is the canonical place for our docs right? http://python-openstacksdk.readthedocs.org/en/latest/
19:45:41 <briancurtin> yeah the name stuff was there to help the object_store proxy's implementation, but since we're not going that way, they won't be needed. i'll do that cleanup once we get further along in doing mass changes that touch those methods
19:46:23 <briancurtin> and yes, functional is now +2'ed
19:46:33 <etoews> cool.
19:47:53 <etoews> i'm all for these mass changes and stabilizing the internal api but where does that leave me for developing support for services right now?
19:48:15 <etoews> the orchestration patch is a good example
19:48:53 <etoews> seems like so much will be changing/shifting i'm not really sure if i should pursue the patch now or wait until the internal api stabilizes.
19:49:13 <briancurtin> etoews: can you link the orch patch?
19:49:46 <etoews> the one we've been discussing https://review.openstack.org/#/c/164061/
19:50:14 <briancurtin> hah, thought you were referencing another one
19:50:33 <terrylhowe> it’d be nice if that went in before a mass create change
19:50:36 <briancurtin> etoews: i think you're fine to just go with it. especially on create that one is going to take some time in review
19:50:41 <etoews> am i making sense or am i being overly cautious
19:51:00 <etoews> alright. i'll just go for it.
19:51:01 <terrylhowe> only the proxy part might change I think
19:52:31 <briancurtin> yep, that'll be the only part affected
19:54:22 <etoews> so now that we have 1 functional test. do we want to consider integration tests?
19:54:59 <etoews> wait. maybe i shouldn't have used the word "integration".
19:55:07 <briancurtin> yeah i need a different word in there
19:55:11 <etoews> means different things to different people
19:55:44 <etoews> so eventually we'll have a bunch of functional tests (and that's great) but they'll take a long time to run.
19:56:08 <etoews> and may fail in weird ways because they're running against a live cloud
19:56:59 <etoews> do we want to consider using something like betamax or vcr.py with requests?
19:57:19 <briancurtin> i'm not familiar with those, but i know ian is
19:57:41 <etoews> http://betamax.readthedocs.org/en/latest/
19:57:46 <terrylhowe> as long as the recorded responses are managable
19:57:54 <etoews> that's where i got it (from ian)
19:58:01 <etoews> i caught his talk at pycon
19:58:16 <etoews> something to think about
19:58:48 <etoews> i can see a future where running all functional tests could take longer than an hour
19:58:52 <terrylhowe> the ruby guys were doing something similar and it got unmanagable because one change and everything would change
19:59:21 <terrylhowe> yeh, good way to go for a gate especially
19:59:37 <terrylhowe> run the real test less frequently
19:59:41 <etoews> yep
20:00:02 <etoews> nightly against the public clouds and a devstack instance
20:00:08 <etoews> or something like that
20:00:13 <etoews> food for thought
20:00:39 <briancurtin> will look into it and check out his video
20:00:50 <etoews> i suppose i should have said sigmavirus24 ^
20:00:57 <briancurtin> and that's time. thanks everyone, good meeting
20:01:06 <terrylhowe> cya
20:01:10 <briancurtin> #endmeeting