[atomic-wg] Issue #308: enable --tsflags=nodocs for all base images by
default
by Tomas Tomecek
ttomecek reported a new issue against the project: `atomic-wg` that you are following:
``
@ignatenkobrain had an interesting idea this morning on IRC: what if all our docker base images had `--tsflags=nodocs` enabled on by default? This could be easily achieved by changing the configuration in `/etc/dnf/dnf.conf`.
I'm very much interested in your opinion. I personally like it and am all for it.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/308
6 years, 9 months
Meeting item for 20170802: Atomic Host + Modularity - Enabling CI/CD
by Dusty Mabe
Recently we talked about adding more CI/CD to the Atomic Host
processes. Since we release every two weeks we'd like to automatically
run tests on every change that goes in to Atomic Host and prevent
it from going into Atomic Host if it causes test failures.
This was suggested to the Atomic Working Group from the new CI Working
Group [1] in the 2017-07-12 meeting [2]. Stef, from the CI working
group also sent a mail to the cloud list about it [3].
Here are some of the things we want to be able to do:
1 Have a rigorous definition (including specific versions, buildroot) of
what goes into an Atomic Host, including dependencies.
2 Triggering the CI/CD pipeline based on a change to definition
of what goes into Atomic Host.
3 A way to revert a package in the Atomic Host compose to an earlier version.
4 A place to store higher level tests along with rigorous definition
of Atomic Host, including them being versioned.
5 Landing multiple changes that need to land together to pass testing.
Out of that list we think we require that:
1R The definition of what is composed into Atomic Host artifacts should
include specific versions of packages, and all dependencies included.
2R The definition of what is composed in an Atomic Host should be stored
in a git repository so that changes can be detected easily. The
CI/CD pipeline can be triggered off of changes to this reposiroty.
3R A mechanism to make a future composed Atomic Host artifact, contain
an earlier (in RPM NVR parlance) version of a package.
4R The high level functional Atomic Host tests should live in the same
git repository with the rigorous definition of what goes into an Atomic
Host.
5R A mechanism to tell the CI Pipeline that multiple dist-git repository
changes (i.e. multiple changing RPMs) should be built and tested together.
We believe that moving to an Atomic Host defined by a module [4] can
satisfy our needs and enable the improved control of artifacts within
Atomic Host as well as the improved triggering and coupling with a
testing pipeline that will help us move forward. Since modularity is new
this will take some experimentation to prove out. Let's chat about this
in the Atomic Working Group meeting today at 1700UTC in #fedora-meeting-1.
Dusty
[1] https://fedoraproject.org/wiki/CI
[2] https://meetbot.fedoraproject.org/fedora-meeting-1/2017-07-12/fedora_atom...
[3] https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.o...
[4] https://docs.pagure.org/modularity/
6 years, 9 months
Atomic WG Meeting Minutes 2017-08-02
by Sinny Kumari
full log: https://meetbot.fedoraproject.org/fedora-meeting-1/2017-08-02/fedora_atom...
===================================
#fedora-meeting-1: fedora_atomic_wg
===================================
Meeting started by ksinny at 17:00:09 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2017-08-02/fedora_atom...
.
Meeting summary
---------------
* Roll Call (ksinny, 17:00:26)
* kube-sig ticket about versions discussion
https://pagure.io/atomic/kubernetes-sig/issue/6 (jbrooks, 17:05:22)
* jberkus wrote a blog post on the irc/list changes for pa.io and is
working on getting a blog out on the fedora comm blog
http://www.projectatomic.io/blog/2017/07/changes-to-fah-mailing-lists/
(dustymabe, 17:06:07)
* dusty wrote a comprehensive blog post on upgrading f25->f26 atomic
host - it got merged but has not yet posted to the pa.io/blog:
https://github.com/projectatomic/atomic-site/pull/458 (dustymabe,
17:07:00)
* dusty communicated about the ref issue in atomic host
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-J...
(dustymabe, 17:07:50)
* ACTION: dustymabe to create ticket to track RFE for rawhide based
containers to be made available from registry.fedoraproject.org
(dustymabe, 17:08:22)
* ACTION: jberkus strigazi to continue moving kube issues to new
kube-sig tracker (ksinny, 17:09:51)
* dustymabe jberkus came up with etherpad for us to use during the
VFAD http://etherpad.osuosl.org/fedora_atomic_docs_vfad (dustymabe,
17:10:23)
* experiment with modularity (dustymabe, 17:12:27)
* LINK:
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-A...
(dustymabe, 17:12:47)
* LINK:
https://gist.github.com/cgwalters/c69bf2091eab7c1af316d0d7dd41f530
(walters, 17:14:50)
* ACTION: jbrooks dustymabe to come up with list of questions for
modularity folks and invite them to our atomic weekly meeting in 1
or 2 weeks (dustymabe, 17:31:23)
* ACTION: dustymabe to create a ticket for experimenting with
modularity - where we can track progress on an atomic host module
POC (dustymabe, 17:34:09)
* ACTION: dustymabe to create a ticket for questions for them for us
to curate with a meeting tag (dustymabe, 17:34:21)
* Open Floor (ksinny, 17:36:53)
* status of building Atomic cloudimages on multi-arches (ksinny,
17:38:08)
* LINK: https://pagure.io/atomic-wg/issue/299 (ksinny, 17:38:13)
* LINK:
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-A...
(dustymabe, 17:55:46)
* LINK: https://pagure.io/atomic-wg/issue/306 (dustymabe, 17:55:52)
* LINK: http://lkml.iu.edu/hypermail/linux/kernel/1608.0/04662.html
the pull request in question (Drakonis_, 17:57:29)
* btrfs discussions for atomic host in
https://pagure.io/atomic-wg/issue/306 (dustymabe, 17:59:02)
Meeting ended at 18:00:08 UTC.
Action Items
------------
* dustymabe to create ticket to track RFE for rawhide based containers
to be made available from registry.fedoraproject.org
* jberkus strigazi to continue moving kube issues to new kube-sig
tracker
* jbrooks dustymabe to come up with list of questions for modularity
folks and invite them to our atomic weekly meeting in 1 or 2 weeks
* dustymabe to create a ticket for experimenting with modularity - where
we can track progress on an atomic host module POC
* dustymabe to create a ticket for questions for them for us to curate
with a meeting tag
Action Items, by person
-----------------------
* dustymabe
* dustymabe to create ticket to track RFE for rawhide based containers
to be made available from registry.fedoraproject.org
* jbrooks dustymabe to come up with list of questions for modularity
folks and invite them to our atomic weekly meeting in 1 or 2 weeks
* dustymabe to create a ticket for experimenting with modularity -
where we can track progress on an atomic host module POC
* dustymabe to create a ticket for questions for them for us to curate
with a meeting tag
* jbrooks
* jbrooks dustymabe to come up with list of questions for modularity
folks and invite them to our atomic weekly meeting in 1 or 2 weeks
* **UNASSIGNED**
* jberkus strigazi to continue moving kube issues to new kube-sig
tracker
People Present (lines said)
---------------------------
* dustymabe (127)
* ksinny (47)
* jbrooks (46)
* zodbot (19)
* maxamillion (16)
* walters (15)
* roshi (14)
* Drakonis_ (10)
* _ari_ (2)
* scollier (2)
* sayan (2)
* miabbott (1)
* pbrobinson (1)
6 years, 9 months
[atomic-wg] Issue #299: Concerns related to enabling Atomic Host CloudImages
compose in Rawhide for multi-arches
by Sinny Kumari
sinnykumari added a new comment to an issue you are following:
``
>
> In what context? If you mean building and booting FAH cloudImage (qcow2) in rawhide, then x86_64 already exist in nightly compose. Other than that, I have tried on ppc64le locally and it should work once initial issues mentioned in this ticket get resolved.
>
> I just mean, what all architectures work? You have overcome issues with aarch64 so we know that x86_64 and aarch64 work (with fixes)? What else works/doesn't work?
x86_64, aarch64 and ppc64le works with issues fixed from this ticket. Haven't tried any other arches.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/299
6 years, 9 months
[atomic-wg] Issue #299: Concerns related to enabling Atomic Host CloudImages
compose in Rawhide for multi-arches
by Sinny Kumari
sinnykumari added a new comment to an issue you are following:
``
>
> Update:
> I have succeeded in creating FAH CloudImage on aarch64 using imagefactory on local machine. Image gets generated successfully when we use reqpart in fedora-atomic kickstart file.
> There are two issues while booting generated cloudImage on aarch64:
> 1. "can't find command linuxefi, can't find command initrdefi" . Modifying kernel boot parameter from linuxefi to linux and initrdefi to initrd fixes this problem. This problem has been fixed here https://github.com/ostreedev/ostree/pull/1021 .
>
> sweet - are we testing this with rawhide or f26?
In rawhide
> After changes made as stated in 1st issue, booting gets stuck with following messages:
> EFI stub: Booting Linux Kernel...
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> It seems to be a problem with console option passed in fedora-atomic kickstart file at https://pagure.io/fedora-kickstarts/blob/master/f/fedora-atomic.ks#_20 . It seems, arm devices uses console=ttyAMA0. Either adding console=ttyAMA0 in line#20 or removing console=tty1 console=ttyS0,115200n8 fixes the problem.
>
>
> I wish i would have known you were debugging this :) - I hit this same problem a few months ago: https://twitter.com/dustymabe/status/867225301985755137. I guess we need to find a way to specify that to just the aarch64 images.
Yeah! I started debugging around 2 weeks back on aarch64, just after getting ppc64le issues sorted out (mentioned in the main ticket)
> With above two problem fixed, aarch64 image boots successfully.
>
> 🎉 have we tried with any other architectures?
In what context? If you mean building and booting FAH cloudImage (qcow2) in rawhide, then x86_64 already exist in nightly compose. Other than that, I have tried on ppc64le locally and it should work once initial issues mentioned in this ticket get resolved.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/299
6 years, 9 months