15:00:24 <jpena> #startmeeting RDO meeting (2016-03-02)
15:00:24 <zodbot> Meeting started Wed Mar  2 15:00:24 2016 UTC.  The chair is jpena. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:24 <zodbot> The meeting name has been set to 'rdo_meeting_(2016-03-02)'
15:00:36 <jpena> #topic roll call
15:00:37 <jschlueter> o/
15:00:41 <trown> o/
15:00:43 <leanderthal> o/
15:00:44 <mflobo> o/
15:00:50 <jpena> #chair jschlueter trown leanderthal mflobo
15:00:50 <zodbot> Current chairs: jpena jschlueter leanderthal mflobo trown
15:00:50 <jruzicka> o/
15:00:56 <jpena> #chair jruzicka
15:00:56 <zodbot> Current chairs: jpena jruzicka jschlueter leanderthal mflobo trown
15:01:06 <sai> trown: awesome, i can work on the baremetal stuff
15:01:09 <leanderthal> how do you know whom to chair?  everyone who raises their hands?
15:01:20 <jpena> leanderthal: mostly :)
15:01:30 <elmiko> o/
15:01:33 <chandankumar> \o/
15:01:37 <leanderthal> jpena, fair
15:01:42 <rbowen> Why can't I send to the channel?
15:01:44 <rbowen> Oh, there we go.
15:01:50 <jpena> #chair elmiko chandankumar rbowen
15:01:50 <zodbot> Current chairs: chandankumar elmiko jpena jruzicka jschlueter leanderthal mflobo rbowen trown
15:01:52 <rbowen> /o/
15:02:20 <apevec> o/
15:02:24 <EmilienM> o/
15:02:30 <jpena> #chair apevec EmilienM
15:02:30 <zodbot> Current chairs: EmilienM apevec chandankumar elmiko jpena jruzicka jschlueter leanderthal mflobo rbowen trown
15:03:12 <jpena> ok, let's start with the agenda
15:03:14 <jpena> #topic take2, Delorean -> Fluzo: fluzo.com is taken, so (TM) issues possible :(
15:03:19 <apevec> ah yes
15:03:37 <apevec> so looks like there's company w/ that name
15:03:43 <trown> naming is hard
15:03:44 <apevec> so we better avoid it
15:03:46 <apevec> it is!
15:03:59 <apevec> there are few new suggestions on ethpad
15:04:10 <apevec> mine: ozulf (fluzo backwards)
15:04:17 <apevec> which I think it's lame :)
15:04:25 <apevec> then paramite's vodou suggestion: https://en.wikipedia.org/wiki/Damballa
15:04:29 <elmiko> lol
15:04:51 <apevec> I'm not sure what's the connection to back to the future theme
15:04:58 <apevec> also, no religion please
15:05:03 <elmiko> why not call it hover-board?
15:05:15 <apevec> and finally, paramite's elements suggestion: https://en.wikipedia.org/wiki/Zeolite
15:05:16 <trown> damballa is problematic https://en.wikipedia.org/wiki/Damballa_%28company%29
15:05:18 <apevec> which is kind of nice
15:05:29 <apevec> trown, thanks, so it's out
15:06:20 <jpena> I'd propose to have an etherpad where we propose names, then we can do our due diligence to find out if there are tm issues for a week and decide in the next meeting
15:06:21 <imcsk8> o/
15:06:28 <trown> there is also http://www.zeolite.com/
15:06:36 <trown> and it is used in cat liter
15:06:46 <apevec> lol
15:06:48 <elmiko> ouch
15:06:50 <leanderthal> bwahahahaha
15:06:58 <leanderthal> does that make it more relevant or less?
15:06:59 <elmiko> jpena: +1
15:07:02 <leanderthal> /hides
15:07:05 <trown> hehe
15:07:11 <elmiko> nice lol
15:07:16 <trown> +1 to jpena suggestion
15:07:29 <leanderthal> +2 to jpena suggestion
15:07:30 <trown> maybe send out something to ML with etherpad link to get more participation?
15:07:32 * apevec apevec to open an etherpad for future Delorean name
15:07:42 <apevec> #undo
15:07:42 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x351080d0>
15:07:52 <jruzicka> let's leave it in the RDO meeting one, no?
15:07:56 * apevec apevec to open an etherpad for future Delorean name and advertise on rdo-list
15:08:03 <jruzicka> oh, ok
15:08:07 <elmiko> trown: +1, getting wider audience would be excellent
15:08:22 <apevec> jruzicka, no, I just started cleaning RDO-Meeting  :)
15:08:22 <rdobot> I think apevec meant TripleO! ( https://www.rdoproject.org/blog/2016/02/rdo-manager-is-now-tripleo/ )
15:08:27 <red_trela> 2016-03-02 14:59:09 [NovaCompute]: CREATE_FAILED ResourceInError: resources.NovaCompute: Went to status ERROR due to "Message: Exceeded maximum number of retries. Exceeded max scheduling attempts 3 for instance 93069fc8-87d0-423d-b918-897cfb56f6f2. Last exception: Failed to provision instance 93069fc8-8
15:08:28 <red_trela> ideas?
15:08:36 <trown> red_trela: after meeting
15:08:53 <apevec> so we need topic to re-program regex in rdobot  :)
15:08:58 <trown> lol
15:09:03 <jpena> :D
15:09:05 <trown> dmsimard|afk: is afk
15:09:09 <apevec> ok, next topic
15:09:16 <jpena> #topic undercloud.qcow2 mirroring for testdays
15:09:36 <apevec> trown, ^ came up today when red_trela was failing to d/l
15:09:43 <apevec> but do we actually need it now?
15:09:44 <trown> apevec: did you put this up for ... ah yep
15:09:51 <jpena> how big is that file?
15:09:53 <trown> apevec: it should not be needed
15:10:02 <apevec> ok, done :)
15:10:07 <trown> there is built in retry w/ resume now, and caching
15:10:21 <apevec> trown, it's just if someone tries manual curl which will fail
15:10:42 <trown> #action trown fix RDO tripleo docs to not mention manual curl
15:11:15 <jpena> trown: if the file is not huge, we might even host it in the delorean/fluzo/whatever host
15:11:19 <red_trela> it doesn't, I think - I just preferred it :)
15:11:36 <trown> red_trela: ah ok, I should still fix it up :)
15:11:56 <apevec> jpena, it is huge
15:12:00 <apevec> few GBs
15:12:02 <trown> jpena: it is 2.5G, and mirroring would be good, it is just not a blocker for anything
15:12:14 <jpena> 2.5 GB is not that much
15:12:16 <apevec> mirroring in proper CDN that is
15:12:32 <apevec> jpena, still, it would be a load on hosting link
15:12:42 <red_trela> yea, downloading it from Japan is super slow :)
15:13:15 <trown> next topic?
15:13:26 <jpena> yep
15:13:30 <jpena> #topic Failure to build from source workflow
15:13:57 <jpena> So the question here is what to do when we have a FTBFS (failed to build from source)
15:13:58 <trown> I put this one up, since it has come up a couple times this week
15:14:36 <apevec> proposal is: quickfix + open new empty TODO review for followup
15:14:47 <apevec> could be scripted?
15:15:24 <jpena> asking the other way around: what is the harm if a ftbfs takes a couple days to fix?
15:15:27 <trown> maybe, though the empty TODO review should not be much effort
15:15:59 <trown> jpena: it means delorean consistent repo can not move forward, and often we are waiting for some fix to land to potentially promote delorean
15:16:25 <jpena> and we can only promote consistent, right?
15:16:28 <trown> and recent history has shown that delorean does not stay "promotable" for very long
15:16:30 <trown> ya
15:17:14 <trown> so 2 days is a really long time... ideally we fix FTBFS within hours
15:18:21 <jpena> In those cases, I'd be ok with quickfixing and opening a follow-up review to complete the build. In those cases, the added file is not usually required in the short term, and if it is we need to fix packaging anyway
15:18:24 <chandankumar> if no. of FTBFS reviews are less, we can fix quicklly.
15:19:24 <trown> ya both of the cases this week were FTBFS for an added binary, that could not even be used without new configuration
15:19:25 <apevec> jpena, usual case is just what we had: new service binary is added
15:19:54 <apevec> but support in puppet is missing so can't be used anyways
15:20:01 <trown> so fixing by just adding the binary, with follow-up TODO review to properly add the service seems like a good compromise
15:20:02 <apevec> yeah, what trown said
15:20:13 <jpena> yes, lgtm
15:20:19 <jpena> is anyone against this proposal?
15:20:30 <chandankumar> i am ok with it.
15:20:44 <apevec> I'll describe that in packaging docs update which I'm supposed to be working on
15:20:50 <trown> :)
15:20:50 <jpena> ack
15:20:55 <chandankumar> is there a way better way to add it to my watchlist?
15:21:11 <apevec> #action apevec describe FTBFS flow in packaging docs update
15:21:14 <trown> chandankumar: the TODO review?
15:21:19 <chandankumar> yes
15:21:30 <apevec> chandankumar, it would get the same topic:rdo-FTBFS
15:21:40 <trown> I think the TODO review should include adding maintiners in rdoinfo to the review
15:21:58 <apevec> trown, ack
15:22:16 <chandankumar> ok
15:22:39 <apevec> and title in big letters: TODO complete "$previous-review-subject"
15:22:59 <trown> ya, as big of letters as a commit message allows :)
15:23:55 <jpena> ok, next topic?
15:24:00 <apevec> next
15:24:11 <jpena> #topic python-%{service}-tests packages (that include tempest tests for each OpenStack project)
15:24:14 <EmilienM> o/
15:24:36 <apevec> IIRC we had that topic months ago but it was not priority
15:24:39 <apevec> now it is
15:24:41 <EmilienM> the soon the better so upstream CI can run tempest plugins and then RDO CI too
15:25:06 <apevec> we actually have -tests subpackage in example openstack .spec
15:25:09 <EmilienM> it's some work to invest but worth it regarding the testing coverage we can have
15:25:31 <apevec> it takes 3 chunks in .spec:
15:25:31 <apevec> https://github.com/javierpena/openstack-example-spec/blob/master/openstack-example.spec#L48-L56
15:25:31 <apevec> https://github.com/javierpena/openstack-example-spec/blob/master/openstack-example.spec#L139-L141
15:25:31 <apevec> https://github.com/javierpena/openstack-example-spec/blob/master/openstack-example.spec#L148
15:25:35 <jpena> do we have a list of the packages without -tests subpkg?
15:25:47 <apevec> I did example for Keystone: https://review.gerrithub.io/264900 Add Keystone tests subpackage
15:25:59 <apevec> jpena, list with -tests would be shorter I guess
15:26:17 <apevec> Neutron had it
15:26:34 <apevec> that's where it came to example spec from :)
15:26:43 <chandankumar> apevec, what about enabling %check section for test subpackages in openstack -* packages?
15:26:50 <apevec> chandankumar, hold on :)
15:26:53 <apevec> step by step
15:27:03 <apevec> -tests is a priority now
15:27:14 <apevec> %check can come next
15:27:29 <jpena> so first we need those for OpenStack services, right?
15:27:33 <apevec> yes
15:27:50 <jpena> ok, let's then check them all and create a trello card to track them
15:27:56 <EmilienM> +1
15:27:58 <apevec> ack, who can take that action
15:28:05 <EmilienM> I can help
15:28:07 <chandankumar> i can helo
15:28:10 <chandankumar> *help
15:28:20 <EmilienM> chandankumar: go ahead man
15:28:20 <jpena> I can create the trello card
15:28:22 <apevec> first step is to grep all specs
15:29:37 <chandankumar> ok
15:30:25 <apevec> action for the record?
15:31:20 <jpena> #action chandankumar will create a trello card with packages requiring -tests subpkg
15:31:21 <chandankumar> I will list down which of the openstack-* have missing test subpackages.
15:31:40 <trown> awesome
15:31:41 <chandankumar> ack
15:31:47 <trown> I will take a couple from the trello card
15:31:53 <EmilienM> chandankumar: ping me if you need help please
15:31:59 <chandankumar> sure EmilienM
15:32:01 <chandankumar> :-)
15:32:33 <jpena> so... if we're done with this topic, we can go to the last one
15:33:01 <trown> I thought we had chairs lined up again
15:33:05 <jpena> #topic open floor
15:33:29 <chandankumar> leanderthal, is chair for next meeting i think?
15:33:47 <chandankumar> 8chairing
15:33:51 <chandankumar> *chairing
15:34:12 <leanderthal> i am
15:34:17 <leanderthal> :-)
15:34:19 <trown> sweet
15:34:20 <leanderthal> go me!
15:34:38 <chandankumar> #action leanderthal to chair for next meeting.
15:34:51 <leanderthal> *flex*
15:35:02 <ibravo> question, is the script to build bare metal going to the docs, or how do w communicate to the rest of the users?
15:35:10 <tosky> sorry, late question about -tests subpackages: it's not so easy, as the entry points for Tempest plugin should be split as well
15:35:16 <tosky> do you know how it can be done with setuptools?
15:36:02 <apevec> tosky, tell me more
15:36:06 <tosky> if you just applies the changes that apevec pointed out, the entry point will end up into the common/main package and tempest discovery could fail anyway
15:36:31 <tosky> apevec: packages which export tempest-style tests using the Tempest Plugin interface require a special entry point
15:36:35 <tosky> you can see an example here:
15:36:39 <tosky> (moment)
15:36:40 <apevec> tosky, link me some examples
15:37:07 <apevec> tosky, -tests subpkg depends on openstack-$service
15:37:18 <apevec> so I think we shold have those entry points, no?
15:37:18 <tosky> apevec: http://git.openstack.org/cgit/openstack/sahara/tree/setup.cfg#n65
15:37:26 <apevec> in the system
15:37:32 <tosky> yes, but see this scenario:
15:37:49 <tosky> you install only the main package (see sahara and manila)
15:38:00 <ayoung> apevec, you know who's name should be on that review?
15:38:00 <apevec> right, and that fails
15:38:09 <tosky> run tempest discovery, boom, because the entry point is defined but  the code is not there unless you install the -tests package
15:38:11 <apevec> ayoung, which review?
15:38:17 <ayoung> https://review.gerrithub.io/#/c/264900/
15:38:26 <ayoung> apevec, anything with Keystone....please keep me in mind
15:38:39 <apevec> tosky, right, I don't see a problem with that scenario, install -tests if you want tests
15:38:41 <tosky> so unless you make openstack-tempest depend on all possible -tests packages which export tempest tests, it's not exactly going to work
15:39:16 <apevec> tosky, why would that be needed?
15:39:18 <tosky> apevec: yes, but you need to install each and every declared -tests package even if you want to run a subset
15:39:27 <apevec> install openstack-tempest + -tests for stuff you want to test
15:39:31 <tosky> no
15:39:34 <apevec> tosky, wha?
15:39:35 <trown> oh I see
15:39:43 <tosky> tempest tries to find all the entry points when it runs discovery
15:39:44 <apevec> that's silly
15:39:53 <tosky> but it's what it is now
15:40:00 <tosky> complaining upstream, we need a solution :)
15:40:01 <apevec> tosky, it could do try: import ...
15:40:03 <trown> apevec: the entrypoints will be there for the service, if you dont install the tests package tempest will barf
15:40:06 <apevec> damn upstream :)
15:40:12 <trown> pinche tempest
15:40:18 <apevec> trown, yeah, I see but still ...
15:40:25 <tosky> it's not an import, it's an entry point in setup.cfg in tempest
15:40:29 <apevec> we can't split egginfo
15:40:30 <jpena> tosky: if it doesn't find the entry point, does it just ignore it or fail? Because today we have packages that just remove tests (e.g. keystone)
15:40:34 <ayoung> We are trying to get the Functional test out of Tempest upstream
15:40:43 <tosky> jpena: it fails
15:40:55 <trown> jpena: keystone hasnt moved to a tempest plugin yet
15:40:56 <imcsk8> trown pinche? :P
15:41:01 <jpena> ahh ok
15:41:06 <tosky> I have to say I didn't test with Mitaka, but it fails in Liberty
15:41:13 <tosky> so please be aware that it could be an issue
15:41:29 <ayoung> trown, we are moving to Functional tests.  I'd actually think the client is the right place for them.  It worked for the recent implied roles change
15:41:34 <trown> imcsk8: I grew up in Mexic^wTexas, so its allowed :)
15:41:36 <apevec> tosky, so I think we can patch that in openstack-tempest RPM as a workaround
15:41:43 <ayoung> so...yell at me, and I will yell at the rest of Keystone core
15:41:44 <imcsk8> trown cool hehe
15:41:48 <apevec> and talk/propose fix upstream
15:42:01 <tosky> another question: how many tests are we going to package? Scenario/tempest, or also lower level integration and unit?
15:42:30 <apevec> everything under tests/
15:42:44 <apevec> ayoung, client? really?
15:42:55 <ayoung> apevec, yeah.  It makes sense when you think about it
15:43:05 <ayoung> we don't really have "functionality" until you can call it from client
15:43:20 <ayoung> and the client really should be tested against a live keystone server, not one running sqlite
15:43:48 <ayoung> I was able to do my development against a Kolla setup stripped down to just Keystone and MySQL
15:43:59 <dmellado> tosky: trying to get some context, let me read
15:44:02 <dmellado> xD
15:44:08 <apevec> what about adding new feature, shouldn't you have tests for that in the same repo?
15:44:09 <tosky> apevec: so remember also sahara-tests, which is a new repo where all the high level sahara tests have been moved
15:44:09 <ayoung> apevec, see https://review.openstack.org/#/c/280983/
15:44:17 <ayoung> apevec, unit tests, yes
15:44:28 <ayoung> and most of our unit tests run through the REST API
15:44:41 <tosky> dmellado: we need the help of some tempest contributor to fix the discoverability of tempest plugin so that they don't fail if the entry point is defined but the code is not there
15:44:42 <ayoung> but unit tests don't get run against a MySQL backend..too slow
15:45:10 <apevec> tosky, oh, so separate repo, is that sahara only?
15:45:21 <tosky> apevec: afaik yes
15:45:24 <apevec> this will be new package
15:45:33 <ayoung> apevec, and writing any large scale functional test really either needs the client, or you end up reimplementing the client
15:45:43 <apevec> SRPM but same namespace python-sahara-tests
15:45:51 <ayoung> so...client is the right place.  It just doesnt get us a CLI now.  That is an additional step
15:45:52 <tosky> ayoung: well, you can use the tempest clients
15:46:07 <ayoung> tosky, as I said, you need to reimplement
15:46:17 <ayoung> this is new functionality:  the API calls to do implied roles
15:46:23 <apevec> tempest reimplements all clients?
15:46:27 <dmellado> tosky: I'll try to bring the topic u/s or downstream worst case, but I need to check first where that filure would be producing
15:46:27 <tosky> yes
15:46:35 <tosky> apevec: yes
15:46:36 <dmellado> apevec: tempest uses its own service clients, yes
15:46:38 <apevec> are they rounder?
15:46:50 <ayoung> apevec, and now you understand why we want to take over our own functional testing\
15:47:02 <dmellado> apevec: https://github.com/redhat-openstack/tempest/tree/master/tempest/services
15:47:13 <ayoung> tempest only brushes on the top of Keystone behavior
15:47:34 <ayoung> https://github.com/redhat-openstack/tempest/tree/master/tempest/services/identity/v3  is it for identity
15:47:54 <trown> should we endmeeting?
15:47:56 <dmellado> ayoung: expect that to change, soon
15:48:03 <apevec> ok, so anyway -tests subpackaging is the first step
15:48:09 <apevec> and we'll obviously need to iterate
15:48:21 <ayoung> dmellado, and, as should be obvious, it means our clients are untested
15:48:21 <apevec> yes, let's end the meeting
15:48:27 * trown goes for coffee...
15:48:32 <trown> thanks jpena for chairing
15:48:41 <jpena> ok, let's end!
15:48:42 <dmellado> ayoung: I've read a discussion about something like this in the ML today
15:48:43 <apevec> we'll add details in -tests trello card
15:48:43 <jpena> #endmeeting