As Joe noted the other day, Fedora Atomic is intended to come with this service, which will create storage space for Docker images. As mentioned in the IRC meeting, at this point, the plan is to get this to stable after the beta (before the feature freeze, as soon as possible), to update the Atomic tree definition, and then to request a test candidate including it.
But the first step is getting it to stable. So, testers wanted --
https://admin.fedoraproject.org/updates/docker-storage-setup-0.0.3-1.fc21
second priority after
http://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test
of course :)
On Thu, Oct 30, 2014 at 09:34:32AM -0400, Matthew Miller wrote:
As Joe noted the other day, Fedora Atomic is intended to come with this service, which will create storage space for Docker images. As mentioned in the IRC meeting, at this point, the plan is to get this to stable after the beta (before the feature freeze, as soon as possible), to update the Atomic tree definition, and then to request a test candidate including it.
But the first step is getting it to stable. So, testers wanted --
https://admin.fedoraproject.org/updates/docker-storage-setup-0.0.3-1.fc21
So.. not the easiest thing to test because I couldn't find any atomic images with this package installed. Here is what I did to test on the atomic image from http://koji.fedoraproject.org/koji/taskinfo?taskID=7974506 :
cd /tmp/ wget https://kojipkgs.fedoraproject.org//packages/docker-storage-setup/0.0.3/1.fc... rpm2cpio docker-storage-setup-0.0.3-1.fc21.noarch.rpm | cpio -idv cp usr/bin/docker-storage-setup /usr/local/bin/docker-storage-setup cp usr/lib/systemd/system/docker-storage-setup.service /etc/systemd/system/docker-storage-setup.service sed -i 's|/usr/bin/|/usr/local/bin/|' /etc/systemd/system/docker-storage-setup.service systemctl enable docker-storage-setup.service systemctl enable docker.service reboot
After reboot docker was up and running and I was able to pull and run busybox from the docker registry. Here are the logs:
docker-storage-setup[783]: CHANGED: partition=2 start=1026048 old: size=5265408 end=6291456 new: size=40916832,end=41942880 docker-storage-setup[783]: Physical volume "/dev/vda2" changed docker-storage-setup[783]: 1 physical volume(s) resized / 0 physical volume(s) not resized docker-storage-setup[783]: Rounding up size to full physical extent 20.00 MiB docker-storage-setup[783]: Logical volume "docker-meta" created docker-storage-setup[783]: Logical volume "docker-data" created
Hope this helps,
Dusty
On Thu, Oct 30, 2014, at 09:12 PM, Dusty Mabe wrote:
So.. not the easiest thing to test because I couldn't find any atomic images with this package installed.
It is possible to compose trees on your own too, using local packages. A quick HOWTO:
yum install rpm-ostree cd /srv git clone https://fedorahosted.org/fedora-atomic/ mkdir /srv/repo ostree --repo=/srv/repo init --mode=archive-z2 mkdir local-repo cp /path/to/docker-storage-setup.rpm local-repo (cd local-repo && createrepo .) # edit fedora-atomic/fedora-atomic-base.json to add a yum repo pointing to /srv/local-repo rpm-ostree compose tree --repo=/srv/repo fedora-atomic/fedora-atomic-docker-host.json
Then set up a static webserver pointing at /srv/repo. In the client system:
ostree remote add local --set=gpg-verify=false http://192.168.122.1/repo atomic rebase local:
rpm2cpio docker-storage-setup-0.0.3-1.fc21.noarch.rpm | cpio -idv cp usr/bin/docker-storage-setup /usr/local/bin/docker-storage-setup
That works too though. Thanks for testing!
On Thu, Oct 30, 2014 at 9:12 PM, Dusty Mabe dusty@dustymabe.com wrote:
On Thu, Oct 30, 2014 at 09:34:32AM -0400, Matthew Miller wrote:
As Joe noted the other day, Fedora Atomic is intended to come with this service, which will create storage space for Docker images. As mentioned in the IRC meeting, at this point, the plan is to get this to stable after the beta (before the feature freeze, as soon as possible), to update the Atomic tree definition, and then to request a test candidate including it.
But the first step is getting it to stable. So, testers wanted --
https://admin.fedoraproject.org/updates/docker-storage-setup-0.0.3-1.fc21
So.. not the easiest thing to test because I couldn't find any atomic images with this package installed. Here is what I did to test on the atomic image from http://koji.fedoraproject.org/koji/taskinfo?taskID=7974506 :
cd /tmp/ wget https://kojipkgs.fedoraproject.org//packages/docker-storage-setup/0.0.3/1.fc... rpm2cpio docker-storage-setup-0.0.3-1.fc21.noarch.rpm | cpio -idv cp usr/bin/docker-storage-setup /usr/local/bin/docker-storage-setup cp usr/lib/systemd/system/docker-storage-setup.service /etc/systemd/system/docker-storage-setup.service sed -i 's|/usr/bin/|/usr/local/bin/|' /etc/systemd/system/docker-storage-setup.service systemctl enable docker-storage-setup.service systemctl enable docker.service reboot
After reboot docker was up and running and I was able to pull and run busybox from the docker registry. Here are the logs:
docker-storage-setup[783]: CHANGED: partition=2 start=1026048 old: size=5265408 end=6291456 new: size=40916832,end=41942880 docker-storage-setup[783]: Physical volume "/dev/vda2" changed docker-storage-setup[783]: 1 physical volume(s) resized / 0 physical volume(s) not resized docker-storage-setup[783]: Rounding up size to full physical extent 20.00 MiB docker-storage-setup[783]: Logical volume "docker-meta" created docker-storage-setup[783]: Logical volume "docker-data" created
Hope this helps,
Dusty
Thank you for testing. You basically tested in the same way that I developed and demoed it. :-) Unfortunately, you gave it karma while it was still pending, and when the push to testing happened, it reset the karma to 0. So please "+1" again. Thanks!
On Fri, Oct 31, 2014 at 09:09:41AM -0400, Andy Grimm wrote:
Thank you for testing. You basically tested in the same way that I developed and demoed it. :-) Unfortunately, you gave it karma while it was still pending, and when the push to testing happened, it reset the karma to 0. So please "+1" again. Thanks!
Done
On Thu, Oct 30, 2014, at 09:34 AM, Matthew Miller wrote:
As Joe noted the other day, Fedora Atomic is intended to come with this service, which will create storage space for Docker images. As mentioned in the IRC meeting, at this point, the plan is to get this to stable after the beta (before the feature freeze, as soon as possible), to update the Atomic tree definition, and then to request a test candidate including it.
But the first step is getting it to stable. So, testers wanted --
https://admin.fedoraproject.org/updates/docker-storage-setup-0.0.3-1.fc21
Still need one more karma.
On Sat, Nov 01, 2014 at 04:41:35PM -0400, Colin Walters wrote:
https://admin.fedoraproject.org/updates/docker-storage-setup-0.0.3-1.fc21
Still need one more karma.
It's got it now -- should go to stable tonight. Can we get the tree updated so it includes this and kubernetes (do we also need karma on https://admin.fedoraproject.org/updates/FEDORA-2014-13940/kubernetes-0.4+-0.... ?) and cockpit and whatever else is considered the state-of-atomic-today?
Once that's ready, we can ask releng for a test candidate.
On 11/03/2014 11:19 AM, Matthew Miller wrote:
It's got it now -- should go to stable tonight. Can we get the tree updated so it includes this and kubernetes (do we also need karma on https://admin.fedoraproject.org/updates/FEDORA-2014-13940/kubernetes-0.4+-0.... ?) and cockpit and whatever else is considered the state-of-atomic-today?
Once that's ready, we can ask releng for a test candidate.
I thought Colin had made the change required for k8s and Cockpit, but it didn't seem to get pulled in.
Do we just need to file a ticket with releng for the tc once this is complete, or...?
Best,
jzb
On Mon, Nov 03, 2014 at 11:42:22AM -0600, Joe Brockmeier wrote:
Do we just need to file a ticket with releng for the tc once this is complete, or...?
QA normally files the TC tickets, so let's coordinate with them.
I backported some changes from fedora-atomic master to f21: https://git.fedorahosted.org/cgit/fedora-atomic.git/log/?h=f21
Here are 4 patches for spin-kickstarts master for fedora-cloud-atomic.ks. I tried to actually test them against rawhide but hit https://bugzilla.redhat.com/show_bug.cgi?id=1111290
So I backported them to f21 and then I hit a different (presumably anaconda, but maybe dracut) bug where it loops forever at shutdown (haven't searched for/filed a bug yet).
However if I terminated the VM in imagefactory, the resulting qcow2 works.
To save you all the pain of testing this until we get patches landed, please try: https://alt.fedoraproject.org/pub/alt/fedora-atomic/testing/f21/20141104.0/f...
On Tue, Nov 04, 2014 at 08:53:04PM -0500, Colin Walters wrote:
Here are 4 patches for spin-kickstarts master for fedora-cloud-atomic.ks. I tried to actually test them against rawhide but hit https://bugzilla.redhat.com/show_bug.cgi?id=1111290
Applied to master -- I had to update the one about extlinux because an unrelated change you hadn't pulled. Can you rebase for f21? They don't apply cleanly -- I think just for minor things but I'll need more focus than I have right now to do it right. (Will look again tomorrow.)
On Tue, Nov 4, 2014, at 09:20 PM, Matthew Miller wrote:
Applied to master -- I had to update the one about extlinux because an unrelated change you hadn't pulled. Can you rebase for f21? They don't apply cleanly -- I think just for minor things but I'll need more focus than I have right now to do it right. (Will look again tomorrow.)
These are the two patches that should go on f21, backported from master. And only the first is really needed.
On Wed, Nov 05, 2014 at 10:37:02AM -0500, Colin Walters wrote:
These are the two patches that should go on f21, backported from master. And only the first is really needed.
Applied. Don't we also need "Point to dl.fedoraproject.org"?
On Wed, Nov 5, 2014, at 11:45 AM, Matthew Miller wrote:
On Wed, Nov 05, 2014 at 10:37:02AM -0500, Colin Walters wrote:
These are the two patches that should go on f21, backported from master. And only the first is really needed.
Applied. Don't we also need "Point to dl.fedoraproject.org"?
I'd like to get a final confirmation that's what we should do for release before we hardcode the URL. Client systems can at least change that after the fact, whereas partitioning is baked in.
On Wed, Nov 05, 2014 at 12:10:40PM -0500, Colin Walters wrote:
I'd like to get a final confirmation that's what we should do for release before we hardcode the URL. Client systems can at least change that after the fact, whereas partitioning is baked in.
Who are the stakeholders for that final decision? Cloud WG, releng, infrastructure, mirrors? Let's get it made quickly.
In the meantime, I'd argue that changing it for the test candidates is a step forward from the internal URL.
On Wed, Nov 05, 2014 at 12:20:38PM -0500, Matthew Miller wrote:
Who are the stakeholders for that final decision? Cloud WG, releng, infrastructure, mirrors? Let's get it made quickly.
In the meantime, I'd argue that changing it for the test candidates is a step forward from the internal URL.
Although obviously we need it to be more than rawhide.
On Wed, Nov 05, 2014 at 12:22:33PM -0500, Matthew Miller wrote:
In the meantime, I'd argue that changing it for the test candidates is a step forward from the internal URL.
Although obviously we need it to be more than rawhide.
And also -- we _want_ it to hit the internal URL in koji but be configured to access the outside URL after, right? So, that should be changed in %post, I guess?
On Wed, Nov 5, 2014, at 04:11 PM, Matthew Miller wrote:
On Wed, Nov 05, 2014 at 12:22:33PM -0500, Matthew Miller wrote:
In the meantime, I'd argue that changing it for the test candidates is a step forward from the internal URL.
Although obviously we need it to be more than rawhide.
And also -- we _want_ it to hit the internal URL in koji but be configured to access the outside URL after, right? So, that should be changed in %post, I guess?
Right. This is a complex topic, because when I wrote the original Anaconda rpmostreepayload patches, I had been thinking of a boot.iso scenario, whereas it's awkward for the ImageFactory-on-server.
The short answer is to change it in %post.
The long term answer is for Anaconda's rpmostreepayload to be aware of the distinction between "distribution side" composes and downstream composes. (And for that matter, for Anaconda itself to understand this. We shouldn't have to rm /var/lib/systemd/random-seed in %post)
-
Andy Grimm -
Colin Walters -
Dusty Mabe -
Joe Brockmeier -
Matthew Miller