Hi,
One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal.
Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community.
This process proposed here very closely maps to the Core CentOS Linux process.
I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help.
Regards
This is something I want very much - sign me up for alpha testing or even pre-alpha! ;-)
On Tue, Apr 14, 2015 at 4:22 AM, Karanbir Singh kbsingh@centos.org wrote:
Hi,
One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal.
Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community.
This process proposed here very closely maps to the Core CentOS Linux process.
I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help.
Regards
-- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 04/14/2015 04:52 PM, Karanbir Singh wrote:
Hi,
One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal.
Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community.
This process proposed here very closely maps to the Core CentOS Linux process.
I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help.
+1
I would like get involved in builds and testing.
What does `Source Drop` block means? Will it be a store of OSTree repositories as output of compose-server?
On 15/04/15 14:21, Navid Shaikh wrote:
I would like get involved in builds and testing.
excellent!
What does `Source Drop` block means? Will it be a store of OSTree repositories as output of compose-server?
Since this is the downstream build, the source drop in this case would be when the srpm sources show up at git.centos.org
but you raise a good question: once we have the image up, what ostree repo would this be pointing at ? Off the top of my head, I'd guess the ostree repo would just be the atomic definition in the composed images, and a nightly update to include updates released into the CentOS Linux distro. And then rebase on next release.
this way anyone, once onramped onto an atomic image, would just keep running an 'atomic update' to get new content and never need to rebase the image.
On Wed, Apr 15, 2015 at 12:37 PM, Karanbir Singh mail-lists@karan.org wrote:
On 15/04/15 14:21, Navid Shaikh wrote:
I would like get involved in builds and testing.
excellent!
Sign me up. My packer setup needs a workout anyway. And this is a good excuse for me to get jenkins up and running.
What does `Source Drop` block means? Will it be a store of OSTree repositories as output of compose-server?
Since this is the downstream build, the source drop in this case would be when the srpm sources show up at git.centos.org
but you raise a good question: once we have the image up, what ostree repo would this be pointing at ? Off the top of my head, I'd guess the ostree repo would just be the atomic definition in the composed images, and a nightly update to include updates released into the CentOS Linux distro. And then rebase on next release.
this way anyone, once onramped onto an atomic image, would just keep running an 'atomic update' to get new content and never need to rebase the image.
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 04/14/2015 06:22 AM, Karanbir Singh wrote:
Hi,
One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal.
Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community.
This process proposed here very closely maps to the Core CentOS Linux process.
I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help.
This looks good to me and I'm keen to assist.
As a starting point, I've put up a snapshot of the non-RPM metadata that is being used to generate the upstream Atomic content. It differs substantially from the current CentOS Atomic SIG content and will need at least some modification to be workable.
It's currently sitting in this directory and branch of my fork of the Atomic SIG repo:
https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapsho...
Prior to the full RPM source drop being available, I'd like to at least try some initial smoke test tree composes using the SIG content in CBS. I will attempt to start on this early next week.
I'd also be interested in getting plugged in on the CI/CD infrastructure side of things.
-Ian
Regards
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 17/04/15 14:16, Ian McLeod wrote:
On 04/14/2015 06:22 AM, Karanbir Singh wrote:
Hi,
One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal.
Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community.
This process proposed here very closely maps to the Core CentOS Linux process.
I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help.
This looks good to me and I'm keen to assist.
As a starting point, I've put up a snapshot of the non-RPM metadata that is being used to generate the upstream Atomic content. It differs substantially from the current CentOS Atomic SIG content and will need at least some modification to be workable.
It's currently sitting in this directory and branch of my fork of the Atomic SIG repo:
https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapsho...
Prior to the full RPM source drop being available, I'd like to at least try some initial smoke test tree composes using the SIG content in CBS. I will attempt to start on this early next week.
I believe the srpm content is at git.c.o already - we can get cracking on that fairly rapidly. Anaconda will need its rebranding stuff to be done, but the rest looks fairly cleanly reusable.
I'd also be interested in getting plugged in on the CI/CD infrastructure side of things.
sounds good, what sort of tests did you have in mind ? I had started off on a smoke testing walk-through, but never had the time to get it end-to-end. I do want to get atleast the basic stuff done in there.
On 04/17/2015 10:23 AM, Karanbir Singh wrote:
On 17/04/15 14:16, Ian McLeod wrote:
On 04/14/2015 06:22 AM, Karanbir Singh wrote:
Hi,
One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal.
Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community.
This process proposed here very closely maps to the Core CentOS Linux process.
I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help.
This looks good to me and I'm keen to assist.
As a starting point, I've put up a snapshot of the non-RPM metadata that is being used to generate the upstream Atomic content. It differs substantially from the current CentOS Atomic SIG content and will need at least some modification to be workable.
It's currently sitting in this directory and branch of my fork of the Atomic SIG repo:
https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapsho...
Prior to the full RPM source drop being available, I'd like to at least try some initial smoke test tree composes using the SIG content in CBS. I will attempt to start on this early next week.
I believe the srpm content is at git.c.o already - we can get cracking on that fairly rapidly. Anaconda will need its rebranding stuff to be done, but the rest looks fairly cleanly reusable.
I'd also be interested in getting plugged in on the CI/CD infrastructure side of things.
sounds good, what sort of tests did you have in mind ? I had started off on a smoke testing walk-through, but never had the time to get it end-to-end. I do want to get atleast the basic stuff done in there.
Vagrant is a tempting option here. If we do regular and on-demand Vagrant box builds we get two things more or less for free:
1) Verification that Anaconda based installs are working.
2) A dirt simple smoke test that verifies quite a bit of basic functionality in the resulting system: "vagrant up; vagrant ssh /bin/true"
On 04/17/2015 02:16 PM, Ian McLeod wrote:
https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapsho...
Prior to the full RPM source drop being available, I'd like to at least try some initial smoke test tree composes using the SIG content in CBS. I will attempt to start on this early next week.
Johnny is going to work on the rpms today, we should have a repo with the binary built atomic branch content soon.
With that in mind, do you have any thoughts on how best to setup the rest of the pipeline to get the lorax build run and then the actual box images and isos ?
I was hoping to use the recently setup scripts and replace the repo configs to point at this new rpms content + base OS + Updates + Extras ( so as to consume the upstream docker and deps ).
regards,
Apologies for the delayed progress here. Some details below.
On 04/22/2015 04:56 AM, Karanbir Singh wrote:
On 04/17/2015 02:16 PM, Ian McLeod wrote:
https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapsho...
Prior to the full RPM source drop being available, I'd like to at least try some initial smoke test tree composes using the SIG content in CBS. I will attempt to start on this early next week.
Johnny is going to work on the rpms today, we should have a repo with the binary built atomic branch content soon.
With that in mind, do you have any thoughts on how best to setup the rest of the pipeline to get the lorax build run and then the actual box images and isos ?
I was hoping to use the recently setup scripts and replace the repo configs to point at this new rpms content + base OS + Updates + Extras ( so as to consume the upstream docker and deps ).
I and jbrooks have both had success generating a working tree using the JSON in the "downstream" branch of the SIG repo. I've done this using only the Base, updates, extras and the "cah" rebuild repo that Johnny produced. I'll PR these changes shortly.
The only snag I'm encountering has to do with the version of anaconda pulled into the installer. The 7.1.1 Atomic install media is based on an Anaconda version that is older than the RHEL 7.1 release Anaconda.
Internally we generated installer media by pointing lorax at a repo that intentionally masked out the 7.1 anaconda packages while preserving the remainder of the 7.1 updates. I've duplicated this locally using reposync to produce an appropriate repo for lorax. It seems to work.
However, this temporary intermediate lorax repo step doesn't fit very cleanly into the script workflow in the SIG repo, nor is it something that needs to be done on an ongoing basis. With this in mind, I wanted to see if perhaps I could work with someone from the core team to spin the 7.1.1 install media by hand and then focus on a merged/automated approach going forward.
Thoughts?
regards,
On 05/05/2015 08:38 AM, Ian McLeod wrote:
Apologies for the delayed progress here. Some details below.
On 04/22/2015 04:56 AM, Karanbir Singh wrote:
On 04/17/2015 02:16 PM, Ian McLeod wrote:
https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapsho...
Prior to the full RPM source drop being available, I'd like to at least try some initial smoke test tree composes using the SIG content in CBS. I will attempt to start on this early next week.
Johnny is going to work on the rpms today, we should have a repo with the binary built atomic branch content soon.
With that in mind, do you have any thoughts on how best to setup the rest of the pipeline to get the lorax build run and then the actual box images and isos ?
I was hoping to use the recently setup scripts and replace the repo configs to point at this new rpms content + base OS + Updates + Extras ( so as to consume the upstream docker and deps ).
I and jbrooks have both had success generating a working tree using the JSON in the "downstream" branch of the SIG repo. I've done this using only the Base, updates, extras and the "cah" rebuild repo that Johnny produced. I'll PR these changes shortly.
The only snag I'm encountering has to do with the version of anaconda pulled into the installer. The 7.1.1 Atomic install media is based on an Anaconda version that is older than the RHEL 7.1 release Anaconda.
Internally we generated installer media by pointing lorax at a repo that intentionally masked out the 7.1 anaconda packages while preserving the remainder of the 7.1 updates. I've duplicated this locally using reposync to produce an appropriate repo for lorax. It seems to work.
Awesome! and thanks :-).
However, this temporary intermediate lorax repo step doesn't fit very cleanly into the script workflow in the SIG repo, nor is it something that needs to be done on an ongoing basis. With this in mind, I wanted to see if perhaps I could work with someone from the core team to spin the 7.1.1 install media by hand and then focus on a merged/automated approach going forward.
Thoughts?
Do you mean you are planning to use RHEL/CentOS 7.1.1 anaconda packages with downstream CentOS Atomic build of 7.1.1?
-Lala
On 05/05/15 04:08, Ian McLeod wrote:
Apologies for the delayed progress here. Some details below.
On 04/22/2015 04:56 AM, Karanbir Singh wrote:
On 04/17/2015 02:16 PM, Ian McLeod wrote:
https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapsho...
Prior to the full RPM source drop being available, I'd like to at least try some initial smoke test tree composes using the SIG content in CBS. I will attempt to start on this early next week.
Johnny is going to work on the rpms today, we should have a repo with the binary built atomic branch content soon.
With that in mind, do you have any thoughts on how best to setup the rest of the pipeline to get the lorax build run and then the actual box images and isos ?
I was hoping to use the recently setup scripts and replace the repo configs to point at this new rpms content + base OS + Updates + Extras ( so as to consume the upstream docker and deps ).
I and jbrooks have both had success generating a working tree using the JSON in the "downstream" branch of the SIG repo. I've done this using only the Base, updates, extras and the "cah" rebuild repo that Johnny produced. I'll PR these changes shortly.
The only snag I'm encountering has to do with the version of anaconda pulled into the installer. The 7.1.1 Atomic install media is based on an Anaconda version that is older than the RHEL 7.1 release Anaconda.
Internally we generated installer media by pointing lorax at a repo that intentionally masked out the 7.1 anaconda packages while preserving the remainder of the 7.1 updates. I've duplicated this locally using reposync to produce an appropriate repo for lorax. It seems to work.
cool!
However, this temporary intermediate lorax repo step doesn't fit very cleanly into the script workflow in the SIG repo, nor is it something that needs to be done on an ongoing basis. With this in mind, I wanted to see if perhaps I could work with someone from the core team to spin the 7.1.1 install media by hand and then focus on a merged/automated approach going forward.
is that not achieved with just an exclude= in the repo def's ? if we need to run a createrepo with an -x to exclude from the repo side, we can do that as well. Typically, we snapshot the tree that goes into a build anyway.
regards
On 05/05/2015 03:00 AM, Karanbir Singh wrote:
On 05/05/15 04:08, Ian McLeod wrote:
Apologies for the delayed progress here. Some details below.
On 04/22/2015 04:56 AM, Karanbir Singh wrote:
On 04/17/2015 02:16 PM, Ian McLeod wrote:
https://github.com/imcleod/sig-atomic-buildscripts/tree/scratch/rhel-snapsho...
Prior to the full RPM source drop being available, I'd like to at least try some initial smoke test tree composes using the SIG content in CBS. I will attempt to start on this early next week.
Johnny is going to work on the rpms today, we should have a repo with the binary built atomic branch content soon.
With that in mind, do you have any thoughts on how best to setup the rest of the pipeline to get the lorax build run and then the actual box images and isos ?
I was hoping to use the recently setup scripts and replace the repo configs to point at this new rpms content + base OS + Updates + Extras ( so as to consume the upstream docker and deps ).
I and jbrooks have both had success generating a working tree using the JSON in the "downstream" branch of the SIG repo. I've done this using only the Base, updates, extras and the "cah" rebuild repo that Johnny produced. I'll PR these changes shortly.
The only snag I'm encountering has to do with the version of anaconda pulled into the installer. The 7.1.1 Atomic install media is based on an Anaconda version that is older than the RHEL 7.1 release Anaconda.
Internally we generated installer media by pointing lorax at a repo that intentionally masked out the 7.1 anaconda packages while preserving the remainder of the 7.1 updates. I've duplicated this locally using reposync to produce an appropriate repo for lorax. It seems to work.
cool!
However, this temporary intermediate lorax repo step doesn't fit very cleanly into the script workflow in the SIG repo, nor is it something that needs to be done on an ongoing basis. With this in mind, I wanted to see if perhaps I could work with someone from the core team to spin the 7.1.1 install media by hand and then focus on a merged/automated approach going forward.
is that not achieved with just an exclude= in the repo def's ? if we need to run a createrepo with an -x to exclude from the repo side, we can do that as well. Typically, we snapshot the tree that goes into a build anyway.
I will doublecheck with Colin on this, but as best I can tell, the "rpm-ostree-toolbox installer" input allows only repo URLs and package name based excludes. For example:
https://github.com/CentOS/sig-atomic-buildscripts/blob/master/config.ini#L52
If I can bend this to exclude just the newer anaconda, that would be ideal.
If not, as you say, creating an alternative view of the Base repo that exludes them seems to work as well.
regards
On Tue, May 5, 2015, at 08:31 AM, Ian McLeod wrote:
I will doublecheck with Colin on this, but as best I can tell, the "rpm-ostree-toolbox installer" input allows only repo URLs and package name based excludes.
Yes, unfortunately. This is actually a lorax restriction in that it only takes repo URLs as arguments, not repo files that would have `excludes=` processed.
On 05/05/2015 01:46 PM, Colin Walters wrote:
On Tue, May 5, 2015, at 08:31 AM, Ian McLeod wrote:
I will doublecheck with Colin on this, but as best I can tell, the "rpm-ostree-toolbox installer" input allows only repo URLs and package name based excludes.
Yes, unfortunately. This is actually a lorax restriction in that it only takes repo URLs as arguments, not repo files that would have `excludes=` processed.
not a problem, i will get the repo setup today. If we can make sure the PR's are all in, I can also run through the build and post results.
- KB
On 05/05/2015 08:08 AM, Karanbir Singh wrote:
On 05/05/2015 01:46 PM, Colin Walters wrote:
On Tue, May 5, 2015, at 08:31 AM, Ian McLeod wrote:
I will doublecheck with Colin on this, but as best I can tell, the "rpm-ostree-toolbox installer" input allows only repo URLs and package name based excludes.
Yes, unfortunately. This is actually a lorax restriction in that it only takes repo URLs as arguments, not repo files that would have `excludes=` processed.
not a problem, i will get the repo setup today. If we can make sure the PR's are all in, I can also run through the build and post results.
- KB
So, I did a quick experiment and added explicit NVR package excludes using the "lorax_exclude_packages" pass-through option. It's a bit of a hack, and it will stop working and/or need to be refreshed when a newer anaconda appears in the upstream CentOS repos, but by that point our 7.1.1 downstream should be out the door and done.
Here is the change:
https://github.com/CentOS/sig-atomic-buildscripts/pull/30/files#diff-38589f3...
It seems to have worked.
-Ian
On 05/05/2015 08:36 AM, Ian McLeod wrote:
On 05/05/2015 08:08 AM, Karanbir Singh wrote:
On 05/05/2015 01:46 PM, Colin Walters wrote:
On Tue, May 5, 2015, at 08:31 AM, Ian McLeod wrote:
I will doublecheck with Colin on this, but as best I can tell, the "rpm-ostree-toolbox installer" input allows only repo URLs and package name based excludes.
Yes, unfortunately. This is actually a lorax restriction in that it only takes repo URLs as arguments, not repo files that would have `excludes=` processed.
not a problem, i will get the repo setup today. If we can make sure the PR's are all in, I can also run through the build and post results.
- KB
So, I did a quick experiment and added explicit NVR package excludes using the "lorax_exclude_packages" pass-through option. It's a bit of a hack, and it will stop working and/or need to be refreshed when a newer anaconda appears in the upstream CentOS repos, but by that point our 7.1.1 downstream should be out the door and done.
Here is the change:
https://github.com/CentOS/sig-atomic-buildscripts/pull/30/files#diff-38589f3...
It seems to have worked.
Can we quickly establish a location for the candidate composed trees and lorax install trees, and then do some test runs with the content in the "downstream" tree?
It's really impossible to do an end to end test of the repo content if there's no established location (and ref name) to put into the kickstart used to generate the image.
-Ian _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 05/06/2015 07:53 AM, Ian McLeod wrote:
On 05/05/2015 08:36 AM, Ian McLeod wrote:
On 05/05/2015 08:08 AM, Karanbir Singh wrote:
On 05/05/2015 01:46 PM, Colin Walters wrote:
On Tue, May 5, 2015, at 08:31 AM, Ian McLeod wrote:
I will doublecheck with Colin on this, but as best I can tell, the "rpm-ostree-toolbox installer" input allows only repo URLs and package name based excludes.
Yes, unfortunately. This is actually a lorax restriction in that it only takes repo URLs as arguments, not repo files that would have `excludes=` processed.
not a problem, i will get the repo setup today. If we can make sure the PR's are all in, I can also run through the build and post results.
- KB
So, I did a quick experiment and added explicit NVR package excludes using the "lorax_exclude_packages" pass-through option. It's a bit of a hack, and it will stop working and/or need to be refreshed when a newer anaconda appears in the upstream CentOS repos, but by that point our 7.1.1 downstream should be out the door and done.
Here is the change:
https://github.com/CentOS/sig-atomic-buildscripts/pull/30/files#diff-38589f3...
It seems to have worked.
Can we quickly establish a location for the candidate composed trees and lorax install trees, and then do some test runs with the content in the "downstream" tree?
It's really impossible to do an end to end test of the repo content if there's no established location (and ref name) to put into the kickstart used to generate the image.
Some quick further updates here:
I have been unable to generate a working install tree using the current mirror content combined with the "cah" repo. The lorax runs complete, but the resulting Anaconda fails during installs in one way or another.
I initially hit some python-blivet version mismatch issues. Even after fixing these, I end up with an install that hangs when creating the initial filesystems. At this point, I attempted to dial back the kernel version pulled in by lorax, to match the somewhat older version present in the RHELAH installer. This, it seems, is impossible using the existing mirror content, which is now irreversibly newer.
If, however, I use the composed ostree generated from the current "downstream" branch of the Atomic SIG repo, combined with the Anaconda used to generate the SIG images, all is well. Using local runs of Image Factory, I've generated a vagrant/libvirt box that boots successfully into Atomic and this system contains the "cah" repo packages. To be clear, I'm talking about the install tree hosted here:
http://buildlogs.centos.org/centos/7/atomic/x86_64/atomic-anaconda-nightly/l...
So, again, if we can get the composed tree generated from the "downstream" branch of the SIG repo hosted on buildlogs, it should be possible to use the CBS to generate both cloud and vagrant images that qualify, roughly speaking, as a downstream rebuild of the 7.1.1 RHELAH release.
Thoughts?
-Ian _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 05/07/2015 04:54 AM, Ian McLeod wrote:
Some quick further updates here:
I have been unable to generate a working install tree using the current mirror content combined with the "cah" repo. The lorax runs complete, but the resulting Anaconda fails during installs in one way or another.
I initially hit some python-blivet version mismatch issues. Even after fixing these, I end up with an install that hangs when creating the initial filesystems. At this point, I attempted to dial back the kernel version pulled in by lorax, to match the somewhat older version present in the RHELAH installer. This, it seems, is impossible using the existing mirror content, which is now irreversibly newer.
If, however, I use the composed ostree generated from the current "downstream" branch of the Atomic SIG repo, combined with the Anaconda used to generate the SIG images, all is well. Using local runs of Image Factory, I've generated a vagrant/libvirt box that boots successfully into Atomic and this system contains the "cah" repo packages. To be clear, I'm talking about the install tree hosted here:
http://buildlogs.centos.org/centos/7/atomic/x86_64/atomic-anaconda-nightly/l...
The included code must have worked, Red Hat did a release based on it :)
But if in the interim we can get around the blocker by using the upstream anaconda, lets do that while we go back and figure out what the problem with the released code is.
- KB
On 05/07/2015 05:39 AM, Karanbir Singh wrote:
On 05/07/2015 04:54 AM, Ian McLeod wrote:
Some quick further updates here:
I have been unable to generate a working install tree using the current mirror content combined with the "cah" repo. The lorax runs complete, but the resulting Anaconda fails during installs in one way or another.
I initially hit some python-blivet version mismatch issues. Even after fixing these, I end up with an install that hangs when creating the initial filesystems. At this point, I attempted to dial back the kernel version pulled in by lorax, to match the somewhat older version present in the RHELAH installer. This, it seems, is impossible using the existing mirror content, which is now irreversibly newer.
If, however, I use the composed ostree generated from the current "downstream" branch of the Atomic SIG repo, combined with the Anaconda used to generate the SIG images, all is well. Using local runs of Image Factory, I've generated a vagrant/libvirt box that boots successfully into Atomic and this system contains the "cah" repo packages. To be clear, I'm talking about the install tree hosted here:
http://buildlogs.centos.org/centos/7/atomic/x86_64/atomic-anaconda-nightly/l...
The included code must have worked, Red Hat did a release based on it :)
But if in the interim we can get around the blocker by using the upstream anaconda, lets do that while we go back and figure out what the problem with the released code is.
Sounds good.
What is the next step here?
At the risk of sounding like a broken record, it would be great to get tree composes onto buildlogs. This will immediately allow me to spin cloud and vagrant image candidates with publicly visible build logs, kickstarts, etc.
- KB
On Thu, May 7, 2015, at 06:39 AM, Karanbir Singh wrote:
I initially hit some python-blivet version mismatch issues. Even after fixing these, I end up with an install that hangs when creating the initial filesystems. At this point, I attempted to dial back the kernel version pulled in by lorax, to match the somewhat older version present in the RHELAH installer. This, it seems, is impossible using the existing mirror content, which is now irreversibly newer.
It is really painful but not impossible. I had a script lying around for this that I can't find at the moment, but will retype now.
http://buildlogs.centos.org/centos/7/atomic/x86_64/atomic-anaconda-nightly/l...
This build was last done on 19-Feb-2015 right? Is the date stamp wrong, or why are we debugging something so old?
On 05/05/15 04:08, Ian McLeod wrote:
I and jbrooks have both had success generating a working tree using the JSON in the "downstream" branch of the SIG repo. I've done this using only the Base, updates, extras and the "cah" rebuild repo that Johnny produced. I'll PR these changes shortly.
also just to confirm, this was tested using the build_ostree_components.sh script ( and changes needed are being pushed against that ? )
- KB
On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote:
One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host.
Can you help me understand how this relates to the "4 week Atomic releases" plan Mike McGrath posted about last month? (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html)
On 17/04/15 16:11, Matthew Miller wrote:
On Tue, Apr 14, 2015 at 12:22:31PM +0100, Karanbir Singh wrote:
One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host.
Can you help me understand how this relates to the "4 week Atomic releases" plan Mike McGrath posted about last month? (http://lists.centos.org/pipermail/centos-devel/2015-March/012959.html)
it doesnt.
the '4' builds will happen orthogonal from these ones.
On 04/14/2015 04:52 PM, Karanbir Singh wrote:
Hi,
One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal.
+1. I think this will serve as the stable build for CentOS Atomic SIG.
Have we decided about the time-line to make this happen?
Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community.
This process proposed here very closely maps to the Core CentOS Linux process.
I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help.
Regards
-Lala
On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote:
On 04/14/2015 04:52 PM, Karanbir Singh wrote:
Hi,
One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal.
+1. I think this will serve as the stable build for CentOS Atomic SIG.
Have we decided about the time-line to make this happen?
The reason I am interested in it because I am getting in to one or other issues while using the test builds of CentOS Atomic hosts and don't think SIG provides a stable build yet. So I think rebuilding the RHEL Atomic will give us a stable Atomic host.
Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community.
This process proposed here very closely maps to the Core CentOS Linux process.
I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help.
Regards
-Lala
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 04/21/2015 08:28 AM, Lalatendu Mohanty wrote:
On 04/21/2015 12:00 PM, Lalatendu Mohanty wrote:
On 04/14/2015 04:52 PM, Karanbir Singh wrote:
Hi,
One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal.
+1. I think this will serve as the stable build for CentOS Atomic SIG.
Have we decided about the time-line to make this happen?
The reason I am interested in it because I am getting in to one or other issues while using the test builds of CentOS Atomic hosts and don't think SIG provides a stable build yet. So I think rebuilding the RHEL Atomic will give us a stable Atomic host.
the intention is to build this as soon as we can and get the things moving.
Its not going to be a clear build => done situation, we will need to iterate over things a few times, and there will also be some patching / de-branding that needs to be done ( hoping to do all this in the mailing list here, to get max exposure and ideally help! )
- KB
Quick update on this, we have the rpm stack done once - its going to need debranding, but we can start on that once we have the other things sorted out. Ian's done some work last night to get the images and the anaconda side of things sorted out, but that work is not finished yet. We hope to keep working on that through the day today and see if we can get to a testable set of components by the close of play,
- KB
On 04/23/2015 02:41 PM, Karanbir Singh wrote:
Quick update on this, we have the rpm stack done once - its going to need debranding, but we can start on that once we have the other things sorted out. Ian's done some work last night to get the images and the anaconda side of things sorted out, but that work is not finished yet. We hope to keep working on that through the day today and see if we can get to a testable set of components by the close of play,
- KB
Awesome news!. I am looking forward to use the 1st cut.
-Lala
-
Colin Walters -
Ian McLeod -
Karanbir Singh -
Karanbir Singh -
Lalatendu Mohanty -
M. Edward (Ed) Borasky -
Matthew Miller -
Mauricio Tavares -
Navid Shaikh