15:30:17 <mfer> #startmeeting openstack-sdk-php
15:30:19 <openstack> Meeting started Wed Jun  4 15:30:17 2014 UTC and is due to finish in 60 minutes.  The chair is mfer. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:30:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:30:22 <openstack> The meeting name has been set to 'openstack_sdk_php'
15:30:34 <mfer> Hello everyone. Please state your name along with any applicable association
15:30:37 <mfer> Matt Farina, HP
15:30:44 <glenc> Glen Campbell, Rackspace
15:30:45 <jamie_h> Jamie Hannaford, Rackspace
15:30:46 <samchoi> Sam Choi, HP
15:31:51 <mfer> Thanks for coming folks
15:32:08 <mfer> #topic Agenda
15:32:26 <mfer> 1. Reviews in progress - any questions/concerns? We are quickly accumulating reviews that touch overlapping files. It would be in our best interest to move forward with reviews soon. (samchoi)
15:32:26 <mfer> 2. Testing discussion, how to approach refactoring of tests, etc (samchoi). Also how are we going to approach integration tests (jamie_h)
15:32:26 <mfer> 3. Discussion: do we need a "scripts" or "bin" folder at the top level? (jamie_h)
15:32:26 <mfer> 4. Discussion: do we need our own autoloader? Can we rely on Composer's instead? (jamie_h)
15:32:33 <mfer> Is there anything else we should add?
15:32:50 <jamie_h> I have nothing else
15:33:09 <samchoi> I'm ok with the topics
15:33:23 <glenc> ok
15:33:48 <mfer> great.
15:34:02 <mfer> #topic Reviews in progress - any questions/concerns?
15:34:31 <mfer> #link https://review.openstack.org/#/q/status:open+project:stackforge/openstack-sdk-php,n,z
15:34:48 <samchoi> Since this patch is needed by a few others, I believe it'd be worth discussing the status: https://review.openstack.org/#/c/93089/
15:34:48 <mfer> There are a number of them and due to dependencies some that could land have not yet
15:35:28 <mfer> I'm in the process of reviewing that one right now
15:35:53 <mfer> samchoi can you take a look at that one today as well?
15:36:23 <samchoi> mfer: sure, I had already reviewed a fairly recently patch so I'll check the additions today
15:36:30 <mfer> great
15:36:40 <samchoi> that review reminds me, should Shaunak be reviewing that one as well?
15:36:45 <jamiehannaford> sorry - my wifi died
15:36:48 <mfer> sure
15:36:52 <samchoi> Or are we fine with having 2 core reviewers?
15:37:05 <mfer> samchoi two is enough
15:37:34 <samchoi> mfer: thanks. Would the protocol be the same for very simple reviews? 2 core reviewers?
15:37:45 <mfer> jamiehannaford samchoi and I are going to look at the guzzle work today
15:37:48 <mfer> samchoi yes
15:38:04 <jamiehannaford> mfer thanks
15:38:18 <jamiehannaford> can I get a quick recap on what's just been said?
15:38:42 <mfer> we're looking at the items that need to be reivewed starting with that one
15:39:04 <mfer> i'd like that one to get finished soon so it stops blocking the others
15:39:24 <jamiehannaford> yeah, exactly
15:39:29 <jamiehannaford> that one's a blocker for me
15:39:29 <mfer> besides the guzzle work, are there any other reviews we should discuss?
15:39:36 <mfer> it's a blocker for me too
15:39:56 <jamiehannaford> for now, I'd say no - we can talk about others next week probably
15:40:24 <mfer> samchoi do you have any others you'd wanted to talk about?
15:40:57 <samchoi> no I'm good
15:41:18 <mfer> #topic Testing discussion, how to approach refactoring of tests, etc (samchoi). Also how are we going to approach integration tests (jamie_h)
15:41:35 <mfer> samchoi jamie_h would you like to get this discussion started?
15:42:13 <jamie_h> samchoi did you have an opinion about the best way to refactor tests in line with proposal?
15:42:15 <samchoi> I primarily just wanted to get a feel for how to best proceed with refactoring current tests, given jamie_h's email to the dev mailing list
15:42:22 <jamie_h> yeah, okay
15:42:48 <samchoi> I've been looking at other projects' test suites and see an array of approaches and am open to suggestions
15:43:12 <jamie_h> so, in terms of approach - shall we refactor gradually (patch by patch) or do it all in 1 patch?
15:43:22 <jamie_h> I don't think there's that much to do
15:43:43 <jamie_h> stream wrappers were a big chunk of it (in terms of lines), which is in a pending patch
15:43:53 <mfer> jamie_h i think it depends on how it comes in. if you wanted to write a patch it would get reviewed
15:44:02 <mfer> or, it could happen with each change being made
15:44:47 <jamie_h> I prefer the second option, personally - as long as there isn't massive scope creep
15:45:02 <jamie_h> samchoi which approaches of other SDKs caught your attention?
15:45:13 <samchoi> I don't have a strong opinion on either way at the moment. I do wonder if the one shot approach would potentially become a blocker if it's too large though
15:45:54 <samchoi> The one that's caught my attention the most is the Ruby SDK, despite not having had enough time to look through it in detail yet jamie_h
15:46:11 <jamie_h> for now, IMO all we need to do is incorporate mocks when we unit test classes - which isn't that hard
15:46:17 <samchoi> I spoke with a few of them, and their approach seems to be in line with what you pointed out in the email jamie_h
15:46:29 <jamie_h> fog's testing setup is...interesting :)
15:46:34 <jamie_h> well, the old way at least
15:47:13 <samchoi> they also spoke highly of VCR, which makes me wonder if PHP-VCR may be a good addition for our testing suite
15:47:47 <jamie_h> the problem I have with VCR is that it doesn't help unit tests at all - because units of code should be isolated. capturing network traffic, although clever, goes against that isolation
15:48:14 <jamie_h> VCR is cools for integration tests where you're mixing lots of modules together, like a full run-through
15:48:17 <mfer> this is more their way of handling integration testing w/o having an environment for that. they don't have the same limitations we do.
15:48:41 <jamie_h> integration testing (i.e. hitting the API) is also something I wanted to talk about
15:48:45 <samchoi> jamie_h: Correct, but the Ruby guys had mentioned to me that their focus was on unit and functional tests, with fucntional tests benefitting from VCR
15:49:06 <jamie_h> I definitely agree we need something for functional tests
15:49:44 <mfer> jamie_h did you have something you wanted to suggest for integration tests?
15:50:13 <jamie_h> I've been investigating testing tools we can use for integration tests
15:50:27 <jamie_h> I really like the look of one, called http://behat.org/
15:50:51 <jamie_h> the basic idea is that you define each SDK feature as a "story"
15:51:07 <jamie_h> that story is defined in human-readable language, and can be automatically tested against the API
15:51:52 <jamie_h> the whole idea is that it allows us to define the scope of a feature (listContainers, getContainer) and define its acceptance criteria, i.e. a common definiton of "done"
15:53:22 <jamie_h> so apart from integration testing, we also know what our customer's use-cases are and have a way of tracking when those features are complete (project progress)
15:53:22 <mfer> This is quite scrum story based
15:54:05 <mfer> can you point to any projects using behat?
15:54:46 <jamie_h> i can find that out. It has like 600k downloads on packagist, so it's well-established
15:54:56 <mfer> i'm thinking about this project in terms of developer experience. this is a little different from a PHP app built by a team. I can see how behat is useful for that... especially with stories
15:55:15 <mfer> I'm trying to see how this would be useful for a developer consuming this library in addition to testing
15:55:15 <jamie_h> it's making sure the experience of our users is well defined
15:55:23 <mfer> a library like this is a slightly different animal
15:55:59 <jamie_h> this is what I'm referring to: http://dannorth.net/whats-in-a-story/
15:56:10 <mfer> for example, i was looking at the acceptance tests of gophercloud (https://github.com/rackspace/gophercloud)
15:56:21 <mfer> talking with a number of developers they thought this was a great idea
15:56:34 <mfer> they are acceptance tests and they work great as examples of how to do things
15:56:58 <mfer> the audience is developers rather than a PM who is checking the story in human readable language
15:57:12 <mfer> i'm curious what y'all think
15:57:46 <samchoi> I haven't encountered a projet using behat yet, I have no opinion at the moment
15:58:01 <jamie_h> it's a way of us defining user requirements
15:58:18 <jamie_h> and testing them with our SDK
15:58:33 <mfer> jamie_h do you know of any open source libraries using behat. i'd like to look at usage and who it applies to
15:58:57 <jamie_h> mfer I'll add that as an action point
15:59:11 <jamie_h> we don't need to reach decisions now, just sharing what I've been researching recently
15:59:15 <mfer> i'll tell ya, what we did in my last gig would have benefited from behat. i'm just not sure about an SDK with all developers working on it.
15:59:27 <mfer> i think it's great. and i'm going to look more into behat
15:59:44 <jamie_h> it's a tool that benefits any software project which has consumers
16:00:02 <mfer> different kinds of consumers do things and prefer things in a different way
16:00:06 <jamie_h> because you're defining their engagement and making sure those user requirements are always tested
16:00:19 <mfer> lots of enterprise developers don't use scrum or stories. this will be different for them
16:01:09 <mfer> it might be good if each of us who isn't familiar with behat can take a look at it
16:01:41 <mfer> it might be good to look at who our target audiences are (and not assume that ourselves are the 80% of that group in style) and look at the context
16:01:56 <jamie_h> this is a good intro to behat: http://behat.readthedocs.org/en/latest/quick_intro.html
16:02:16 <jamie_h> the whole idea of behat is for us to be able to target our audience and establish use cases
16:02:36 <jamie_h> and then ensuring our SDK meets those user expectations
16:02:44 <mfer> i think that's useful. the format matters as well. this is very scrum story formatted.
16:03:34 <samchoi> jamie_h: I would think that the test suite is primarily for the contributors as I think it's unlikely that many casual users would be too concerned with understanding/reading the entire test suite.
16:03:45 <samchoi> did you have other people in mind?
16:03:51 <samchoi> for the audience?
16:04:21 <jamie_h> samchoi primarily for us. but it's accessible to anyone. we're effectively offering them blueprints of our features
16:04:30 <jamie_h> it would serve as our integration suite
16:04:42 <jamie_h> "make sure feature x works exactly as our users would want it to"
16:04:54 <jamie_h> "if there's another conceivable use case, test that too"
16:04:57 <jamie_h> all against the API
16:05:07 <samchoi> alright thanks for clarifying
16:05:34 <mfer> jamie_h and our developer users would want to define that in a scrum story?
16:06:06 <jamie_h> mfer they could look at the use-cases if they wanted to, but it's primarily about us understanding what our users want from our SDK
16:06:18 <mfer> that's what I'm questioning. particularly after the summit where just about no one like things done for you. they all wanted to write and see code. that's why so many people liked the gophercloud style of acceptance tests
16:06:31 <jamie_h> we'd have documentation for that
16:06:36 <mfer> glenc can you make sure the folks on gophercloud know that people liked the style of acceptance tests
16:07:15 <jamie_h> although i see the appeal of gophercloud's acceptance tests, it doesn't offer anything that good example code or documentation can
16:07:38 <mfer> jamie_h samchoi i always like comparing things. it helps ideas to pop or not. what would the alternative be?
16:07:50 <jamie_h> write stand alone scripts that hit the API
16:08:06 <mfer> jamie_h those acceptance tests are written in a format developers like. Code. That's really really important.
16:08:30 <mfer> Personally, I'd rather write code than a story any day
16:08:42 <jamie_h> all acceptance tests will need to be written in code - but the priority is making sure customer use cases are met
16:08:47 <jamie_h> with a script that gets ambiguous
16:08:50 <glenc> mfer - I will pass that along
16:09:02 <mfer> customers are other developers. not management or PMs. that's important here
16:09:06 <jamie_h> sample code + documentation is what devs will go to
16:09:29 <mfer> besides devs as customers who else is there?
16:09:41 <mfer> it's the devs who consume it and the devs who work on it
16:09:58 <mfer> I question so much because I want anything we do to fit well.
16:10:04 <samchoi> I would think that's basically it, no?
16:11:28 <jamie_h> with standalone scripts, you're not testing dev use cases. you're just ensuring that nothing breaks
16:11:34 <jamie_h> that's my only concern
16:11:47 <jamie_h> we need to make sure devs are getting what they should
16:12:19 <jamie_h> shall postpone this until next week when we've had more time to research stuff?
16:12:26 <samchoi> sure jamie_h
16:12:50 <mfer> can't you test use cases by writing them? then folks who consume it have example code of exactly how to do that the best way. and if someone has a better way it can be changed?
16:13:19 <mfer> i think we should postpone this. get to know behat and spend some time focusing on the needs of our audiences. that could be good
16:14:10 <mfer> are we ready to move on?
16:14:22 <samchoi> sure
16:14:23 <jamie_h> yep
16:14:27 <mfer> #topic Discussion: do we need a "scripts" or "bin" folder at the top level? (jamie_h)
16:14:52 <jamie_h> just a general question: what do we anticipate these folders get used for?
16:14:59 <mfer> I think we can delete these folders. In practice we don't need them and they had been added as part of the pear spec
16:15:11 <jamie_h> okay
16:15:18 <jamie_h> just want to keep top-level as light as possible
16:15:20 <mfer> anyone disagree?
16:15:58 <samchoi> I'm in favor on anything that simplifies the directory structure...we have plenty of layers already
16:16:05 <samchoi> favor of*
16:16:52 <mfer> great
16:17:02 <mfer> shall we move on to the autoloader discussion?
16:17:16 <jamie_h> I have nothing more to add
16:17:34 <samchoi> sure, go ahead mfer
16:18:15 <mfer> #topic Discussion: do we need our own autoloader? Can we rely on Composer's instead? (jamie_h)
16:18:50 <jamie_h> realistically - do we need our own autoloader class?
16:19:30 <mfer> i don't think so. we should just document using it with another autoloader.
16:19:36 <glenc> +1
16:19:52 <jamie_h> +1
16:20:17 <jamie_h> for everyone's interest, ZF3 might be doing this too: https://github.com/zendframework/zf2/issues/6285
16:20:43 <jamie_h> plus, IDK how our autoloader handles dependencies like guzzle
16:21:13 <mfer> likely doesn't
16:21:27 <mfer> lets delete it
16:21:35 <mfer> i'm happy to take that on too
16:21:45 <mfer> ok, i think that's everything on the agenda
16:21:51 <mfer> #topic Open Discussion
16:21:59 <mfer> who wants to talk about what
16:22:00 <mfer> ?
16:22:42 <samchoi> I didn't want to slow us down before, but did anyone have any reasons why PHP-VCR couldn't be used to supplement our test suite?
16:23:10 <samchoi> If not, I'm interested in seeing how well it'd work for our purposes
16:23:23 <jamie_h> from my perspective, we need two types of tests: unit tests (which are isolated, thus don't need VCR) and acceptance/integration tests
16:23:30 <samchoi> since it'd simply speed up our HTTP requests and doesn't seem to have a drawback
16:23:51 <jamie_h> IDK whether VCR will help us with acceptance tests because we need a real API response to judge whether our feature works
16:24:16 <samchoi> Well yes, it's definitely not for unit tests. Why not use it for other tests though? I could reach out to the Ruby guys again, but they've had great success with it
16:24:25 <jamie_h> don't get me wrong - I really really like VCR and have used it before. I just don't know whether it helps us
16:24:28 <jamie_h> samchoi sure okay
16:24:29 <mfer> we need to get setup on the openstack infra for testing. VCR might help to speed up local testing but we should hit a real API
16:24:51 <jamie_h> if we all think we need to hit a real API for acceptance tests, not sure that VCR is the tool for us
16:25:32 <mfer> when reviews go into gerrit the tests should be automated against a real api. we can do this i'm told
16:25:56 <samchoi> hmm I'll follow up on this
16:26:11 <samchoi> I'd assume others are just creating new VCR cassettes after a set period
16:26:45 <jamie_h> with VCR you can refresh cassettes by overriding their content with a new API hit, I think
16:27:18 <jamie_h> mfer would we have control over which tests to run when a patch enters gerrit? like travis
16:27:34 <mfer> i belive we have that control
16:27:52 <jamie_h> awesome
16:28:02 <jamie_h> that can't come soon enough IMO :)
16:28:11 <mfer> we'd have any control we'd have anywhere else because we'd script what gets run
16:29:03 <mfer> we have two minutes left. anything else before we wrap this up for the next group?
16:30:07 <glenc> not from me
16:30:14 <mfer> #endmeeting