18:07:16 <sputnik13> #startmeeting cue
18:07:17 <openstack> Meeting started Tue Apr 14 18:07:16 2015 UTC and is due to finish in 60 minutes.  The chair is sputnik13. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:07:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:07:21 <openstack> The meeting name has been set to 'cue'
18:07:31 <davideagnello> :)
18:07:37 <sputnik13> there, now it's going all under cue
18:08:07 <sputnik13> ok, our second meeting
18:08:27 <esmute> Here the logs from last meeting which contains some action items: http://eavesdrop.openstack.org/meetings/cue/2015/cue.2015-04-07-18.02.html
18:08:30 <davideagnello> my action item from previous meeting was:  davideagnello to discuss cue's integration testing approach
18:09:02 <sputnik13> yes, davideagnello please talk about what happened and where we are with your action
18:09:21 <davideagnello> I am currently writing some sample tests with the Rally framework as 'plugins'
18:09:37 <sputnik13> #topic integration testing approach
18:09:40 <davideagnello> since the scenario or integration tests would be located in Cue
18:10:37 <davideagnello> the second action item is to write a sample scenario test in Tempest, after which a decision would be made
18:11:08 <sputnik13> does tempest allow you to have tests located outside the tempest repository as well?  I think you mentioned but it slips my feeble
18:11:10 <sputnik13> memory
18:11:14 <sputnik13> :)
18:11:19 <davideagnello> scenario testing approach would be simulating use-cases, including negative
18:11:44 <esmute> davideagnello: it would be leveraging the cue client for this right?
18:12:03 <davideagnello> esmute: yes
18:12:19 <davideagnello> integration tests would ideally hit the API directly
18:13:15 <davideagnello> sputnik13: they can, it requires some configuration to get them running which is in our action items to get running.
18:13:38 <sputnik13> ok
18:13:49 <esmute> davideagnello: I am about to submit a patch to refactor and separate the unittests from functional. Once Im done this, i'll help you with your investigation with tempest
18:14:03 <davideagnello> with rally, in order to get tests running outside the repo they have to be copied to the appropriate location, namely: ./rally/plugins/
18:14:21 <sputnik13> would that be cue/rally/plugins?
18:14:37 <davideagnello> rally looks in this location for your plugin scenarios, contexts, runners, etc.
18:15:24 <davideagnello> esmute: thank you, what is remaining with tempest is to write some sample tests
18:16:27 <davideagnello> sputnik13: the test code and yaml/json files would live in our repo.  when running the tests, they would have to be moved to ~./rally/... for rally to actually execute them
18:17:19 <sputnik13> symlink would work just as well I assume, like how we have the devstack plugin symlinked from our repo to devstack
18:18:20 <davideagnello> sputnik13: it should, will try running my sample tests like this as well
18:18:37 <sputnik13> so davideagnello you're going to do the rally tests, esmute is going to do the tempest tests, and we'll have more information on which to go with by next week, right?
18:19:00 <davideagnello> sputnik13: yes, targeting by the end of this week
18:19:37 <sputnik13> #action davideagnello to implement simple rally tests and provide findings on suitability for use in writing integration and scenario tests
18:19:56 <sputnik13> #action esmute to implement simple tempest tests and provide findings on suitability for use in writing integration and scenario tests
18:20:07 <sputnik13> did I do that right? :)
18:20:42 <sputnik13> hmm, no feedback from the bot, let's just say that's correct and move on
18:21:07 <sputnik13> #topic end-to-end conductor functional test
18:22:37 <sputnik13> I think everyone knows, but for the sake of posterity...  from looking at the test "coverage" as far as an end-to-end test, it was agreed that we already have a test that provides sufficient coverage from the API to the jobboard
18:23:09 <sputnik13> so, there is already a functional test that directly exercises the API's POST method to initiate a create cluster flow
18:23:39 <sputnik13> which results in a create cluster job being posted to the taskflow jobboard
18:24:26 <sputnik13> what we're missing is a test to ensure when we spin up a conductor that the conductor is started properly and starts pulling jobs off the jobboard
18:24:42 <sputnik13> so the latter is the functional test that I am currently working on
18:25:13 <sputnik13> for a single unified test that does both I believe we need to treat it more like an integration or scenario test, which will be done once we decide on which framework to use
18:25:50 <sputnik13> oh, shoot, I should have asked whether there are any questions before changing topics...  sorry :)
18:26:02 <esmute> sputnik13: would it be possible to use all the necessary fixtures to do an end-2-end test?
18:26:16 <sputnik13> esmute what do you mean?
18:27:46 <sputnik13> you mean use fixtures to do a single complete end to end test?
18:27:46 <davideagnello> esmute: the issue is that an end-to-end test will require a separate process for the worker/conductor to take jobs and run them
18:27:52 <esmute> i was wondering if we could levarage the fixtures (or create more) in order to have tests that will start from the api, post a job to the jobboard and get it consumed
18:28:54 <esmute> could the same process do both? I remember us talking about it  but it is also slipping my feeble :P
18:29:01 <sputnik13> esmute: yes we can do that, but I think these things should be tested separately at least as far as unit/functional tests are concerned...  the thing with test cases is the more they cover the less information you generally have as far as exactly what failed when failures happen
18:29:04 <davideagnello> if we are going to have integration tests that will do that, there won't be much value added
18:29:58 <esmute> so the idea is to have functional tests that does the posting to the jobboard and other tests that test the consumption
18:29:59 <sputnik13> technically speaking, we could do all of our integration and scenario tests with fixtures, it really depends on what we want to accomplish
18:30:25 <sputnik13> esmute: right, since those are in fact two separate "functions" in cue, one is by the API and the other is by the worker
18:30:52 <sputnik13> at least that's what I'm telling the voices in my head to justify my thought process :D
18:31:59 <esmute> ok.. thats fine.. we will need integration tests anyways and it is makes more sense to do them with int-tests then it is fine
18:32:31 <sputnik13> right, as you said we would need to do tests like that in integration/scenario tests anyway
18:32:38 <vipul> wassup folks
18:33:22 <sputnik13> so, rather than do it in both functional and integration, I think it makes sense to have the smaller tests in functional that verify each leg of that particular "flow" and have the integration test verify the whole flow together
18:33:48 <esmute> ok.. sounds good
18:34:11 <sputnik13> vipul welcome fearless leader
18:34:29 <vipul> Wozniak just got off stage.. he like to talk
18:34:37 <sputnik13> how are things at openstack live :)
18:34:43 <sputnik13> the woz
18:35:26 <esmute> lol
18:35:30 <vipul> we're presenting in a couple of hours.. the Cue logo will be prominently displayed
18:35:48 <sputnik13> niiice
18:36:09 <sputnik13> if there are no more questions/issues, this segways nicely in to the next topic :)
18:37:46 <sputnik13> no more questions or issues?
18:37:54 <sputnik13> for this or the previous topic (sorry)?
18:37:54 <esmute> nop.. next topic
18:37:57 <sputnik13> ok
18:38:07 <sputnik13> #topic cue stickers
18:38:42 <vipul> so just to give some quick feedback..
18:38:51 <vipul> from the folks that notice these things..
18:38:51 <sputnik13> ok
18:39:02 <vipul> the shadows are kinda off in the design you sent last
18:39:19 <sputnik13> ah right
18:39:24 <sputnik13> the top of the lower bar should be lighter
18:39:26 <sputnik13> not darker
18:39:28 <sputnik13> :)
18:39:31 <sputnik13> i just realized
18:39:34 <vipul> so if the light source is at to top which is where it seems to be
18:39:37 <vipul> right
18:39:44 <sputnik13> I will let him know
18:39:51 <abitha> do we have a final color selected?
18:40:17 <sputnik13> I don't think so...  vipul mentioned he would like it a darker red, pink is offensive to his sensibilites :)
18:40:22 <vipul> :P
18:40:38 <vipul> a richer red would be nice.. just my opinion..
18:40:39 <abitha> :D
18:40:40 <sputnik13> http://snag.gy/nEquR.jpg
18:40:47 <sputnik13> that is how the logo currently stands
18:40:50 <esmute> vipul: im impressed you saw that level of detail
18:41:04 <vipul> esmute: i didn't.. others did
18:41:37 <sputnik13> vipul: any other feedback?
18:41:38 <esmute> others?
18:41:44 <esmute> from OS live?
18:41:55 <vipul> Yes.. while i was creating slides
18:42:17 <vipul> sputnik13: that's the only feedback.. otherwise people like it
18:42:37 <sputnik13> cool
18:42:42 <sputnik13> I passed on the feedback
18:43:02 <vipul> ok we only have about a month.. so need to get these printed out soon
18:43:23 <sputnik13> and a new version with the tweaks we asked for should be coming our way today or tomorrow
18:43:24 <esmute> sputnik13: who is making these adjusting to the logo?
18:43:40 <esmute> s/adjusting/adjustment
18:44:24 <sputnik13> esmute: a guy I worked with at my previous company is a graphic designer by training (although he does web ui/ux now), we asked him to do the logo
18:45:42 <sputnik13> so once we OK the tweaks, he's going to get a printed proof done to double check the cutouts, and then have the final printed and sent to us
18:45:53 <esmute> ok
18:45:56 <vipul> cool beans
18:46:12 <sputnik13> we talked briefly about t-shirts, do you want to get something done there?
18:46:42 <vipul> I think we just get the logo from him and have Angela take care of those
18:46:53 <sputnik13> ok
18:47:24 <sputnik13> yeah I wasn't thinking of asking him to do the t-shirts, I was more asking are we going to make t-shirts for the team :)
18:47:45 <vipul> oh yea i think we should.. and make esmute wear it
18:47:52 <sputnik13> as you said we have 1 month now, so we should probably get it going soon
18:48:22 <esmute> i would wear a shirt with that logo... just that logo though... no other odd additions
18:48:24 <esmute> :p
18:48:40 <sputnik13> hah, I have some thoughts on what the t-shirt should look like
18:48:54 <sputnik13> I'll get the t-shirt stuff moving
18:49:12 <sputnik13> it would be really good to get more visibility at the conference
18:49:26 <esmute> #action sputnik13 getting the cue t-shirt finalized
18:49:38 <sputnik13> :)
18:49:54 <sputnik13> #action esmute wear t-shirt for entire conference
18:50:08 <esmute> oops.. i forgot to add no weird toons/geeky stuff
18:50:14 <sputnik13> hah, too late
18:50:29 <sputnik13> ok that's it for previous actions
18:50:37 <sputnik13> open discussion
18:50:44 <esmute> ok i got one
18:50:45 <sputnik13> oh wait, any questions/issues?
18:50:49 <sputnik13> with previous topic
18:51:00 <sputnik13> if not, lets go to open discussion
18:51:06 <esmute> PEPE8 import grouping checkers. Do we need them?
18:51:10 <esmute> they are so annoying.
18:51:16 <sputnik13> #topic open discussion
18:51:23 <esmute> PEPE8 import grouping checkers. Do we need them?
18:51:34 <abitha> is it the import grouping?
18:51:45 <esmute> i dont understand that order pep8 wants it
18:51:47 <sputnik13> I don't think we have any pep8 defined ourselves
18:52:04 <esmute> so i keep swiching things around until i get it right
18:52:07 <sputnik13> meaning we get it from the openstack common requirements...  or something like that
18:52:11 <sputnik13> afaik
18:52:25 <sputnik13> so, yes we need to keep it...  vipul any thoughts?
18:52:46 <esmute> we can omit some pep8 validations if we want
18:53:13 <esmute> these are annoying.. or am i the only one that thinks that?
18:53:19 <sputnik13> import grouping isn't that bad
18:53:37 <sputnik13> it's system libs, 3rd party libs, then project libs
18:53:39 <sputnik13> s/libs/modules
18:54:07 <sputnik13> so anything that's standard python module, you put at top in alphabetical order
18:54:18 <esmute> ok
18:54:28 <sputnik13> then anything that's a 3rd party module (likely installed via pip or requirements.txt)
18:54:42 <sputnik13> then any cue modules
18:54:43 <esmute> so 3rd party ares things like oslos and other openstack commons libs
18:54:46 <sputnik13> yeah
18:55:08 <sputnik13> I sometimes get confused whether it's stdlib, 3rd party, project
18:55:13 <sputnik13> or stdlib, project, 3rd party
18:55:21 <esmute> haha
18:55:22 <esmute> ok
18:55:25 <sputnik13> but that's the general grouping
18:55:33 <sputnik13> and they need to be in alphabetical order
18:55:39 <esmute> if its just me, ill learn the grouping order.. its fine
18:55:56 <sputnik13> yeah it's annoying but once you figure out the ordering it's not that bad
18:56:09 <sputnik13> and there's some merit to it
18:56:27 <sputnik13> when you want to see what modules are used, it's easier to find things in a sorted list
18:57:37 <sputnik13> ok, other topics?
18:57:39 <sputnik13> it's lunch time :D
18:58:37 <sputnik13> alright, should we adjourn the meeting?
18:58:38 <esmute> cool.. we took the whole hour as well
18:59:16 <sputnik13> alright, thanks everyone
18:59:20 <sputnik13> #endmeeting