15:30:17 #startmeeting openstack-sdk-php 15:30:19 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:30:22 The meeting name has been set to 'openstack_sdk_php' 15:30:34 Hello everyone. Please state your name along with any applicable association 15:30:37 Matt Farina, HP 15:30:44 Glen Campbell, Rackspace 15:30:45 Jamie Hannaford, Rackspace 15:30:46 Sam Choi, HP 15:31:51 Thanks for coming folks 15:32:08 #topic Agenda 15:32:26 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 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 3. Discussion: do we need a "scripts" or "bin" folder at the top level? (jamie_h) 15:32:26 4. Discussion: do we need our own autoloader? Can we rely on Composer's instead? (jamie_h) 15:32:33 Is there anything else we should add? 15:32:50 I have nothing else 15:33:09 I'm ok with the topics 15:33:23 ok 15:33:48 great. 15:34:02 #topic Reviews in progress - any questions/concerns? 15:34:31 #link https://review.openstack.org/#/q/status:open+project:stackforge/openstack-sdk-php,n,z 15:34:48 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 There are a number of them and due to dependencies some that could land have not yet 15:35:28 I'm in the process of reviewing that one right now 15:35:53 samchoi can you take a look at that one today as well? 15:36:23 mfer: sure, I had already reviewed a fairly recently patch so I'll check the additions today 15:36:30 great 15:36:40 that review reminds me, should Shaunak be reviewing that one as well? 15:36:45 sorry - my wifi died 15:36:48 sure 15:36:52 Or are we fine with having 2 core reviewers? 15:37:05 samchoi two is enough 15:37:34 mfer: thanks. Would the protocol be the same for very simple reviews? 2 core reviewers? 15:37:45 jamiehannaford samchoi and I are going to look at the guzzle work today 15:37:48 samchoi yes 15:38:04 mfer thanks 15:38:18 can I get a quick recap on what's just been said? 15:38:42 we're looking at the items that need to be reivewed starting with that one 15:39:04 i'd like that one to get finished soon so it stops blocking the others 15:39:24 yeah, exactly 15:39:29 that one's a blocker for me 15:39:29 besides the guzzle work, are there any other reviews we should discuss? 15:39:36 it's a blocker for me too 15:39:56 for now, I'd say no - we can talk about others next week probably 15:40:24 samchoi do you have any others you'd wanted to talk about? 15:40:57 no I'm good 15:41:18 #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 samchoi jamie_h would you like to get this discussion started? 15:42:13 samchoi did you have an opinion about the best way to refactor tests in line with proposal? 15:42:15 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 yeah, okay 15:42:48 I've been looking at other projects' test suites and see an array of approaches and am open to suggestions 15:43:12 so, in terms of approach - shall we refactor gradually (patch by patch) or do it all in 1 patch? 15:43:22 I don't think there's that much to do 15:43:43 stream wrappers were a big chunk of it (in terms of lines), which is in a pending patch 15:43:53 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 or, it could happen with each change being made 15:44:47 I prefer the second option, personally - as long as there isn't massive scope creep 15:45:02 samchoi which approaches of other SDKs caught your attention? 15:45:13 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 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 for now, IMO all we need to do is incorporate mocks when we unit test classes - which isn't that hard 15:46:17 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 fog's testing setup is...interesting :) 15:46:34 well, the old way at least 15:47:13 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 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 VCR is cools for integration tests where you're mixing lots of modules together, like a full run-through 15:48:17 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 integration testing (i.e. hitting the API) is also something I wanted to talk about 15:48:45 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 I definitely agree we need something for functional tests 15:49:44 jamie_h did you have something you wanted to suggest for integration tests? 15:50:13 I've been investigating testing tools we can use for integration tests 15:50:27 I really like the look of one, called http://behat.org/ 15:50:51 the basic idea is that you define each SDK feature as a "story" 15:51:07 that story is defined in human-readable language, and can be automatically tested against the API 15:51:52 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 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 This is quite scrum story based 15:54:05 can you point to any projects using behat? 15:54:46 i can find that out. It has like 600k downloads on packagist, so it's well-established 15:54:56 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 I'm trying to see how this would be useful for a developer consuming this library in addition to testing 15:55:15 it's making sure the experience of our users is well defined 15:55:23 a library like this is a slightly different animal 15:55:59 this is what I'm referring to: http://dannorth.net/whats-in-a-story/ 15:56:10 for example, i was looking at the acceptance tests of gophercloud (https://github.com/rackspace/gophercloud) 15:56:21 talking with a number of developers they thought this was a great idea 15:56:34 they are acceptance tests and they work great as examples of how to do things 15:56:58 the audience is developers rather than a PM who is checking the story in human readable language 15:57:12 i'm curious what y'all think 15:57:46 I haven't encountered a projet using behat yet, I have no opinion at the moment 15:58:01 it's a way of us defining user requirements 15:58:18 and testing them with our SDK 15:58:33 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 mfer I'll add that as an action point 15:59:11 we don't need to reach decisions now, just sharing what I've been researching recently 15:59:15 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 i think it's great. and i'm going to look more into behat 15:59:44 it's a tool that benefits any software project which has consumers 16:00:02 different kinds of consumers do things and prefer things in a different way 16:00:06 because you're defining their engagement and making sure those user requirements are always tested 16:00:19 lots of enterprise developers don't use scrum or stories. this will be different for them 16:01:09 it might be good if each of us who isn't familiar with behat can take a look at it 16:01:41 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 this is a good intro to behat: http://behat.readthedocs.org/en/latest/quick_intro.html 16:02:16 the whole idea of behat is for us to be able to target our audience and establish use cases 16:02:36 and then ensuring our SDK meets those user expectations 16:02:44 i think that's useful. the format matters as well. this is very scrum story formatted. 16:03:34 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 did you have other people in mind? 16:03:51 for the audience? 16:04:21 samchoi primarily for us. but it's accessible to anyone. we're effectively offering them blueprints of our features 16:04:30 it would serve as our integration suite 16:04:42 "make sure feature x works exactly as our users would want it to" 16:04:54 "if there's another conceivable use case, test that too" 16:04:57 all against the API 16:05:07 alright thanks for clarifying 16:05:34 jamie_h and our developer users would want to define that in a scrum story? 16:06:06 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 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 we'd have documentation for that 16:06:36 glenc can you make sure the folks on gophercloud know that people liked the style of acceptance tests 16:07:15 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 jamie_h samchoi i always like comparing things. it helps ideas to pop or not. what would the alternative be? 16:07:50 write stand alone scripts that hit the API 16:08:06 jamie_h those acceptance tests are written in a format developers like. Code. That's really really important. 16:08:30 Personally, I'd rather write code than a story any day 16:08:42 all acceptance tests will need to be written in code - but the priority is making sure customer use cases are met 16:08:47 with a script that gets ambiguous 16:08:50 mfer - I will pass that along 16:09:02 customers are other developers. not management or PMs. that's important here 16:09:06 sample code + documentation is what devs will go to 16:09:29 besides devs as customers who else is there? 16:09:41 it's the devs who consume it and the devs who work on it 16:09:58 I question so much because I want anything we do to fit well. 16:10:04 I would think that's basically it, no? 16:11:28 with standalone scripts, you're not testing dev use cases. you're just ensuring that nothing breaks 16:11:34 that's my only concern 16:11:47 we need to make sure devs are getting what they should 16:12:19 shall postpone this until next week when we've had more time to research stuff? 16:12:26 sure jamie_h 16:12:50 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 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 are we ready to move on? 16:14:22 sure 16:14:23 yep 16:14:27 #topic Discussion: do we need a "scripts" or "bin" folder at the top level? (jamie_h) 16:14:52 just a general question: what do we anticipate these folders get used for? 16:14:59 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 okay 16:15:18 just want to keep top-level as light as possible 16:15:20 anyone disagree? 16:15:58 I'm in favor on anything that simplifies the directory structure...we have plenty of layers already 16:16:05 favor of* 16:16:52 great 16:17:02 shall we move on to the autoloader discussion? 16:17:16 I have nothing more to add 16:17:34 sure, go ahead mfer 16:18:15 #topic Discussion: do we need our own autoloader? Can we rely on Composer's instead? (jamie_h) 16:18:50 realistically - do we need our own autoloader class? 16:19:30 i don't think so. we should just document using it with another autoloader. 16:19:36 +1 16:19:52 +1 16:20:17 for everyone's interest, ZF3 might be doing this too: https://github.com/zendframework/zf2/issues/6285 16:20:43 plus, IDK how our autoloader handles dependencies like guzzle 16:21:13 likely doesn't 16:21:27 lets delete it 16:21:35 i'm happy to take that on too 16:21:45 ok, i think that's everything on the agenda 16:21:51 #topic Open Discussion 16:21:59 who wants to talk about what 16:22:00 ? 16:22:42 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 If not, I'm interested in seeing how well it'd work for our purposes 16:23:23 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 since it'd simply speed up our HTTP requests and doesn't seem to have a drawback 16:23:51 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 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 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 samchoi sure okay 16:24:29 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 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 when reviews go into gerrit the tests should be automated against a real api. we can do this i'm told 16:25:56 hmm I'll follow up on this 16:26:11 I'd assume others are just creating new VCR cassettes after a set period 16:26:45 with VCR you can refresh cassettes by overriding their content with a new API hit, I think 16:27:18 mfer would we have control over which tests to run when a patch enters gerrit? like travis 16:27:34 i belive we have that control 16:27:52 awesome 16:28:02 that can't come soon enough IMO :) 16:28:11 we'd have any control we'd have anywhere else because we'd script what gets run 16:29:03 we have two minutes left. anything else before we wrap this up for the next group? 16:30:07 not from me 16:30:14 #endmeeting