Fwd: Annoucing Fedora Developer Portal mailing list
by Nick Coghlan
Developer portal update that's potentially of interest to folks here :)
Cheers,
Nick.
---------- Forwarded message ----------
From: Petr Hracek <phracek(a)redhat.com>
Date: Fri, Feb 19, 2016 at 6:23 PM
Subject: Annoucing Fedora Developer Portal mailing list
Hi folks,
I am glad to announce, Fedora Developer Portal has official
mailing list.
developer-portal(a)lists.fedoraproject.org
If you want to discuss anything about the portal, feel free to send us
any feedback,
suggestions, etc. Or even file a n issue on GitHub.
In the most time you can reach us on IRC *freenode*, channel
*#developer-portal*.
Soon, we would like to inform you about the progress and what we plan
for next round.
Portal is located on GitHub [1].
As website [2] as content [3].
[1] https://github.com/developer-portal
[2] https://github.com/developer-portal/website
[3] https://github.com/developer-portal/content
--
Petr Hracek
Software Engineer
Developer Experience
Red Hat, Inc
Mob: +420777056169
email: phracek(a)redhat.com
--
Nick Coghlan
Fedora Environments & Stacks
Red Hat Developer Experience, Brisbane
Software Development Workflow Designer & Process Architect
8 years, 2 months
- 3
- 2
Containers: we're asking for ponies, so here's a suggestion for the
Minimum Viable (Modular) Pony Show
by Matthew Miller
At DevConf.cz, I said that 2016 needed to be the year of the _show_
part of "show & tell" for what we started with the "rings" proposal and
now what we're calling, vaguely, "modularity".
Some of that is scary, because anything really new always is. It's
important that we do this in a way that *both* brings useful new
functionality _and_ doesn't break what we have.
In the commercial world, there's a concept of "minimum viable product" --
not done, not perfect, but what it takes to actually start solving problems
and providing value. In Fedora, we're not in business in the same way, but
some of the same can apply. So, here's my suggestions for a "minimum viable
demo" for what a container-based module might look like in Fedora.
Particularly, when I've spoken to people about delivering parts of Fedora as
containers, the part about tracking security and proving updates becames
disturbingly hand-wavy, with "yeah, of course, we'll do something to cover
that". I think to be successful, we need to make sure that this is addressed
early. So, this proposal for a demo I'd like to see.
I've broken it down into three parts of increasing complexity and
usefulness: starting with "and I want a pony", then moving up to "actually,
a unicorn", and then "also, could you put wings on that?"
So, first:
The Minimum Viable Pony
-----------------------
This is a basic web server module delivered as a container.
Part A: the basic module:
* Answers on port 80 and serves out static web pages.
* Content comes from /var/www/html... or another container, or whatever.
* Doesn't even need to be configurable. It's a demo.
* It's composed entirely from RPMs already existing in Fedora.
Part B: DNF Plugin to list CVEs
* Works like https://docs.fedoraproject.org/en-US/Fedora/17/html/Security_Guide/sect-S...
- lists all RPMs on host system where a security update is available
- can list by CVE
- also by Bugzilla
- also with link to update notice
- with various breakdowns by severity level
- **additionally** lists "modules" which need updates (with same links)
- has option to list which specific RPMs within the module have the
problem.
So that's a good start. As a sysadmin, I'm feeling a little less scared
about. But we also need...
To Take It to Unicorn Level
---------------------------
It's all well and good to fix the problem, but we also need to be able to
fix it. So, the next level is:
* Image is built in Fedora's new Layered Image Build Service
https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
* If there is a security vulnerability in any RPM that is in the image, it
is automatically rebuilt and made available somewhere.
* And automatically tested!
- Here, just a basic test that makes sure that input web content comes
out. It's a proof-of-concept so no real in-depth testing is needed.
* And, then, a dnf plugin which actually downloads and applies the update.
Now, not only do we have comforting tooling (minimizing change pain), we
also have a real, practical improvement (there will be cake!). In the
current system, while we do hands-on testing of individual updates, they
aren't necessarily tested in the application to which they apply. For
example, if the web server here is Nginx and the security flaw in the SSL
library, current update testing does not guarantee that the update has been
tested *for that use*. But this will. Plus, in addition to whatever human
oversight, there will be an _automatic_ test.
So that's pretty good. But finally, to get to the glorious future, I'd also
like to see this unicorn become also a pegasus (my daughter tells me that
this makes it an "alicorn")...
Taking Flight
-------------
Same as above, but with two new things:
New Thing One:
* Instead of RPMs, a module which uses some non-RPM upstream packaging
format as part of its composition
- Ruby gem, Python egg or wheel, Java jar... whatever
* And the DNF list-security command still works
- and the verbose flag now tells us about the CVEs or whatever for the
non-RPM package
New Thing Two:
* There is enough metadata and intelligence such that when the new
container is updated, that update happens without downtime. This may
involve multiple containers.
* If the update fails locally for some reason (despite the best efforts at
upstream testing), it's rolled back automatically
From here, I can imagine all sorts of other mythical creatures. But, you
know, for a start. What do you think?
As a user/sysadmin, is there something more you'd like to see? If
you're skeptical about containers, would this make you feel better? If
not, what might?
If you're excited about them, does this seem like a useful start?
What's missing?
And, of course, if you're a developer working on this stuff, can I have
ponies please?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8 years, 2 months
- 2
- 7
- ← Newer
- 1
- Older →