12:03:17 <phracek> #startmeeting Env and Stacks (2015-05-07)
12:03:17 <zodbot> Meeting started Thu May  7 12:03:17 2015 UTC.  The chair is phracek. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:03:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
12:03:49 <phracek> #meetingname env-and-stacks
12:03:49 <zodbot> The meeting name has been set to 'env-and-stacks'
12:04:02 <phracek> #chair bkabrda hhorak juhp ncoghlan vpavlin sicampbell walters ttomecek phracek
12:04:02 <zodbot> Current chairs: bkabrda hhorak juhp ncoghlan phracek sicampbell ttomecek vpavlin walters
12:04:14 <phracek> hhorak: Hi
12:05:35 <phracek> #topic Follow-ups, if any progress has been made
12:06:21 * langdon lurks
12:06:46 <phracek> First of all I would like to introduce, that jstribny, asamalik and me (phracek) are going to start on
12:06:55 <phracek> developer.fedoraproject.org page
12:07:06 <phracek> Some preview screenshots are available here:
12:07:20 <phracek> #link http://download.eng.brq.redhat.com/scratch/phracek/landing_page.png
12:07:39 * juhp_ just wants to apologize for long absence from the meetings...
12:07:42 <phracek> #link http://download.eng.brq.redhat.com/scratch/phracek/project_page.png
12:07:52 <phracek> juhp_: Hi
12:07:59 * ncoghlan likewise apologises for the extended absence
12:08:17 * bkabrda too
12:08:17 <juhp_> phracek, perhaps you could upload it somewhere public? :)
12:08:25 * vpavlin sneaks in..
12:08:33 <juhp_> okay - you guys making me feel better ;) :)
12:08:55 <ncoghlan> phracek: I was about to ask the same question (I'm not on the VPN at the moment)
12:09:08 <phracek> mmnt, I will past to fedoraproject.org
12:09:40 <ttomecek> phracek, neat!
12:10:00 <ncoghlan> I'm not sure it counts as a follow-up, but I had some good conversations with Randy Barlow on the Pulp team at PyCon
12:10:29 <phracek> #link https://phracek.fedorapeople.org/landing_page.png
12:10:43 <phracek> #link https://phracek.fedorapeople.org/project_page.png
12:10:52 <phracek> the links should be available publicly
12:11:18 <ncoghlan> phracek: I'll echo ttomecek: neat! :)
12:11:32 <ncoghlan> those are very cool
12:11:40 <phracek> Of course pictures are not real pages but the main page can look like as screenshots.
12:12:08 <phracek> We plan to discuss some issues with langdon and workstation team how it can be improved
12:12:35 * langdon hides
12:12:40 <juhp_> phracek, thanks
12:13:01 <ttomecek> ncoghlan, Nick, can you summarize the conversation a bit?
12:13:18 <langdon> phracek, definitely should include mizmo too.. not sure if you did already ( i can't remember) and her "hubs" plan
12:13:42 <ncoghlan> langdon: maybe worth mentioning to the CentOS folks as well
12:13:43 <phracek> The page should mainly help new fedora users and current Fedora users how to use project like docker, vagrant etc.
12:14:11 <langdon> ncoghlan, a unified "developer on the OS page" might be interesting
12:14:15 <ncoghlan> langdon: a CentOS page like that would be a good way to point folks towards Software Collections
12:14:26 <ncoghlan> langdon: indeed
12:15:24 <phracek> #info ncoghlan summarize the conversation with Randy Barlow on the Pulp team at PyCon
12:15:36 <ncoghlan> regarding the Pulp discussions, Randy's the author of the pulp-python plugin, and was very interested in the language specific repos idea
12:15:40 <langdon> ncoghlan, i had proposed a similar idea for "container-y stuff" (here i think) a while back..
12:16:08 <ncoghlan> (that's actually why he was at PyCon - presenting that at the poster session)
12:16:56 <ncoghlan> pulp-python doesn't allow uploading wheel files yet, but that had already moved to the top of his list based on poster session feedback
12:18:16 <ncoghlan> so if/when we switch the language specific repos idea to be based on Pulp, the Pulp team are likely to be responsive to our questions
12:18:40 <bkabrda> there's one more issue with pulp - it doesn't support lazy fetching. so if you choose to mirror PyPI, it goes and downloads the whole PyPI content, which is not what we want.
12:18:45 * walters is here now
12:18:59 <bkabrda> I talked to Randy about this and he said that lazy fetching is also on their priority list
12:19:41 <ncoghlan> bkabrda: am I right in thinking they wanted that as a general feature, not just for Python?
12:19:51 <bkabrda> ncoghlan: correct
12:20:09 * hhorak finally ready, reading the above..
12:20:19 * hhorak finally ready, reading the above...
12:20:21 <bkabrda> ncoghlan: randy actually said that it will require some deeper changes in pulp itself, but they want/need to do those anyway
12:22:05 <phracek> ncoghlan: thanks for summary. Can we go to the next topic?
12:22:32 <ncoghlan> yep, I'll do a really short info summary as well
12:23:01 <phracek> ncoghlan: Would you be able to send summary to ML?
12:23:20 <ncoghlan> phracek: sure, that's a better idea
12:23:28 <phracek> #topic Docker images building within Fedora
12:23:46 <ncoghlan> #action ncoghlan send Pulp update to ML
12:25:07 <phracek> In my action item I have TODO to check if all Docker images are ready for F22.
12:25:27 <phracek> #link https://github.com/fedora-cloud/Fedora-Dockerfiles
12:25:45 * phracek did not have a time yet:(
12:26:04 <hhorak> by this docker piece in the agenda I wanted basically to summarize what is the current status of fedora-dockerfiles/images/build-system...
12:26:19 <phracek> hhorak: your turn:)
12:27:08 <hhorak> phracek: you actually started with the exact thing I had on mind... have you talked to scot, the Fedora-Dockerfiles guy by any chance or not yet?
12:27:37 <phracek> hhorak: sorry not yet:( I have to do that next week.
12:27:44 <hhorak> phracek: no problem..
12:27:49 * phracek is appologize
12:28:32 <ttomecek> re build-system, we are working together with Fedora folks on that; unfortunately it looks like it will take some (a lot) time
12:29:09 <ttomecek> the issue is koji and openshift v3: our current solution uses custom koji plugin
12:29:28 <ncoghlan> ttomecek: is this for base images, or layered ones?
12:29:30 <ttomecek> looks like that fedora folks are not happy with koji and they would like to rewrite it or something like that
12:29:41 <hhorak> ttomecek: do you know something about the workflow in fedora? the docker image would be built in the fedora instance of the build service, tested and then ... pushed to docker hub?
12:30:00 <ttomecek> re openshift v3: it bundles several dozens of packages meaning unpackagable for Fedora
12:30:45 <dgilmore> ttomecek: working on what?
12:30:49 <ttomecek> ncoghlan, layered; base image can already be built in koji using img factoru
12:30:50 <phracek> #info ttomecek works on build-system for dockerfiles with Fedora folks
12:30:51 <dgilmore> ttomecek: and with who?
12:30:55 <ttomecek> factory*
12:31:17 <ttomecek> dgilmore, Paul Frields and Adam Miller were on the call
12:31:26 <dgilmore> ttomecek: no one is working with Fedora releng on tooling for docker layered images
12:31:27 <ncoghlan> ttomecek: OK, cool - that's where I was puzzled :)
12:31:42 <dgilmore> ttomecek: okay
12:32:03 <dgilmore> ttomecek: they were just seeing what is being done
12:32:22 <dgilmore> ttomecek: you can not really call that working on getting it in Fedora
12:32:32 <dgilmore> there is a lot of work that needs to be done for that
12:32:43 <ttomecek> hhorak, too early to talk about workflow: CentOS is actually way far ahead; they would like to have something functional by the end of this month
12:33:01 <ncoghlan> dgilmore: thanks for clarifying, that aligns with my understanding as well
12:33:17 <dgilmore> ncoghlan: we want to do it
12:33:28 <dgilmore> but it is super super early
12:33:36 <ncoghlan> dgilmore: right
12:33:56 <ttomecek> dgilmore, I agree: right now it's mainly really about investigation
12:34:10 <ncoghlan> dgilmore: jgreguske and gsterling gave me the rundown on their setup just after PyCon
12:34:11 <hhorak> #info btw. adam sent an invitation for whenisgood instance to find a good time to meet and discuss Project Planning workflow.. just don't oversee it :)
12:34:14 <dgilmore> it will be a Fedora 23 thing
12:34:20 <ttomecek> should have picked more appropriate words, sorry
12:34:50 <dgilmore> ttomecek: :) it happens, its good to get clarification many times
12:35:31 <ncoghlan> given how fast various folks are moving at the moment, I'm not surprised we sometimes get confused :)
12:38:33 <phracek> Gyus, thanks for information. The next topic is
12:38:38 <phracek> #topic Containers-Testing-Framework
12:38:39 <dgilmore> ncoghlan: indeed, I am in the middle of it all and often get confused
12:39:47 <phracek> During our RedHack week thozza and his team does a huge work on behave which could be used as a testing framework for container.
12:40:19 <phracek> #link http://pythonhosted.org/behave/
12:40:46 <langdon> phracek, did those changes get accepted upstream?
12:41:14 <phracek> langdon: AFAIK it was a proof of concept if the library can be used.
12:41:56 <phracek> Next step is to show upstream that it can be used as a testing framework.
12:42:10 <phracek> hhorak: Do you have a couple of words for that?
12:42:12 <langdon> phracek, ohh.. i need to review what they did (didn't follow the presentation well).. i was hoping they were gonna integrate the "remoting" aweiteka did
12:42:30 <ncoghlan> phracek: upstream as in Project Atomic? Or Container Tools?
12:43:31 <phracek> If I understand properly then Container Tools. Like for Fedora_dockerfiles.
12:44:06 <langdon> phracek, well.. i am pretty sure c-t is all in on behave.. once we get some things working
12:44:10 <hhorak> langdon: I don't understand what should be accepted upstream?
12:44:58 <hhorak> phracek: I wanted basically to share the link to let people know ...
12:44:58 <hhorak> #link https://github.com/Containers-Testing-Framework
12:45:19 <hhorak> it would be great if we started to use it somehow in fedora for the dockerfiles
12:45:26 <phracek> hhorak: ok, thanks. I am pretty fast.
12:45:41 <langdon> hhorak, for RHW, I had suggested that the behave team should refactor the code here https://github.com/aweiteka/UATFramework which allows behave to be used from one machine to another .. to make it generic and usable in bheave directly.. they way UAT_Framework is built, is kinda weird
12:45:53 <hhorak> phracek: it's more like I'm pretty slow :)
12:46:34 * langdon still has plans to rewrite fedora-features in behave and see if that works.. but.. "time"
12:46:34 <ncoghlan> langdon: cool. If we encounter any problems collaborating with behave upstream, let me know, since I know Benno via linux.conf.au and PyCon Australia
12:46:57 <ncoghlan> langdon: but hopefully we won't need to rely on that :)
12:46:57 <hhorak> langdon: what I understood was that they used some pieces for UATF to their project, but I don't think they wanted to push the changes back :0
12:47:02 <langdon> ncoghlan, i think the work is only a couple days.. but.. not a couple days i have :)
12:47:19 <phracek> ncoghlan: Do we plan to use behave generally for let's say all applications?
12:47:34 <hhorak> phracek: that would be nice :)
12:47:44 <ncoghlan> phracek: where I consider it most interesting is in the context of independent QA testing
12:47:46 <hhorak> but i don't think anybody is working on it
12:48:00 <phracek> including all current projects like vim, emacs, devassistant etc.?
12:48:16 <phracek> or better say all current packages.
12:48:23 <ncoghlan> and the kinds of stuff we might want to do as application independent checks of a container
12:48:24 <ttomecek> please no
12:48:29 <walters> i think there's a more fundamental issue here in that we don't have an environment set up to run these tests
12:48:45 <phracek> ttomecek: I hope so that not:)
12:48:56 <langdon> walters, i was hopeing to use the centos-ci
12:49:04 <walters> for fedora?
12:49:13 <langdon> walters, yeah.. why not :)
12:49:17 <walters> ok
12:49:17 <ncoghlan> phracek, ttomecek: don't think unit tests, think acceptance tests IMO
12:49:41 <phracek> ok. Thanks for confirmation.:)
12:49:48 <walters> i guess if we do that, we could use centos' instance of the container build service as well
12:50:06 <langdon> on behave: i guess i was thinking that behave would be used for the high-level stuff (like a feature or a dockerfile) which would then call the "existing project tests" as part of its tests ... "all of the tests in emacs pass" might be the behave bdd
12:50:27 <ncoghlan> langdon: +1
12:51:10 <langdon> walters, i am not sure why we couldn't.. i think the cent folks are hoping lots of projects will use their ci ... but.... worth discussing...
12:51:27 <hhorak> langdon: yes, the unit tests are run during build (usually) so these are fine.. the behave for the high level makes great sense to me as well
12:51:35 <ncoghlan> my interest in the container testing framework (and this is speculative at this point) is to help automate pre-release testing for internal services
12:51:52 * phracek nods
12:52:19 <langdon> ncoghlan, uhh.. that sounded like you were quoting a rational sales guy.. could you elaborate? :)
12:52:52 <ncoghlan> langdon: internal QE test we're not going to break the world before pushing out new updates to internal services
12:53:02 <ncoghlan> a lot of that testing is more manual than we'd like right now
12:53:37 <ttomecek> ncoghlan, that could work; but I'm still a person who likes to code tests precisely, basically without any frameworks/helpers (my .02$)
12:53:44 <ncoghlan> and a BDD framework like behave seems like a potentially good candidate
12:54:00 <ncoghlan> ttomecek: those are likely to be unit tests, not acceptance tests
12:54:04 <langdon> ncoghlan, ahh yes.. i think if we could setup a nice "model" with templates and all that jazz for "os integration testing" (where os = traditional or docker or whatever) .. people could just drop in to it...
12:54:10 <ttomecek> ncoghlan, understood
12:54:50 <ncoghlan> langdon: http://serverspec.org/ is an RSpec based example of that
12:54:54 <langdon> ttomecek, and.. you should try behave.. the "tests" can/are very specific.. you just wrap them in to "blocks" of test using the behave language
12:55:20 <hhorak> ttomecek: you can still write you test in any language/style/framework and only use exec() in the behave framework + document the feature using the bahavioural style -- that's the magic of this framework, that it is self-documenting as well
12:55:45 <ncoghlan> langdon: my experience is that most developers scratch their heads in confusion at BDD, while QA and business analysts go "That's cool!"
12:55:48 * bkabrda has to run
12:55:59 <bkabrda> see you next week guys, I've got another meeting in 5
12:56:25 <phracek> bkabrda: bye:)
12:56:35 <langdon> ncoghlan, ha.. well.. isn't that the point? they are supposed ot be writing that part anyway
12:57:08 <ncoghlan> langdon: yes, but most descriptions of BDD I've seen don't do a very good job of explaining the intended audience :)
12:58:00 <hhorak> speaking about the tests in fedora -- maybe we shouldn't enforce people to use a specific framework, just allow to store the tests somewhere (dist-git?), run them in safe environment (taskotron/jenkins) and show the results in ... (bodhi?)
12:58:32 <juhp_> hmm yeah
12:58:35 <langdon> hhorak, sure.. but if all the examples are written in behave.. guess what most people will write them in :)
12:58:35 <ncoghlan> hhorak: you generally still need a meta-framework of some kind
12:58:45 <walters> i thought about this for a long time
12:58:49 <walters> you know it's 2015
12:59:01 <ncoghlan> e.g. Beaker has beakerlib et al
12:59:01 <walters> we have lots and lots and lots of people who are very experienced with build systems and such
12:59:06 <hhorak> walters: me too, but never got to some real PoC :)
12:59:10 <walters> how is it that in 2015 the fedora testing sucks so much?
12:59:23 <hhorak> walters: exactly
12:59:31 <walters> the answer i eventually concluded is that because we can't undo, tests can only be "advisory"
12:59:39 <walters> like file bugs or such
12:59:48 <walters> and that's very weak
13:00:00 <walters> people would pay a *lot* more attention to a test system if we reverted builds based on it
13:00:08 <walters> anyways that was just my thought
13:00:11 <juhp_> true
13:00:38 <walters> real world example, if we had the ability to revert, i would back down python-blivet for https://bugzilla.redhat.com/show_bug.cgi?id=1217578
13:00:43 <langdon> walters, +1 .. and a blue dunce cap is mailed to your house
13:00:45 <hhorak> walters: might be, but still we need to first have the tests and run them :)
13:01:00 <ncoghlan> walters: FWIW, there's a certain downstream that was very conflicted about the idea of improving Fedora QA until a little over a year ago
13:01:08 <hhorak> walters: of you meant to revert builds even on bugs?
13:01:18 <ncoghlan> walters: their attitude has improved in recent times ;)
13:02:25 <ncoghlan> but yes, getting Fedora to the point where builds are gated far more strongly is highly desirable
13:03:15 <walters> gating is a waterfall model
13:03:18 <langdon> hhorak, i actually think *many* of the projects have tests.. some are even good.. but we don't have great ways to run/report/use them.. because of the multitude of frameworks.. thats why i was thinking "behave for fedora" then we write plugins to run all the frameworks.. (if they don't already exist)
13:03:19 <walters> which is what we have now
13:03:29 <walters> try-and-revert is totally different
13:03:41 <langdon> walters, the openstack ci is fairly brilliant in that regard
13:03:52 * langdon notes ci.openstack.org
13:04:01 <walters> yeah that's CI though, not CD
13:04:04 <ncoghlan> yes, that's the kind of gating I was referring to
13:04:31 <hhorak> langdon: we also have tests internally that may be opened (sometimes), it has happened already; it's not behave, but would be great to execute within fedora
13:04:38 <ncoghlan> walters: a number of the cloud provides run trunk
13:05:16 <ncoghlan> langdon: taskotron (through TAP), and beaker.fedoraproject.org (through beah/restraint) already offer meta-frameworks
13:05:48 <ncoghlan> langdon: behave is mainly interesting for writing *new* tests in a behavioural style
13:07:10 <ncoghlan> still, solving this isn't primarily Env&Stacks problem - it's qa-devel's :)
13:07:15 <hhorak> ncoghlan: problem of those projects is they are not usable right now.. are they? this should be something more manpower may help?
13:07:37 <ncoghlan> taskotron is up & running I believe
13:07:53 <hhorak> ncoghlan: but it doesn't allow to execute per-package destructive tests
13:08:07 <ncoghlan> although Kamil is still working on the disposable clients
13:08:09 <hhorak> ncoghlan: it only allows to run non-destructive tests running for all packages
13:08:38 <ncoghlan> while I think Beaker is mainly waiting on FAS integration being implemented
13:08:46 <hhorak> ncoghlan: I know, but they have too much to do otherwise, that's why the idea with helping by adding manpower :)
13:09:05 <ncoghlan> (Ansible was a holdup for a while, but the Beaker team wrote those playbooks recently)
13:09:22 * kparal is here, ask me if you need to know something
13:10:09 <hhorak> kparal: hi :) it's basically we didn't ask what is the status of disposable clients in taskotron for some time :)
13:10:37 <hhorak> kparal: and if the only problem is called manpower or if there are some other problems as well
13:11:21 <kparal> hhorak: all of us are working primarily on that right now. it's not implemented yet, though. we hope to have some demos to show on flock
13:11:34 <kparal> I think it's all about manpower at the moment
13:12:33 <hhorak> kparal: sounds quite fine :) do you already think about where the tests will live or this is not being solved yet?
13:13:23 <kparal> we haven't gone that far yet. our initial thoughts were dist-git or something parallel to dist-git
13:13:26 <hhorak> I still believe that even having some tests available and let users to run them if they can, would be success
13:13:54 <ncoghlan> make sure to talk to the fedpkg/rhpkg folks
13:13:56 <hhorak> * I meant run them on their machine (virtual)
13:14:07 <kparal> taskotron should be generic enough to accept any git repo url at all, fwiw
13:14:30 <ncoghlan> since they've been doing a lot of work integrating dist-git with Jenkins based testing
13:14:54 <ncoghlan> and it seems to me that should be adaptable to testing things in Taskotron from fedpkg
13:15:13 <ncoghlan> (he says, without having looked into any of the technical details of how that currently works)
13:15:21 <hhorak> kparal: if talking about it already -- will you need something more from the test than the `libtaskotron task` -- not sure how to call it properly
13:17:11 <kparal> we will need the check (hopefully written in arbitrary language, currently it needs to be python or a python wrapper) and task formula (yaml description of the steps)
13:17:34 <kparal> maybe some additional metadata, like definitions of when to run, for which packages, etc
13:18:30 <hhorak> kparal: nice, so no big limitations for the tests themselves.. thanks..
13:18:45 <kparal> I hope not
13:20:24 <langdon> not sure who to ask this of...but does taskotron have any integration with behave? and/or ci?
13:21:14 <langdon> walters, and.. on the ci/cd comment.. openstack CI is CD for devs/qe.. so i think would still fit the bill
13:21:18 <kparal> langdon: no, but tflink was talking in the past about possible behave integration, IIRC. you'd have to ping him
13:21:55 <ncoghlan> langdon: last time I checked, Taskotron could consume and report results from anything that could emit TAP
13:22:12 <langdon> ncoghlan, TAP?
13:22:19 <ncoghlan> langdon: https://testanything.org/
13:22:32 <kparal> well, it has to contain some taskotron-specific yaml blocks inside that TAP. plain TAP is too... simple.
13:23:06 <langdon> ncoghlan, ahh ok
13:23:24 <ncoghlan> kparal: ah, OK - I didn't know that
13:23:58 <kparal> we haven't really found any generic protocol that would allow to define test execution results well enough
13:24:25 <kparal> usually there's something missing, e.g. "what" got actually tested
13:26:22 <ncoghlan> kparal: unfortunately, if Taskotron can't consume results that tests produce *anyway*, it's going to end up with *no* meaningful data, rather than *some*
13:26:57 <ncoghlan> still, we're way off topic for env-and-stacks now
13:27:04 <kparal> we can definitely work on that. we started with TAP because it was simple
13:28:24 <phracek> #topic Open Floor
13:28:34 <phracek> Any topic to Open Floor?
13:29:05 <ncoghlan> I think we just did that with the testing discussion :)
13:29:35 <ncoghlan> we veered pretty far away from the container testing framework
13:30:35 <phracek> ok. I have thought that it is still a part of CTF.
13:30:36 <hhorak> nothing more here :)
13:30:49 <phracek> ok, thanks to all:) and for good discussion.
13:31:04 <hhorak> phracek: thanks for chairing the meeting!
13:31:15 <phracek> #endmeeting