12:03:17 #startmeeting Env and Stacks (2015-05-07) 12:03:17 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 12:03:49 #meetingname env-and-stacks 12:03:49 The meeting name has been set to 'env-and-stacks' 12:04:02 #chair bkabrda hhorak juhp ncoghlan vpavlin sicampbell walters ttomecek phracek 12:04:02 Current chairs: bkabrda hhorak juhp ncoghlan phracek sicampbell ttomecek vpavlin walters 12:04:14 hhorak: Hi 12:05:35 #topic Follow-ups, if any progress has been made 12:06:21 * langdon lurks 12:06:46 First of all I would like to introduce, that jstribny, asamalik and me (phracek) are going to start on 12:06:55 developer.fedoraproject.org page 12:07:06 Some preview screenshots are available here: 12:07:20 #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 #link http://download.eng.brq.redhat.com/scratch/phracek/project_page.png 12:07:52 juhp_: Hi 12:07:59 * ncoghlan likewise apologises for the extended absence 12:08:17 * bkabrda too 12:08:17 phracek, perhaps you could upload it somewhere public? :) 12:08:25 * vpavlin sneaks in.. 12:08:33 okay - you guys making me feel better ;) :) 12:08:55 phracek: I was about to ask the same question (I'm not on the VPN at the moment) 12:09:08 mmnt, I will past to fedoraproject.org 12:09:40 phracek, neat! 12:10:00 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 #link https://phracek.fedorapeople.org/landing_page.png 12:10:43 #link https://phracek.fedorapeople.org/project_page.png 12:10:52 the links should be available publicly 12:11:18 phracek: I'll echo ttomecek: neat! :) 12:11:32 those are very cool 12:11:40 Of course pictures are not real pages but the main page can look like as screenshots. 12:12:08 We plan to discuss some issues with langdon and workstation team how it can be improved 12:12:35 * langdon hides 12:12:40 phracek, thanks 12:13:01 ncoghlan, Nick, can you summarize the conversation a bit? 12:13:18 phracek, definitely should include mizmo too.. not sure if you did already ( i can't remember) and her "hubs" plan 12:13:42 langdon: maybe worth mentioning to the CentOS folks as well 12:13:43 The page should mainly help new fedora users and current Fedora users how to use project like docker, vagrant etc. 12:14:11 ncoghlan, a unified "developer on the OS page" might be interesting 12:14:15 langdon: a CentOS page like that would be a good way to point folks towards Software Collections 12:14:26 langdon: indeed 12:15:24 #info ncoghlan summarize the conversation with Randy Barlow on the Pulp team at PyCon 12:15:36 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 ncoghlan, i had proposed a similar idea for "container-y stuff" (here i think) a while back.. 12:16:08 (that's actually why he was at PyCon - presenting that at the poster session) 12:16:56 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 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 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 I talked to Randy about this and he said that lazy fetching is also on their priority list 12:19:41 bkabrda: am I right in thinking they wanted that as a general feature, not just for Python? 12:19:51 ncoghlan: correct 12:20:09 * hhorak finally ready, reading the above.. 12:20:19 * hhorak finally ready, reading the above... 12:20:21 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 ncoghlan: thanks for summary. Can we go to the next topic? 12:22:32 yep, I'll do a really short info summary as well 12:23:01 ncoghlan: Would you be able to send summary to ML? 12:23:20 phracek: sure, that's a better idea 12:23:28 #topic Docker images building within Fedora 12:23:46 #action ncoghlan send Pulp update to ML 12:25:07 In my action item I have TODO to check if all Docker images are ready for F22. 12:25:27 #link https://github.com/fedora-cloud/Fedora-Dockerfiles 12:25:45 * phracek did not have a time yet:( 12:26:04 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 hhorak: your turn:) 12:27:08 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 hhorak: sorry not yet:( I have to do that next week. 12:27:44 phracek: no problem.. 12:27:49 * phracek is appologize 12:28:32 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 the issue is koji and openshift v3: our current solution uses custom koji plugin 12:29:28 ttomecek: is this for base images, or layered ones? 12:29:30 looks like that fedora folks are not happy with koji and they would like to rewrite it or something like that 12:29:41 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 re openshift v3: it bundles several dozens of packages meaning unpackagable for Fedora 12:30:45 ttomecek: working on what? 12:30:49 ncoghlan, layered; base image can already be built in koji using img factoru 12:30:50 #info ttomecek works on build-system for dockerfiles with Fedora folks 12:30:51 ttomecek: and with who? 12:30:55 factory* 12:31:17 dgilmore, Paul Frields and Adam Miller were on the call 12:31:26 ttomecek: no one is working with Fedora releng on tooling for docker layered images 12:31:27 ttomecek: OK, cool - that's where I was puzzled :) 12:31:42 ttomecek: okay 12:32:03 ttomecek: they were just seeing what is being done 12:32:22 ttomecek: you can not really call that working on getting it in Fedora 12:32:32 there is a lot of work that needs to be done for that 12:32:43 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 dgilmore: thanks for clarifying, that aligns with my understanding as well 12:33:17 ncoghlan: we want to do it 12:33:28 but it is super super early 12:33:36 dgilmore: right 12:33:56 dgilmore, I agree: right now it's mainly really about investigation 12:34:10 dgilmore: jgreguske and gsterling gave me the rundown on their setup just after PyCon 12:34:11 #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 it will be a Fedora 23 thing 12:34:20 should have picked more appropriate words, sorry 12:34:50 ttomecek: :) it happens, its good to get clarification many times 12:35:31 given how fast various folks are moving at the moment, I'm not surprised we sometimes get confused :) 12:38:33 Gyus, thanks for information. The next topic is 12:38:38 #topic Containers-Testing-Framework 12:38:39 ncoghlan: indeed, I am in the middle of it all and often get confused 12:39:47 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 #link http://pythonhosted.org/behave/ 12:40:46 phracek, did those changes get accepted upstream? 12:41:14 langdon: AFAIK it was a proof of concept if the library can be used. 12:41:56 Next step is to show upstream that it can be used as a testing framework. 12:42:10 hhorak: Do you have a couple of words for that? 12:42:12 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 phracek: upstream as in Project Atomic? Or Container Tools? 12:43:31 If I understand properly then Container Tools. Like for Fedora_dockerfiles. 12:44:06 phracek, well.. i am pretty sure c-t is all in on behave.. once we get some things working 12:44:10 langdon: I don't understand what should be accepted upstream? 12:44:58 phracek: I wanted basically to share the link to let people know ... 12:44:58 #link https://github.com/Containers-Testing-Framework 12:45:19 it would be great if we started to use it somehow in fedora for the dockerfiles 12:45:26 hhorak: ok, thanks. I am pretty fast. 12:45:41 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 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 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 langdon: but hopefully we won't need to rely on that :) 12:46:57 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 ncoghlan, i think the work is only a couple days.. but.. not a couple days i have :) 12:47:19 ncoghlan: Do we plan to use behave generally for let's say all applications? 12:47:34 phracek: that would be nice :) 12:47:44 phracek: where I consider it most interesting is in the context of independent QA testing 12:47:46 but i don't think anybody is working on it 12:48:00 including all current projects like vim, emacs, devassistant etc.? 12:48:16 or better say all current packages. 12:48:23 and the kinds of stuff we might want to do as application independent checks of a container 12:48:24 please no 12:48:29 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 ttomecek: I hope so that not:) 12:48:56 walters, i was hopeing to use the centos-ci 12:49:04 for fedora? 12:49:13 walters, yeah.. why not :) 12:49:17 ok 12:49:17 phracek, ttomecek: don't think unit tests, think acceptance tests IMO 12:49:41 ok. Thanks for confirmation.:) 12:49:48 i guess if we do that, we could use centos' instance of the container build service as well 12:50:06 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 langdon: +1 12:51:10 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 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 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 ncoghlan, uhh.. that sounded like you were quoting a rational sales guy.. could you elaborate? :) 12:52:52 langdon: internal QE test we're not going to break the world before pushing out new updates to internal services 12:53:02 a lot of that testing is more manual than we'd like right now 12:53:37 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 and a BDD framework like behave seems like a potentially good candidate 12:54:00 ttomecek: those are likely to be unit tests, not acceptance tests 12:54:04 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 ncoghlan, understood 12:54:50 langdon: http://serverspec.org/ is an RSpec based example of that 12:54:54 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 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 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 see you next week guys, I've got another meeting in 5 12:56:25 bkabrda: bye:) 12:56:35 ncoghlan, ha.. well.. isn't that the point? they are supposed ot be writing that part anyway 12:57:08 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 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 hmm yeah 12:58:35 hhorak, sure.. but if all the examples are written in behave.. guess what most people will write them in :) 12:58:35 hhorak: you generally still need a meta-framework of some kind 12:58:45 i thought about this for a long time 12:58:49 you know it's 2015 12:59:01 e.g. Beaker has beakerlib et al 12:59:01 we have lots and lots and lots of people who are very experienced with build systems and such 12:59:06 walters: me too, but never got to some real PoC :) 12:59:10 how is it that in 2015 the fedora testing sucks so much? 12:59:23 walters: exactly 12:59:31 the answer i eventually concluded is that because we can't undo, tests can only be "advisory" 12:59:39 like file bugs or such 12:59:48 and that's very weak 13:00:00 people would pay a *lot* more attention to a test system if we reverted builds based on it 13:00:08 anyways that was just my thought 13:00:11 true 13:00:38 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 walters, +1 .. and a blue dunce cap is mailed to your house 13:00:45 walters: might be, but still we need to first have the tests and run them :) 13:01:00 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 walters: of you meant to revert builds even on bugs? 13:01:18 walters: their attitude has improved in recent times ;) 13:02:25 but yes, getting Fedora to the point where builds are gated far more strongly is highly desirable 13:03:15 gating is a waterfall model 13:03:18 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 which is what we have now 13:03:29 try-and-revert is totally different 13:03:41 walters, the openstack ci is fairly brilliant in that regard 13:03:52 * langdon notes ci.openstack.org 13:04:01 yeah that's CI though, not CD 13:04:04 yes, that's the kind of gating I was referring to 13:04:31 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 walters: a number of the cloud provides run trunk 13:05:16 langdon: taskotron (through TAP), and beaker.fedoraproject.org (through beah/restraint) already offer meta-frameworks 13:05:48 langdon: behave is mainly interesting for writing *new* tests in a behavioural style 13:07:10 still, solving this isn't primarily Env&Stacks problem - it's qa-devel's :) 13:07:15 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 taskotron is up & running I believe 13:07:53 ncoghlan: but it doesn't allow to execute per-package destructive tests 13:08:07 although Kamil is still working on the disposable clients 13:08:09 ncoghlan: it only allows to run non-destructive tests running for all packages 13:08:38 while I think Beaker is mainly waiting on FAS integration being implemented 13:08:46 ncoghlan: I know, but they have too much to do otherwise, that's why the idea with helping by adding manpower :) 13:09:05 (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 kparal: hi :) it's basically we didn't ask what is the status of disposable clients in taskotron for some time :) 13:10:37 kparal: and if the only problem is called manpower or if there are some other problems as well 13:11:21 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 I think it's all about manpower at the moment 13:12:33 kparal: sounds quite fine :) do you already think about where the tests will live or this is not being solved yet? 13:13:23 we haven't gone that far yet. our initial thoughts were dist-git or something parallel to dist-git 13:13:26 I still believe that even having some tests available and let users to run them if they can, would be success 13:13:54 make sure to talk to the fedpkg/rhpkg folks 13:13:56 * I meant run them on their machine (virtual) 13:14:07 taskotron should be generic enough to accept any git repo url at all, fwiw 13:14:30 since they've been doing a lot of work integrating dist-git with Jenkins based testing 13:14:54 and it seems to me that should be adaptable to testing things in Taskotron from fedpkg 13:15:13 (he says, without having looked into any of the technical details of how that currently works) 13:15:21 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 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 maybe some additional metadata, like definitions of when to run, for which packages, etc 13:18:30 kparal: nice, so no big limitations for the tests themselves.. thanks.. 13:18:45 I hope not 13:20:24 not sure who to ask this of...but does taskotron have any integration with behave? and/or ci? 13:21:14 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 langdon: no, but tflink was talking in the past about possible behave integration, IIRC. you'd have to ping him 13:21:55 langdon: last time I checked, Taskotron could consume and report results from anything that could emit TAP 13:22:12 ncoghlan, TAP? 13:22:19 langdon: https://testanything.org/ 13:22:32 well, it has to contain some taskotron-specific yaml blocks inside that TAP. plain TAP is too... simple. 13:23:06 ncoghlan, ahh ok 13:23:24 kparal: ah, OK - I didn't know that 13:23:58 we haven't really found any generic protocol that would allow to define test execution results well enough 13:24:25 usually there's something missing, e.g. "what" got actually tested 13:26:22 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 still, we're way off topic for env-and-stacks now 13:27:04 we can definitely work on that. we started with TAP because it was simple 13:28:24 #topic Open Floor 13:28:34 Any topic to Open Floor? 13:29:05 I think we just did that with the testing discussion :) 13:29:35 we veered pretty far away from the container testing framework 13:30:35 ok. I have thought that it is still a part of CTF. 13:30:36 nothing more here :) 13:30:49 ok, thanks to all:) and for good discussion. 13:31:04 phracek: thanks for chairing the meeting! 13:31:15 #endmeeting