Re: Fedora Rawhide-20170227.n.0 compose check report
by Adam Williamson
On Mon, 2017-02-27 at 17:25 +0000, Fedora compose checker wrote:
> Missing expected images:
>
> Atomic qcow2 x86_64
There seems to be some sort of problem in pungi-make-ostree:
https://kojipkgs.fedoraproject.org//work/tasks/1386/18091386/root.log
DEBUG util.py:435: + pungi-make-ostree tree --repo=/mnt/koji/compose/atomic/rawhide/ --log-dir=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/logs/x86_64/Atomic/ostree-2 --treefile=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/work/ostree-2/config_repo/fedora-atomic-docker-host.json --extra-config=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/work/ostree-2/extra_config.json
DEBUG util.py:435: Traceback (most recent call last):
DEBUG util.py:435: File "/usr/bin/pungi-make-ostree", line 15, in <module>
DEBUG util.py:435: ostree.main()
DEBUG util.py:435: File "/usr/lib/python2.7/site-packages/pungi/ostree/__init__.py", line 85, in main
DEBUG util.py:435: func()
DEBUG util.py:435: File "/usr/lib/python2.7/site-packages/pungi/ostree/tree.py", line 95, in run
DEBUG util.py:435: repos = extra_source_repos + [{'name': 'source_repo_from', 'baseurl': source_repo_from}]
DEBUG util.py:435: TypeError: unsupported operand type(s) for +: 'NoneType' and 'list'
> Server dvd i386
Several i386 image composes still failing for the reason Kevin noted
recently:
dnf.exceptions.Error: Will not install a source rpm package (docker-anaconda-addon-0.4-4.fc26.src).
> Xfce raw-xz armhfp
Looks a bit odd:
https://kojipkgs.fedoraproject.org//work/tasks/1563/18091563/root.log
DEBUG util.py:435: Unable to create appliance : Failed to find package 'firefox' : no package matched: firefox
Is there an ARM-specific issue with the firefox package?
> Server boot i386
> Atomic raw-xz x86_64
See above.
> Failed openQA tests: 10/107 (x86_64), 1/2 (arm)
>
> ID: 57880 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
> URL: https://openqa.fedoraproject.org/tests/57880
This is some kinda transient test fail, I think (openQA clicked in the
wrong place or the click got lost or something).
> ID: 57881 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
> URL: https://openqa.fedoraproject.org/tests/57881
This is now failing because of:
https://bugzilla.redhat.com/show_bug.cgi?id=1405790
freeipa-client and freeipa-server can't be installed due to dep issues
with certmonger, and certmonger rebuild is failing.
> ID: 57899 Test: x86_64 Workstation-live-iso desktop_terminal
> URL: https://openqa.fedoraproject.org/tests/57899
> ID: 57907 Test: x86_64 Workstation-live-iso desktop_update_graphical
> URL: https://openqa.fedoraproject.org/tests/57907
These two failed because gnome-color-manager unexpectedly asked for
access to the system location immediately upon login, which the test
can't cope with:
https://bugzilla.gnome.org/show_bug.cgi?id=779343
We could adjust the test, but the GNOME behaviour seems odd, so waiting
for input from the devs on whether it's a bug.
> ID: 57925 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload
> URL: https://openqa.fedoraproject.org/tests/57925
We never get any video output from this test, with a 10 minute (IIRC)
boot timeout. pwhalen reports there's a showstopper with ARM atm
related to module loading:
https://bugzilla.redhat.com/show_bug.cgi?id=1422634
that may be causing this, or it may be something else.
> ID: 57951 Test: x86_64 universal install_iscsi
> URL: https://openqa.fedoraproject.org/tests/57951
This broke between 20170208 and 20170214, my best guess at what
happened is in the new bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1427359
> ID: 57956 Test: x86_64 universal install_software_raid@uefi
> URL: https://openqa.fedoraproject.org/tests/57956
This is an openQA console typing fail (sigh, still happens
occasionally). Test actually worked fine.
> ID: 57978 Test: x86_64 universal install_cyrillic_language
> URL: https://openqa.fedoraproject.org/tests/57978
Still https://bugzilla.redhat.com/show_bug.cgi?id=1413813 . If that
doesn't get any attention soon I may have to make the test work around
it to cover the rest of the test case...
> ID: 57983 Test: x86_64 universal install_rescue_encrypted
> URL: https://openqa.fedoraproject.org/tests/57983
> ID: 57984 Test: x86_64 universal install_rescue_encrypted@uefi
> URL: https://openqa.fedoraproject.org/tests/57984
Still https://bugzilla.redhat.com/show_bug.cgi?id=1376638 . Looks like
there's now a PR to fix this, but it is not yet merged.
> ID: 57986 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall
> URL: https://openqa.fedoraproject.org/tests/57986
This is a hard fail caused by the same SELinux alert that causes all
the soft fails (see below). It's a hard fail because any AVC alert that
triggers a desktop notification on boot is a Final release criteria
violation.
> Soft failed openQA tests: 52/107 (x86_64)
> (Tests completed, but using a workaround for a known bug)
These are all caused by:
https://bugzilla.redhat.com/show_bug.cgi?id=1392161
it may strictly speaking have been best reported as a separate bug, but
basically there's an AVC that shows up on almost all installs,
something being denied 'mounton' action for /proc/mtrr .
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7 years, 1 month
Meeting with Openstack magnum team today
by Dusty Mabe
Spent the day chatting with a bunch of Fedora Atomic users today.
Some pain points that came out of todays discussions:
- kubernetes versions
* sometimes we have lagged behind upstream in Fedora and this has
caused some pain. They are on board with containerized
kubernetes as a solution to this problem.
- installing small operating system agents
* have some small agents that need to run as a daemon on the host
some solutions:
^ build own ostree - more maintenance
^ package layer - requires reboot
^ run in container - large containers for small agents
^ run as container that acutally bind mounts in host directories
` very small container with just the agent
` when container runs it bind mounts in software from the
host. i.e. using the hosts python stack. I don't know if
this will work but just thought of it as we were talking
today.
` i'm sure this may be a bad idea on several levels.
- pre-loading containers on system startup
* there is a need for being able to load containers on system
startup into the container runtime. I think jlebon already
worked on something like this maybe. Either way the idea is that
we have a service that looks in a certain directory in the
filesystem for container images and loads them into the runtime
on startup and then deletes those images (or not depending on
configuration). One could start a cloud image and mount a volume
that these images are already loaded into. One could crack open
the qcow and cp the files in, etc. Doesn't matter how they get
to the "pre-defined" location, we'll import them.
Dusty
7 years, 1 month
FYI - changed ostree ref for rawhide
by Dusty Mabe
The atomic WG had a discussion about ref naming for rawhide/f26 [1]
and decided to change from
`fedora-atomic/rawhide/x86_64/docker-host`
to
`fedora/rawhide/x86_64/atomic-host`
for the ref that we follow in the ostree repo. I just merged a PR [2]
that does this in the pagure/fedora-atomic repo. I believe there are
some other places that need to be updated in order to complete this
change. I'll try to track those down and make those changes as well.
Dusty
[1] https://pagure.io/atomic-wg/issue/198
[2] https://pagure.io/fedora-atomic/pull-request/54
7 years, 1 month
[atomic-wg] Issue #198 `move ostree ref to be "container-host"`
by Dusty Mabe
dustymabe added a new comment to an issue you are following:
``
> +1 for atomic-host.
> How do we inform the users? Can we provide some kind of link to the old name so that we don't break everything?
I think if we don't plan to keep the old name around forever then we should just go ahead and make an announcement about the change and have them change it when they switch from f25 to f26 rather than waiting longer. They'll have to do it eventually and I think keeping the old name around is probably more confusing than it's worth.
> We're also going to need to do a big search-and-replace on the docs.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/198
7 years, 1 month