[atomic-wg] Issue #252 `Fix rawhide ISO`
by Colin Walters
walters reported a new issue against the project: `atomic-wg` that you are following:
``
https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/...
```
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/pylorax/ltmpl.py", line 56, in parse
textbuf = template.render(**variables)
File "/usr/lib/python3.6/site-packages/mako/template.py", line 462, in render
return runtime._render(self, self.callable_, args, data)
File "/usr/lib/python3.6/site-packages/mako/runtime.py", line 838, in _render
**_kwargs_for_callable(callable_, data))
File "/usr/lib/python3.6/site-packages/mako/runtime.py", line 873, in _render_context
_exec_template(inherit, lclcontext, args=args, kwargs=kwargs)
File "/usr/lib/python3.6/site-packages/mako/runtime.py", line 899, in _exec_template
callable_(context, *args, **kwargs)
TypeError: render_body() missing 1 required positional argument: 'root'
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/252
6 years, 11 months
[atomic-wg] Issue #181 `Vagrant cannot create synced folder`
by Pagure
jorti reported a new issue against the project: `atomic-wg` that you are following:
``
I just launch an unmodified fedora/25-atomic-host box and I get the error that it cannot create the /vagrant synced dir.
```
$ vagrant up
Bringing machine 'default' up with 'libvirt' provider...
==> default: Creating image (snapshot of base box volume).
==> default: Creating domain with the following settings...
==> default: -- Name: mail-server_default
==> default: -- Domain type: kvm
==> default: -- Cpus: 1
==> default: -- Memory: 512M
==> default: -- Management MAC:
==> default: -- Loader:
==> default: -- Base box: fedora/25-atomic-host
==> default: -- Storage pool: default
==> default: -- Image:
/var/lib/libvirt/images/mail-server_default.img (41G)
==> default: -- Volume Cache: default
==> default: -- Kernel:
==> default: -- Initrd:
==> default: -- Graphics Type: vnc
==> default: -- Graphics Port: 5900
==> default: -- Graphics IP: 127.0.0.1
==> default: -- Graphics Password: Not defined
==> default: -- Video Type: cirrus
==> default: -- Video VRAM: 9216
==> default: -- Keymap: en-us
==> default: -- TPM Path:
==> default: -- INPUT: type=mouse, bus=ps2
==> default: -- Command line :
==> default: Creating shared folders metadata...
==> default: Starting domain.
==> default: Waiting for domain to get an IP address...
==> default: Waiting for SSH to become available...
default:
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Configuring and enabling network interfaces...
==> default: Rsyncing folder: /home/juan/Vagrant/mail-server/ => /vagrant
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
mkdir -p /vagrant
Stdout from the command:
Stderr from the command:
mkdir: cannot create directory ‘/vagrant’: Operation not permitted
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/181
6 years, 11 months
[atomic-wg] Issue #243 `Require DESCRIPTION label for FLIBS containers`
by Josh Berkus
jberkus reported a new issue against the project: `atomic-wg` that you are following:
``
We should require a "description" label in FLIBS containers. This would contain a long, narrative description of the container and how it's supposed to be used, intended for human readability. This would include, for all containers:
* what service/software the container provides
It would also include all of the following which are applicable to the container:
* what purpose it fulfills in a larger infrastructure
* what each VOLUME in the container is for and what kinds of storage they need
* any details about dependencies on other container images
* links to documentation or software project pages
* any special requirements the container has (like lots of RAM, or sound server access)
* details on any required configuration, or links to documentation on configuration
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/243
7 years
Atomic openQA result emails ('compose check report')
by Adam Williamson
Hi folks!
So Colin and I had a bit of a chat about openQA Atomic testing
'integration', and one of the things that came up was the state of the
'compose check report' emails for Atomic tests.
If you're signed up to test@ or devel@ you may have noticed that a
'compose check report' mail is sent out for every mainline Fedora
compose openQA tests, with info on the numbers of passed and failed
tests and some other stuff.
When we set up openQA to test the Atomic Host OStree installer image
and to test the nightly 'two-week Atomic' composes, I asked whether we
should generate those mails, and who they should go to.
The answer I got - and the way it's configured right now - was that
people only wanted the mails produced when a test *failed*, and they
should be mailed to this list plus to one person directly (I think at
first it was Adam Miller, it now seems to be Mike McGrath).
I've just verified that this is actually working: when openQA tests the
'two-week Atomic' composes and a failure occurs, the mail does get
sent. However, there hasn't been a failure of the test since - AFAICS -
2016-10-01. So that's why no such mails have been sent out recently. I
got Mike to check, and he actually did get a mail on 20167-10-01, when
the test last failed.
I think the mails that have been sent to cloud@ were never approved
through moderation, so they never actually appeared here. It'd be good
if a list moderator could check if they see a few 'compose check' mails
hung up in moderation, or something.
So, I just wanted to give a quick heads-up on that, and say that if
anyone would like that configuration changed, I can do it easily
enough. We could have a report generated for every compose as for the
'main' composes, but it'd be quite dull I think, because there's only
one test and it almost always passes. We can also change the list of
addresses that receive the mails when they're sent, if it should be
changed.
Also do let me know if running more tests on the Atomic installer image
would be desirable. For now we just run a single test - a straight-
through install test on x86_64 BIOS - since that's all I was asked for
initially. We could run the same test on UEFI, if desired, and we could
run some of the post-install tests that are run on other images, and we
could run some of the install variant tests; I just don't know which
ones are relevant / useful for the Atomic installer image.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7 years
[atomic-wg] Issue #196 `moving to docker 1.13 in Fedora 25`
by Pagure
dustymabe reported a new issue against the project: `atomic-wg` that you are following:
``
In the meeting today @runcom brought up the topic of:
- removing docker-latest in Fedora (mail thread on that [here](https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-January/msg00037.html))
- moving to docker 1.13 (just released) in Fedora 25
There are some concerns over moving to docker 1.13 but we believe that if we are able to qualify it enough it would be beneficial to go to the latest version so that @runcom doesn't have to manage so many versions of docker. The current proposal is:
- first, wait 4 weeks
- let some bugs from initial release work itself out
- many of us are traveling over the next few weeks anyway so this won't hurt
- 2nd, put out update to updates-testing and wait some time for thorough tests to be conducted on the testing ostree.
- If there are big issues with 1.13 that don't have a ready fix (performance issues, complicated issues that don't have fixes) then we can unpush 1.13 from updates-testing and put out security fixes etc for 1.12. We'd like to not have to unpush if possible though.
Another thing that might be useful is a condensed list of changes from 1.12 to 1.13. @runcom, could you provide us with that information?
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/196
7 years
[atomic-wg] Issue #234 `Container guidelines for containers with volumes`
by James Hogarth
jhogarth reported a new issue against the project: `atomic-wg` that you are following:
``
To protect persistent data it's common to use a VOLUME in the Dockerfile to automatically generate and mount a volume for the container on the host.
Best practice when running these containers should be to used a named volume at that point to ensure persistent when the container is updated.
If VOLUME is not in the Dockerfile then there is a risk of data loss on container updates with an admin not paying attention to which data should be persistent.
I'd suggest we should allow VOLUME in the guidelines for the container maintainer to be clear what is considered important data that must be persisted but we should have a way of making it clear what should be declared at runtime.
An example would be the owncloud container review request which makes the httpd and owncloud configuration directories volumes for persistence and allow customisation, and makes the owncloud data directory a volume to prevent data loss.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/234
7 years
[atomic-wg] Issue #199 `Plan for Atomic prerelease images`
by Robert Mayr
robyduck reported a new issue against the project: `atomic-wg` that you are following:
``
With F25 Atomic replaced definitely Cloud as Fedora edition, and is now the only "cloud" set on getfedora.org.
Until F25 there was never any plan to produce prerelease images (Alpha/Beta), but now, as it is an edition, websites need to know if cloud-wg wants to change that and produce 2-week prerelease images. Alpha freeze is at the end of February and Alpha will be released at 2017-03-14.
https://fedoraproject.org/wiki/Releases/26/Schedule
The earlier we know your plan the better, because actually we do not have any line coded for a new prerelease page.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/199
7 years
[atomic-wg] Issue #254 `Label/comment for primary RPM?`
by Josh Berkus
jberkus reported a new issue against the project: `atomic-wg` that you are following:
``
In the 3/10/2017 VFAD, we decided that VERSION would be 0 pending updating FLIBS to support automatically pulling the version from the "primary RPM" in the container.
However, we are not currently collecting information from maintainers about which RPM is the primary one.
Should we have a label or structured comment, required, which contains this information?
Ref #235
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/254
7 years