2014-07-21 Fedora Atomic Infrastructure Meeting - Minutes
by Brian Proffitt
==============================
#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.0...
.
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/r...
(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
9 years, 9 months
Agenda for today's meeting on Atomic
by Joe Brockmeier
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/
9 years, 9 months
Fedora Atomic Infrastructure Meeting: July 21, 2014
by Brian Proffitt
==============================
#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.0...
.
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/r...
(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
9 years, 9 months
ask fedora -- closing questions because they're answered?
by Matthew Miller
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-po...
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
9 years, 9 months
Atomic Status / Fedora Infra discussion
by Joe Brockmeier
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
9 years, 9 months
Atomic status
by Colin Walters
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?
9 years, 9 months
Fwd: On Fedora's Localization platform
by Dimitris Glezos
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-com...>
, Two
<https://docs.google.com/spreadsheet/ccc?key=0Aqevw3Q-ErDUdFgzT3VNVXQxd095...>
.
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...>
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...>
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...>
by identifying inactive members and refreshing them.
- Help community members prioritize
<https://www.dropbox.com/s/5xbmbc2m1elmcva/Screenshot%202014-07-17%2012.49...>
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/
9 years, 9 months
mirroring for alternative content
by Colin Walters
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?
9 years, 9 months
