Meeting about rolling releases
by Josh Berkus
Folks,
For anyone who's interested, we'll be having a meeting about Rolling
Releases (vs. versioned releases). This is just to get some face-time
for the discussion of how rolling releases would work, what they mean,
and when we'll be ready to deploy them (if ever).
Friday, March 17th, 1pm EDT / 17:00 UTC.
http://bluejeans.com/8169971214
Dial-in:
+1 800 451 8679
+1 212 729 5016
meeting #8169971214
--
--
Josh Berkus
Project Atomic
Red Hat OSAS
7 years, 1 month
[atomic-wg] Issue #231 `clarify meaning of "rolling" for future fedora
atomic releases`
by Jason Brooks
jasonbrooks reported a new issue against the project: `atomic-wg` that you are following:
``
The Atomic WG has unofficially paid attention to only a single fedora atomic release at a time, specifically, the release based on the current latest stable Fedora release. There's a proposal to formalize this in [issue 228](https://pagure.io/atomic-wg/issue/228).
In the discussion around this issue, @jberkus asked why, if we are to support only a single fedora atomic release at a time, do we not adopt a "rolling" release structure for fedora atomic, where the tree served from the fedora atomic ostree repo is always composed from the current latest stable Fedora release.
In response, @dustymabe suggested that "rolling" could mean many different things, and that we should discuss these many meanings in a future VFAD.
In this issue, we can collect some thoughts on what "rolling" means in advance of this VFAD.
To me, a rolling fedora would match up with what rhel and centos atomic do. There's a single repo, and an upgrade from rhel atomic 7.1 to 7.2 to 7.3, etc. simply involves runnning `atomic host upgrade`. The same would apply to fedora for 25 to 26 to 27, etc.
Currently, fedora users are expected to rebase each six months, in the same way that they might rebase between completely separate streams, such as from fedora atomic to centos atomic.
So, upgrades, today:
```
$ sudo ostree remote delete fedora-atomic
$ sudo ostree remote add fedora-atomic --set=gpg-verify=false $ https://dl.fedoraproject.org/pub/fedora/linux/atomic/25
$ sudo rpm-ostree rebase fedora-atomic:fedora-atomic/25/x86_64/docker-host
$ sudo systemctl reboot
```
Upgrades, in a "rolling" world:
```
$ sudo atomic host upgrade
$ sudo systemctl reboot
```
This would have zero impact on the current two-week release scheme. Just as we tried to release fedora atomic 24 every two weeks up until fedora 25 release day, when we shifted to trying to release fedora atomic 25 every two weeks, and stopped paying attention to the 24 stream, we would, at some future point, be releasing fedora atomic every two weeks based on f2N rpms, switch over to the f2N+1 rpms on or near release day, and proceed from there.
The only difference is convenience and clarity for our users.
Before Dusty cited the many meanings of "rolling" I hadn't even considered additional meanings, but maybe we can list some of those here in preparation for the VFAD.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/231
7 years, 1 month
[atomic-wg] Issue #256 `atomic command changes: prefer file over label`
by Tomas Tomecek
ttomecek added a new comment to an issue you are following:
``
@baude thanks for feedback!
From the blog post:
This file will be submitted with the image proposal, and will be included
bout inside the container image and available online from
fedoraproject.org. The Help label will link to that URL.
Would it be okay then if the `HELP` label looked like this?
```
LABEL HELP="curl -s http://pkgs.fedoraproject.org/cgit/docker/cockpit.git/plain/README.md?h=f25"
```
This way the definition of the `HELP` label will be kept and the solution also satisfies the requirement.
Regarding text content:
```
Images that need very little documentation (like libraries) will have that in the Help label as text.
```
I'm in favor of moving such documentation to a different label. `description` fits well:
```
Name | Required | Description
--------------------------------------------------------------
description | no | Detailed description of the image
```
@jberkus @dustymabe @maxamillion @baude are you okay with this?
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/256
7 years, 1 month
[atomic-wg] Issue #256 `atomic command changes: prefer file over label`
by Brent Baude
baude added a new comment to an issue you are following:
``
The https://github.com/projectatomic/ContainerApplicationGenericLabels definition of the HELP label for images is defined as "Command to run the help command of the image". The way Atomic CLI help was designed was as follows:
* If a HELP label exists, execute the command in the label.
* If a HELP label does not exist, look for a /help.1 file and display it using groff.
Again, this is because the HELP label was defined to allow users to have an alternate way to display help including a simple cat of a file that says "For more information about this image go to http://foobar/help"
That said, I think the general idea of allowing more types of help formats is a good thing and I would be very supportive of that. The thing I object to in the proposal is where it is suggested that for images with very little help, they should put the help text in the label itself. I don't like this use case because it is not in line with the label definition. We could change the label definition as one thought. Or we could use a label like HELP_TEXT or HELP_SHORT for that use case.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/256
7 years, 1 month
[atomic-wg] Issue #245 `add DEPENDS label for FLIBS containers`
by Josh Berkus
jberkus reported a new issue against the project: `atomic-wg` that you are following:
``
add a "depends" label for for containers submitted to FLIBS. This label would be populated with a human-readable description of the other containers (or host services) required to make this container work, e.g.
"depends" : "PostgreSQL or MySQL database"
this label would not be required if there are no dependencies. It would eventually be replaced by dependency labeling mandated by Fedora Modularity, once that team figures out dependency labeling. But for now, having human-readable dependencies listed is better than having nothing.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/245
7 years, 1 month
[atomic-wg] Issue #256 `atomic command changes: prefer file over label`
by Tomas Tomecek
ttomecek added a new comment to an issue you are following:
``
@jberkus Josh, after reading your [blog post](http://www.projectatomic.io/blog/2017/03/fedora-vfad-container-policy/) I don't feel like I'm comfortable with `help1.txt`. Right now `atomic` expects man-formatted file named `help.1`, so I would like the list of expected filenames to be:
```
help.1
README
README.md
```
What do you think?
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/256
7 years, 1 month
