13:02:49 <hhorak> #startmeeting Env and Stacks (2015-02-26)
13:02:49 <zodbot> Meeting started Thu Feb 26 13:02:49 2015 UTC.  The chair is hhorak. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:02:49 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:02:54 <hhorak> #meetingname env-and-stacks
13:02:54 <zodbot> The meeting name has been set to 'env-and-stacks'
13:02:57 <hhorak> #chair bkabrda hhorak juhp ncoghlan vpavlin sicampbell walters ttomecek phracek
13:02:57 <zodbot> Current chairs: bkabrda hhorak juhp ncoghlan phracek sicampbell ttomecek vpavlin walters
13:03:21 <hhorak> #topic init process
13:03:39 * hhorak was a bit late, sorry for that
13:04:17 <bkabrda1> hhorak: no worries. and hi everyone!
13:04:58 <phracek> hhorak: but you are here. great. hi all too.
13:06:19 <ttomecek1> hello
13:06:51 <hhorak> I'd like to add one scl topic more (just quickly)
13:07:05 <hhorak> #topic Removing 'scls' from %{_sysconfdir} and %{_localstatedir}
13:07:30 <hhorak> This is a discussion I opened today at:
13:07:30 <hhorak> #link https://www.redhat.com/archives/sclorg/2015-February/msg00032.html
13:08:40 <hhorak> I'd appreciate if you could take a look and express your opinions -- basically if we expect some more stuff under /opt/fedora and so if collections should be placed under /opt/fedora/scls rather than just /opt/rh
13:09:50 <ttomecek> /opt/fedora seems like a better place: we don't want possible conflicts, right?
13:10:27 <hhorak> The original reasoning mentions conda and wheel technologies under /opt/fedora as well..
13:10:27 <hhorak> #link https://bugzilla.redhat.com/show_bug.cgi?id=1066665#c8
13:11:19 <bkabrda1> hhorak: so the vendor owns the whole namespace, so it's his job to make sure that SCLs don't conflict with any of his other shipped products/rpms/...
13:11:36 <hhorak> ttomecek: not sure if I understand, it's more about /opt/fedora vs. /opt/fedora/scls
13:12:39 <hhorak> bkabrda1: I read it like the 'scls' part is not that necessary in your opinion, right?
13:12:45 <bkabrda1> hhorak: exactly
13:12:57 <phracek> I think /opt/fedora/scls is reasonable.
13:13:22 <bkabrda1> I mean, why would someone ship "python33" SCL as well as something-that-is-not-scl "python33"? what would be point of that?
13:13:22 * ncoghlan is still skimming the bug
13:13:27 <phracek> /opt/rh is for RHEL and /opt/fedora is for Fedora. We need to have the same structure based on FHS.
13:13:47 <ncoghlan> bkabrda1: I think it's more for categorisation than avoiding conflict
13:13:51 <phracek> /opt/scl does not make sense from /me point of view.
13:14:21 <ncoghlan> "/opt/fedora/foo" doesn't give any semantic info
13:14:37 <hhorak> phracek: sure, /opt/scl is not in the game at all
13:14:37 <ncoghlan> "/opt/fedora/scls/foo" tells you immediately that "foo" is an SCL
13:15:02 <phracek> ncoghlan: yes. Sounds good.
13:15:05 <bkabrda1> ncoghlan: that's a good point. the question - how is such categorization useful? do I really need to know what that directory ships looking just at it's path?
13:15:12 <phracek> you now that foo is a part of SCL.
13:15:26 <phracek> s/now/know/g
13:15:29 <ncoghlan> I think the key point is Toshio's one in https://bugzilla.redhat.com/show_bug.cgi?id=1066665#c8
13:15:36 <bkabrda1> (that should've been "the question is")
13:15:42 <ncoghlan> that we don't currently know which ideas are going to stick
13:16:31 <ttomecek> hhorak, just reread all those posts you mentioned and now I get it
13:16:38 <ncoghlan> so we might try conda, we might try nix, we might try setting up language specific virtual environments
13:16:44 <phracek> I think that /opt/fedora/conda say you that it is a software to fedora. But nothing related with SCL.
13:17:18 <phracek> Can it be /opt/conda/scl?
13:17:40 <ncoghlan> right, I think that "/scls/" part of the path is for partitioning the "alternate packaging systems" from each other
13:18:01 <ttomecek> ncoghlan, +1
13:18:08 <hhorak> phracek: the second part is <vendor> so unless we consider "a technology" to be the vendor, then no :)
13:18:26 <bkabrda1> ncoghlan: oh, so you want to have e.g. /opt/fedora/scls alongside /opt/fedora/conda-envs etc?
13:18:26 <phracek> hhorak: THX for explanation.
13:18:37 <ncoghlan> yeah, that's the way I read Toshio's comment
13:18:48 <ncoghlan> and I think it's a good idea to preserve that option
13:18:53 <juhp> seems reasonable to me too
13:19:18 <bkabrda1> ncoghlan: ok, taking other technologies into mix makes it reasonable to include /scls/
13:19:28 <bkabrda1> *other packaging technologies
13:19:32 <hhorak> it seems we can try voting after quite looong time...
13:19:39 <ncoghlan> in effect, it would "/opt/<vendor>/<format>/foo"
13:19:43 <ttomecek> but it will be such a PITA to navigate inside collection /opt/fedora/scl/python33/root/usr/lib/python3.3/site-packages/...
13:20:04 <bkabrda1> ttomecek: it's a PITA now, one more level won't make it that much worse ;)
13:20:14 <ncoghlan> ttomecek: I wonder if there might be value in easily chrooting into SCLS
13:20:19 <juhp> (I would probably have called it /opt/fedora/scl/ rather than /opt/fedora/scls/ too)
13:20:29 <ncoghlan> juhp: +1
13:20:47 <ncoghlan> the plural doesn't convey any useful info IMO
13:20:58 <bkabrda1> ncoghlan: site-packages?
13:21:08 <ncoghlan> bkabrda1: touche :)
13:21:10 <bkabrda1> as in "this directory has more of these"?
13:21:13 <bkabrda1> :)
13:21:15 <hhorak> I've heard some other people prefer scl over slco as well
13:21:38 <bkabrda1> I'm personally for "scls" (plural)
13:21:41 <ttomecek> ncoghlan, you can do that already: scl enable python33 bash
13:21:42 <ncoghlan> actually, now that I think about it, don't we use rpms and srpms as dir names in various places as well?
13:21:53 <hhorak> #help
13:22:14 <ncoghlan> ttomecek: that would be my suggestion then - once you chroot in, the prefix doesn't matter so much
13:22:39 <bkabrda1> ncoghlan: in ~/rpmbuild, for example
13:23:04 <ncoghlan> bkabrda1: also common in source yum repos
13:23:07 <juhp> ncoghlan, rpm does yes: RPMS, SOURCES, SRPMS, SPECS, shrug :)  no BUILDROOTS ;o)
13:23:13 <bkabrda1> ncoghlan: yeah, I think so
13:23:44 <ncoghlan> OK, so I guess the plural counts as being more conventional, making it a reasonable idea
13:23:53 * hhorak failed to find if there is a keyword for voting in ircbot (#voting?)
13:23:57 <juhp> ncoghlan, I disagree
13:24:22 <juhp> but everyone prefer scls that's fine
13:24:26 <juhp> if
13:24:27 <bkabrda1> juhp: what's your reasoning?
13:24:53 <juhp> bkabrda1, I think scl is well enough understand as an acronym
13:24:59 <juhp> understood
13:25:16 <juhp> anyway I don't want to bikeshed :)
13:25:34 <bkabrda1> I guess we'll just agree on disagreeing this time :)
13:25:41 <juhp> seems so
13:27:04 <hhorak> #proposal Using /opt/<vendor>/scls allows to categorize content from one vendor, so it will be preferred way for collections in Fedora
13:27:36 <hhorak> let's try voting then (just to make that official)
13:27:49 <ncoghlan> for the record, I thought of a specific use case not so much for the /opt tree, but for /var, which would be as a home for a shared Python wheelhouse
13:27:49 <bkabrda1> hhorak: +1
13:28:01 <ncoghlan> hhorak: +1
13:28:09 <phracek> phracek: +1
13:28:21 <hhorak> +0 (I'm actually not sure now, used to prefer no-scls but you made me believe it is not that bad :) )
13:29:11 <ttomecek> hhorak, +1
13:29:26 <ttomecek> (still like 'scl' more, it's shorter)
13:29:39 <juhp> ttomecek, +1
13:29:40 <juhp> +1
13:30:18 <juhp> I hope we don't have condas and wheels too...
13:30:18 <hhorak> #agreed The preferred way for collections in Fedora is to use a directory under /opt/<vendor>, which allows to categorize content from one vendor (e.g. /opt/fedora/scls)
13:30:50 <hhorak> so let's vote again about scls vs. scl :)
13:31:13 <phracek> phracek: scl +1
13:31:20 <hhorak> #proposal To use scls over scl under /opt/fedora
13:31:51 <hhorak> phracek: sorry, I put the question the other way round, so it means you're -1 for this?
13:31:57 <ttomecek> hhorak, -1
13:32:05 <ncoghlan> +1 (mostly for consistency with rpmbuild directory naming style)
13:32:13 <juhp> -1
13:32:15 <bkabrda1> hhorak: +1
13:32:17 <hhorak> +1
13:32:38 <phracek> yeah.
13:32:53 <phracek> hhorak: scl +1
13:33:17 <phracek> /opt/fedora/scl/ for sure
13:33:22 <hhorak> hm, it is deuce then, +3, -3 if I count correctly
13:33:45 * ncoghlan votes that hhorak flips a coin :)
13:33:58 <ncoghlan> actually, isn't scls the current path?
13:34:06 <hhorak> or let scl-utils developers to decide?
13:34:09 <ttomecek> hhorak, isn't your vote worth 2 votes? :p
13:34:40 <ncoghlan> hhorak: "developer's choice" sounds good to me
13:34:40 <phracek> SCL has original name SoftwareCollections and at the end is 's'. Select what ever you want.
13:34:59 <phracek> in RHEL is scls, right?
13:35:04 <hhorak> ttomecek: it definitely is not :)
13:35:15 <hhorak> phracek: yes
13:35:26 <hhorak> scls is actually used now in latest scl-utils
13:35:31 <bkabrda1> so there are two ways to look at it
13:35:38 <phracek> Then I think we should no complicate the stuff.
13:35:54 <bkabrda1> 1) scls - the directory holds arbitrary number of collections
13:36:23 <bkabrda1> 2) scl is the technology and scls will live in /opt/fedora/scl, similarly to e.g. conda envs, that will live in /opt/fedora/conda
13:36:44 <bkabrda1> (where in 1), conda envs should rather occupy something like /opt/fedora/conda-envs)
13:37:21 <juhp> right
13:37:27 <ncoghlan> For the record, conda itself uses an "envs" directory by default
13:37:27 <bkabrda1> if that makes sense to anyone :)
13:37:59 <ncoghlan> similarly, mkvirtualenv defaults to ".virtualenvs"
13:38:21 <ncoghlan> so there's definitely a trend towards naming the collection rather than the technology (when you also factor in rpmbuild)
13:38:47 <juhp> given the rhel precedent maybe scls is good enough
13:39:09 <phracek> ncoghlan: yeah. technology as a directory name is not a good way. Than I am changing thew vote.
13:39:12 <phracek> scls +1.
13:39:16 <bkabrda1> yeah, I'm also +1 for "scls" as "directory for collections"
13:39:19 <phracek> bkabrda1: Thanks for explanation.
13:39:40 <phracek> And now no coin is need:)
13:40:09 <hhorak> so with phracek's change we can
13:40:09 <hhorak> #agreed to use scls for "directory for collections" rather than scl
13:40:48 <hhorak> Anyway, thanks for help with this, we can probably leave this topic
13:40:52 <hhorak> #topic Follow-ups: Dockerfiles recommended tips
13:40:52 <juhp> sorry if I triggered this discussion - it is also why I wrote "I would have called..." :)
13:41:39 <phracek> I would like to create a site like docker.fedoraproject.org where could be a relevant information
13:41:43 <hhorak> juhp: I guess it was actually a good discussion
13:41:48 <juhp> :)
13:41:55 <phracek> It could be specific to Fedora.
13:42:28 <phracek> And I also prefer to create a page or reference to OpenShift documentation like 'docker for dummy's'
13:43:07 <phracek> It does not currently matter what type of page is going to be used. Like wiki or dJango
13:43:09 <ncoghlan> I'd avoid that particular phrasing, but having a landing page for that sounds like a good idea to me
13:43:43 <phracek> I'd prefer to have more pages then only the big one.
13:44:13 <ttomecek> phracek, so what do you plan to have there? can you name some sections?
13:44:26 <phracek> ttomecek: good point.
13:44:32 <ncoghlan> from a content maintenance perspective, I'm hoping to get some cross platform client docks upstream in Project Atomic
13:44:39 <phracek> 1) Description of docker files
13:44:47 <ncoghlan> and there's already the OpenShift docs
13:44:47 <phracek> 2) Install docker in Fedora
13:45:09 <phracek> 3) using Fedora images or whether can be called.
13:45:23 * ttomecek is going to check atomic docs
13:45:33 <phracek> nchauvet: yes I have read the article but from my point of view it is a one big page.
13:45:44 <phracek> nchauvet: sorry type
13:45:51 <ncoghlan> ttomecek: no client docs yet, hence the "hoping to get" :)
13:46:32 <phracek> 4) docker templates like docker files or images for some stuff (e.g. databases, LAMP, etc.)
13:46:47 <phracek> DevAssistant could help us with this issue I think.
13:47:01 <phracek> 5) How to check your own docker file?
13:47:31 <phracek> I think that each user would like to create its own docker file and there we should provide a dockerlint for that.
13:47:41 <ttomecek> ncoghlan, what client docs you mean actually? sorry, i don't follow
13:47:57 <phracek> But it could be planned later on. It is not needed now.
13:48:02 <ncoghlan> ttomecek: there aren't any, I've been scheming with langdon re how we might create some
13:48:49 <phracek> And of course there should be a description between dockerfile, docker images and docker containers and their workflow.
13:48:55 <ttomecek> phracek, I think it would be really *cool* to have a webbased linter (wild & crazy idea)
13:49:18 <ncoghlan> phracek: that's where I think you're going too far in duplicating content
13:49:20 <ttomecek> ncoghlan, my point was: client of what?
13:49:30 <phracek> ttomecek: why not? It could be amazing? Are you a volunteer;)
13:49:34 <ncoghlan> phracek: "docker in Fedora" yes, "what is Docker?" no
13:49:47 <ncoghlan> ttomecek: developer workflow for container based deployments
13:50:03 <phracek> ncoghlan: ok. Then only reference would be enough.
13:50:17 <ttomecek> ncoghlan, right! that rings some bells; docs like that would be super-useful
13:51:17 <ttomecek> phracek, have to agree with Nick on this. docker's own docs are really great and that's the place where every developer starts, more or less (do we want to change it?)
13:51:30 <ttomecek> i think we should really focus on 'docker in fedora'
13:51:58 <ncoghlan> but it's OK to start with "If you don't know what Docker is, <link to upstream tutorial>"
13:52:01 <phracek> ttomecek: ok. Till next meeting I am going to create my own docker file and let you know my results or brief summary.
13:52:11 <ncoghlan> phracek: also worth looking at https://github.com/fedora-cloud/Fedora-Dockerfiles
13:52:26 <ncoghlan> I think that ties in to your point about examples
13:52:44 <phracek> ncoghlan: Are they bundle in fedora as a package?
13:52:54 <ncoghlan> now, making DevAssistant fedora-dockerfiles aware would be quite neat
13:53:00 <ncoghlan> phracek: yes
13:53:27 <ncoghlan> or maybe it would be a better fit for the stuff langdon and I are looking at
13:53:29 <ncoghlan> hmm
13:53:39 * bkabrda1 hides and covers, hearing about DevAssistant
13:53:44 <phracek> awesome. Then only page how to use in Fedora.
13:53:58 <ncoghlan> I guess it's not an either/or, we could do both (in everyone's copious spare time)
13:54:08 <phracek> bkabrda1: You should be proud about this cool project:)
13:54:27 <ttomecek> ncoghlan, then there should be some proper howto use that particular image as a base for my application
13:54:48 <ncoghlan> ttomecek: yes, that's the part I'm not sure where it should live
13:54:54 <phracek> Let me a week for trying to game with docker and I will let you now results.
13:54:54 * bkabrda1 is proud but also painfully aware, that lots of stuff in assistants is inconsistent and could use dozens of hours of work to improve...
13:55:01 <hhorak> #info having some docker.fedoraproject.org will be very beneficial
13:55:01 <hhorak> #idea content should focus on "docker in Fedora" and developer workflow for container based deployments, not that on "what is Docker?"
13:55:30 <hhorak> #idea making DevAssistant fedora-dockerfiles aware would be quite neat
13:55:32 <phracek> I think man page for docker, dockerfiles would be welcome.
13:55:44 <ncoghlan> ttomecek: I guess we don't have to decide now, we can iterate, and adjust the balance of duplication-vs-cross-reference as we go
13:55:48 <ttomecek> ncoghlan, maybe there could be some metadata for each dockerfile which devassistant would access and present to developer (we could also generate some web docs out of it)
13:56:19 <phracek> hhorak: If I understand properly. fedora-dockerfiles for creating dockerfiles or installing package?
13:56:35 <ttomecek> phracek, man page? docker already has one
13:56:47 <phracek> man dockerfiles I meant
13:56:50 <phracek> .
13:56:55 <ncoghlan> ttomecek: I suspect even better would be to have some conventions in the way we write Dockerfile's such that DevAssistant knows how to read me
13:57:02 <ncoghlan> *read them
13:57:20 <ncoghlan> but we're also getting ahead of ourselves
13:57:29 <ttomecek> phracek, man 5 Dockerfile
13:57:33 <ncoghlan> that kind of integration is in the "nice to have" category at this point
13:57:46 <phracek> ttomecek: THX, I did not tri it yet:)
13:57:51 <phracek> s/tri/try/
13:57:58 <hhorak> phracek: I'm not sure what you mean by that question :)
13:58:19 <phracek> hhorak: I have lost. which one?
13:58:20 <langdon> s/enjoy/open
13:58:37 <hhorak> phracek: about fedora-dockerfiles
13:59:00 <hhorak> hooops, I almost forgot I have another meeting in few minutes, can I ask somebody to finish the meeting, please?
13:59:03 * phracek is thinking
13:59:19 <langdon> ncoghlan: we should get together and discuss our plot(s) more completely
13:59:27 <hhorak> (the last topic on agenda -- "Playground repo revisiting" -- may be left for the next meeting, my intention was only to share the great news from copr guys, that we have singing in copr now, which was a blocker for this feature)
13:59:29 <ttomecek> ncoghlan, right; it would be super nice and useful to figure those conventions out (lots of crazy ideas in my head)
13:59:42 * hhorak waiving, very sorry...
13:59:59 <juhp> singing?
14:00:14 <ncoghlan> langdon: we should. apparently there's this thing called video conferencing which I keep forgetting exists :)
14:00:27 <ttomecek> every time you build a package in copr, copr developers will sing for you
14:00:38 <langdon> ncoghlan: it's just for mktg people
14:00:45 <phracek> I am opened for that.
14:00:51 <juhp> ttomecek, rotfl
14:01:24 <phracek> DevAssistant and fedora-dockerfiles means installing the package? Or creating a dockerfiles?
14:01:44 <phracek> bkabrda1: It is possible to create a assistant to DevAssistant for creating dockerfile? I think not.
14:02:16 <phracek> s/It is/Is it/g
14:02:17 <bkabrda1> phracek: depends what you would want it to do
14:02:59 <ncoghlan> phracek: it was speculation about possibly using those as starting points for new container projects. Pie-in-the-sky as far as I know
14:03:22 <phracek> I thoght create a docker file from scratch. We could discuss about it later on.
14:03:51 <phracek> I think that we can skip it for now.
14:03:51 <juhp> ncoghlan, right
14:04:16 <ncoghlan> back on the last topic hhorak mentioned
14:04:20 <phracek> We should create a page for docker files firstly.
14:04:40 <ncoghlan> yay & grats to the copr folks for getting the signing support done :)
14:04:45 <ttomecek> okay guys, I have to leave for another meeting too; thanks for great chat, see you
14:05:19 <ncoghlan> but with time up & folks having to go, I guess we're done for this week
14:05:45 <phracek> I have to leave too. Can we close the meeting?
14:06:03 <bkabrda1> yeah, let's close
14:07:04 <juhp> ncoghlan, ahh thanks for the clarification ;)
14:07:51 <ncoghlan> juhp: I had an unfair advantage, I saw there original announcement on copr-devel :)
14:08:44 <ncoghlan> anyway, let's see if I have the right permissions...
14:08:47 <ncoghlan> #endmeeting