infrastructure July 2014

infrastructure@lists.fedoraproject.org

58 participants
44 discussions

2014-07-21 Fedora Atomic Infrastructure Meeting - Minutes
by Brian Proffitt 21 Jul '14

21 Jul '14

============================== #atomic: Atomic infrastructure ============================== Meeting started by jzb at 15:03:13 UTC. The full logs are available at http://meetbot.fedoraproject.org/atomic/2014-07-21/atomic.2014-07-21-15.03.… . Meeting summary --------------- * Minimum for Alpha (jzb, 15:04:18) * Mirroring approach probably needed for scale, even if we don't project a high number of users. (stickster, 15:14:51) * Volunteer oddshocks to work on MirrorManager code fixes needed (need to get this more granular, work with dgilmore/nirik) (stickster, 15:16:24) * Volunteer oddshocks to work on MirrorManager code fixes needed (need to get this more granular, work with dgilmore/nirik/walters as needed) (stickster, 15:17:18) * LINK: http://rpm-ostree.cloud.fedoraproject.org/repo/refs/heads/fedora-atomic/raw… (walters, 15:19:42) * ACTION: stickster Send out whenisgood to figure out a slot for next week (stickster, 15:37:54) * ACTION: walters will start a thread on official tree composes and mirroring.. (jzb, 15:38:03) * Where do we need help immediately, and who can step up? (jzb, 15:40:53) * We need to consider where object stores might be backed in the future, based on the observed delta from F21 Alpha (stickster, 15:46:27) Meeting ended at 15:55:09 UTC. Action Items ------------ * stickster Send out whenisgood to figure out a slot for next week * walters will start a thread on official tree composes and mirroring.. Action Items, by person ----------------------- * stickster * stickster Send out whenisgood to figure out a slot for next week * walters * walters will start a thread on official tree composes and mirroring.. * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * stickster (48) * walters (48) * jzb (39) * mattdm (32) * nirik (29) * dgilmore (19) * misc (14) * KidProton (8) * oddshocks (5) * zodbot (3) * bochecha (3) * smooge (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC

1 0

Regular meetup for Atomic
by Paul W. Frields 21 Jul '14

21 Jul '14

Visit this link to indicate preferences for a regular 30-minute slot. http://whenisgood.net/atomic-2014-07 All interested parties welcome; time preference will be given to critical representatives from Atomic, Infra, Rel-eng. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com

1 0

Agenda for today's meeting on Atomic
by Joe Brockmeier 21 Jul '14

21 Jul '14

Hi all, In the interest of keeping things moving well, I threw together a quick draft agenda: - Quick roll call - What is the minimum we need to get to alpha status? (e.g., produce something testable, consumable, usable but not necessarily "production quality") - What are other blockers we need to solve to be able to have an official release? (as opposed to a remix) - Where do we need help immediately, and who can step up? - What are we missing entirely? - Action items for the next week or two - Agreement on next meeting time # # # Anything else? Thoughts, comments, flames? Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb(a)redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/

2 2

Fedora Atomic Infrastructure Meeting: July 21, 2014
by Brian Proffitt 21 Jul '14

21 Jul '14

1 0

ask fedora -- closing questions because they're answered?
by Matthew Miller 21 Jul '14

21 Jul '14

I'm asking this here for lack of a "meta" site for Ask Fedora. :) I recently came across this: https://ask.fedoraproject.org/en/question/50626/when-will-dnf-fully-be-port… I'm a bit perplexed by the close reason -- "the question is answered, right answer was accepted". Whatever the reason, this shows up in the list of questions with [closed] by the title (in addition to the green checkmark indicating that an answer was accepted). Why would we want to do this? Isn't the point to build up a body of questions and answers? I think closing should be reserved for _problematic_ questions -- off topic, spam, argumentative, etc. But maybe I'm not getting something here. Does closing questions for being successful have a benefit I'm missing? -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

4 5

Atomic Status / Fedora Infra discussion
by Joe Brockmeier 21 Jul '14

21 Jul '14

The following is a new meeting request: Subject: Atomic Status / Fedora Infra discussion Organizer: "Joe Brockmeier" <jzb(a)redhat.com> Location: #atomic on Freenode Time: Monday, July 21, 2014, 10:00:00 AM - 10:30:00 AM GMT -06:00 US/Canada Central Invitees: infrastructure(a)lists.fedoraproject.org; ssmoogen(a)redhat.com; kfenzi(a)redhat.com; mscherer(a)redhat.com; mbridon(a)redhat.com; dgay(a)redhat.com; walters(a)redhat.com; pfrields(a)redhat.com; mattdm(a)redhat.com *~*~*~*~*~*~*~*~*~* Hi all, Hope this will work for a quorum, especially Colin, Matthew, Kevin, and Stephen! Best, jzb

1 0

Atomic status
by Colin Walters 21 Jul '14

21 Jul '14

Hi, I feel like things aren't moving forward quickly enough with Atomic, both on the Docker base image side and the rpm-ostree host side. A lot of that is to be expected - we're trying to introduce *two* new ways to deliver software beyond RPMs at the same time. It's quite nontrivial. There's also: 1) We're trying to do new projects, but we haven't added significant human resources 2) This is also the first Fedora.next release 3) We don't know how popular the whole Atomic/Docker model will be until we do a stable release really, but it's hard to get current Infrastructure people to spend time on it without knowing how valuable it is... Let's look at blocking issues for Atomic in Fedora: - Having rpm-ostree be run as part of nightly compose - Content mirroring * Server with SSL, some level of redundancy * Open question around how often/when composes are done, and how much history is retained - GPG signing - Method of having Koji/ImageFactory pull mirrored OSTree repository content to compose ISOs - MirrorManager integration (no code written on ostree side yet) To the best of my knowledge, code exists for all of the above except the last, and the last bit is hard to write without having a deployment of MirrorManager using it, which depends I see two solution paths: - Double down and fix the above, continue trying to sync Atomic with Fedora * Have more time from current Infra people on above * Have me/other members of my team join infra * Mix of both? - Have Atomic be a Remix, partially in infra, partially outside - Have custom GPG key - Continue doing composes on the atomic01.qa.fedoraproject.org machine - Mirror to something like Amazon CloudFront (would require external sponsorship from Red Hat) Would more regular meetings help?

7 22

Fwd: On Fedora's Localization platform
by Dimitris Glezos 18 Jul '14

18 Jul '14

Resending to infra since it didn't go through. -- Dimitris Glezos Founder & CEO, Transifex (sent from device prone to typos) ---------- Forwarded message ---------- From: "Dimitris Glezos" <glezos(a)transifex.com> Date: Jul 17, 2014 1:17 PM Subject: On Fedora's Localization platform To: "Fedora Infrastructure" <infrastructure(a)lists.fedoraproject.org> Cc: "Fedora Translation Project List" <trans(a)lists.fedoraproject.org>, "For participants of the Documentation Project" <docs(a)lists.fedoraproject.org> Hey all, I'll share some of my thoughts at this point. *GIST* - *Freedom* is more than just access to a tarball. What kinds of Freedom is Fedora enjoying and giving up by using a platform like Transifex or GitHub? - What is the *Board's position* about using non-open-source but open-friendly services? How much should we sacrifice to only run open-source on our servers? - Research thoroughly all possible solutions and find out what exactly we'll be sacrificing and gaining. *Pootle* is much more trusted than Zanata. - Ask all key Fedora L10n people. Past and current. - Any switch should be led by a technical Fedora localization person. - The goal should be to make Fedora L10n a successful project. The tools are just tools. The most important community features in Transifex have not been used. *BACKGROUND* My contributions to Fedora nowadays are limited to supporting the L10n project with our Transifex instance. I used to be a member of the Fedora Board in the past. I see there's still the title "Fedora Localization Lead" next to my name, but I suppose that's mostly because no one else took the role. Today I basically make sure the community has what they need from Transifex. I trust Piotr Drąg (raven) for any L10n leadership questions I have. Today a decision is being brewed on the basis that Transifex is not open-source. As I mentioned, this is a discussion which needed to happen. But I find the way it's being discussed disappointing to all the years of hard work many individuals have put to establish a successful L10n platform for Fedora (including my own). Many people in Fedora (and Transifex) have *invested man years to make this work*. We haven't even discussed "what are the key things we need from our L10n platform"? Following are my thoughts. I'm writing these with an effort to wear my Fedora L10n hat as much as possible. But the POV does also include my roles as Transifex's CEO, Fedora's Localization Infrastructure Lead for the past 6 years, and as one of the most experienced people on open-source localization. *ON FREEDOM* When I was young I was looking at freedom in a different way. I was more an open source zealot than today. I cared mostly about openness of the code. It didn't matter if there was only one engineer hacking on the code. What mattered was the license and little more. Gradually I started realizing one of the reasons I loved Fedora was that it valued highly quality and community participation. It valued relationships, productivity, happiness, innovation. We valued meritocracy more than democracy. Succeeding as a distributions was more than just having the sources of packages. *I'm not a fan of the spin put on Freedom in this discussion*. Fedora is free to use Transifex forever. It's free to export all data at any point (including all past translations and all the history of the translations so far) to move to another platform. And it was free to use real people from our team working on improving the platform constantly and adding new features. I've met a lot of people in Fedora. The smartest ones knew very well that *Freedom is not a one-colored attribute*. *MIGRATING* Migrating from one platform to another will have *major costs*. I led the original migration from Elvis <http://fedoraproject.org/wiki/Archive:L10N/Tools/Plans> to Tx. It required many meetings with stakeholders, research, experiments. In the end, *it costed us more than half our translators*. Assuming the Freedom discussion is resolved and the benefits of the migration outweigh the costs. If I were leading this (and did not have a vested interest in one platform...), the last thing I'd want, is to go through the trouble of migrating, only to find out 5 key things we need are missing. *Zero research was done* on the available tools out there and how they stack with Transifex. Here are examples of research done by other projects which came across my attention: One <http://www.worddelights.com/wp-content/uploads/2013/07/developer-side-compa…> , Two <https://docs.google.com/spreadsheet/ccc?key=0Aqevw3Q-ErDUdFgzT3VNVXQxd095bF…> . Ask the Transifex team itself to tell us how they compare to the other platforms on all key areas. Cover solutions like Pootle which are developed in a very open matter. Put in a spreadsheet and compare thoroughly. This is responsible project management 101. *ZANATA* Those who have been around a while saw the Zanata push from the Red Hat teams coming with mathematical precision. Even when Transifex was being fully developed as open source, Red Hat decided to develop Zanata in parallel instead of investing in Transifex. This has always struck me as mind-boggling, given that Transifex was born in Fedora's arms and quickly became the most popular open-source localization platform. It is all in good spirit and competition is good. I am holding no grudge against Zanata. In fact, the Zanata team's efforts to grab Fedora in the past has pushed Tx to innovate fast. Having said this... In terms of Freedom, out of all the localization platforms out there, and given what I've seen the past years, Zanata is developed in one of the least open ways. Which open-source projects are using Zanata? On zanata.org I can see a bunch of test projects, a few Red Hat documentation ones and JBoss <https://translate.jboss.org/> (also Red Hat's). Which other projects have installed their own Zanata server and how many words are they translating? *Pootle is a much more openly developed and widely accepted platform*. The leads (Dwayne and Friedel) are true open-sourcers, their team is presenting in many major open-source conferences, they're trusted by many large open-source projects <http://translate.sourceforge.net/wiki/pootle/live_servers> (Mozilla, Open Office), proprietary ones (Evernote, Grooveshark, Rdio) and their feature list <http://pootle.translatehouse.org/discover.html> is amazing. At FOSDEM I'll go out for drinks with Friedel. When there are tools like Pootle out there, why on Earth would Fedora even consider Zanata? *Where is the research and comparison between the options we have?* *TRANSIFEX* Transifex has 20+ people working full-time on the platform. A big chunk of our time is invested on open-source, community projects <https://www.transifex.com/customers/open-source/>. There are projects on Tx with as many as 1 Billion words being translated by 14.000 people. Joomla <https://www.dropbox.com/s/tnaypyaylxnausr/Screenshot%202014-07-17%2013.11.5…> has 2.7K translators contributing on 250 projects. If the goal is to have a *vibrant and successful Fedora Localization Project*, then there are so many things to be done which make the "which tool" discussion, quite frankly, stupid. Here are a couple: - Use Transifex's Reports <https://www.dropbox.com/s/o4htl010ieo38iw/Screenshot%202014-07-17%2012.40.1…> to constantly recognize our most active translators. Send them a t-shirt or even simply mention them in the release notes. - Nurture teams <https://www.dropbox.com/s/3dtubts36oxhk1q/Screenshot%202014-07-17%2012.46.3…> by identifying inactive members and refreshing them. - Help community members prioritize <https://www.dropbox.com/s/5xbmbc2m1elmcva/Screenshot%202014-07-17%2012.49.2…> which projects to translate first and remove old content. Do we want a successful community L10n project? These are the things we should be discussing. And these are some of the things the Transifex team is investing on. "What does the roadmap look like" is a key question for the research on which tool to choose (which never happened). *ENDING THOUGHTS* As a Fedora contributor, I'm expecting a discussion for such an important topic to have higher responsibility than the one I've seen so far. This is an extremely important topic which has no place for hastiness or egos. I'd be happy to help and wear my Fedora hat. -d -- Dimitris Glezos Founder & CEO, Transifex https://www.transifex.com/

1 0

mirroring for alternative content
by Colin Walters 18 Jul '14

18 Jul '14

Hi, We have several forms of non-Koji internal builds: 1) COPR (the most visible) 2) http://alt.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/ (this could be a COPR) 3) rpm-ostree: http://rpm-ostree.cloud.fedoraproject.org/#/ Now, I recently was allocated a new atomic01.qa.fedoraproject.org server dedicated to rpm-ostree composes, and I'm happy to announce I now have it composing trees: fedora-atomic/rawhide/x86_64/server/docker-host => 175510ab77ef39ec6000db2745c70444d55957e38c5ff28f890237e1f012ea5e fedora-atomic/rawhide/x86_64/workstation/gnome/core => b6f3f3b53ef957c71e8d8bdc36c35519888d4177bf6a582ba37e33416ff84216 But it's on the QA network, and so I can't just serve the content directly from it. Nor would I want to have the compose server doing double duty as a static webserver anyways. I could just rsync this content to the current rpm-ostree.cloud.fedoraproject.org, but there are a few issues with that: 1) It's a one off instance in the fedora cloud with no backup/monitoring 2) No redundancy 3) No tuning for static webserving 4) Most critically, no TLS COPR only relatively recently gained TLS, which is fundamentally necessary for retrieving arbitrary executable code that runs as root. But COPR also (from what I understand from <puiterwijk>) is just one machine. What do you think about investing in having e.g. altcdn.fedoraproject.org be a load-balanced static webserver farm protected by TLS that could be written to by a trusted subset of non-Koji build/compose tooling? "altcdn" is the first thing that came to mind offhand for a name, feel free to pick others =) We'd need to determine the writing process; could be rsync-over-ssh access to specific subdirectories gated by ssh key? Something else?

2 5

Transifex has become proprietary
by Rahul Sundaram 18 Jul '14

18 Jul '14

Hi Unfortunately it looks like Transifex has become proprietary and Fedora moving to using Transifex.com has been cited as one of the reasons why it wasn't important anymore for them to maintain a open source version. https://github.com/transifex/transifex/issues/206#issuecomment-15243207 Should we consider alternatives? Rahul

21 36

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure July 2014