Currently, the Atomic cloud image still tries to contact the compose server internal mirror for updates.
Do we know what the final mirrorlist URL will be? Where are we on getting content sync'd out?
On Sun, Nov 02, 2014 at 04:33:57PM -0500, Colin Walters wrote:
Currently, the Atomic cloud image still tries to contact the compose server internal mirror for updates.
Do we know what the final mirrorlist URL will be? Where are we on getting content sync'd out?
I'm not sure exactly where the final bits will live, or what the URL will be, but the fedmsg-atomic-composer is up and running on the composer.stg box and successfully spitting out rawhide & f21 trees. Pushing this out to a production releng box will be simple once we determine where the trees will live on /pub.
As far as getting them hooked into MirrorManager, I opened this ticket last week to try and figure out what it will take: https://fedorahosted.org/fedora-infrastructure/ticket/4585
luke
On Mon, Nov 03, 2014 at 11:24:18AM -0500, Luke Macken wrote:
I'm not sure exactly where the final bits will live, or what the URL will be, but the fedmsg-atomic-composer is up and running on the composer.stg box and successfully spitting out rawhide & f21 trees. Pushing this out to a production releng box will be simple once we determine where the trees will live on /pub.
Is it https://dl.fedoraproject.org/pub/alt/fedora-atomic/ ?
On Mon, Nov 03, 2014 at 11:42:15AM -0500, Matthew Miller wrote:
On Mon, Nov 03, 2014 at 11:24:18AM -0500, Luke Macken wrote:
I'm not sure exactly where the final bits will live, or what the URL will be, but the fedmsg-atomic-composer is up and running on the composer.stg box and successfully spitting out rawhide & f21 trees. Pushing this out to a production releng box will be simple once we determine where the trees will live on /pub.
Assuming that this is correct, what needs to change? Is this a kickstart line? We should make the appropriate change _today_.
On Tue, Nov 4, 2014, at 10:17 AM, Matthew Miller wrote:
Assuming that this is correct, what needs to change? Is this a kickstart line? We should make the appropriate change _today_.
That's not a globally replicated location, it means we're not taking advantage of mirrorlists. Particularly for cloud, I think we really want content replicated in each provider's AZ to avoid transit costs. Not sure if Fedora does this now.
Also:
1) That data comes from the atomic01.qa box that was provisioned as a testbed for Atomic work, with the idea that official composes would be done in rel-eng 2) It's only composing rawhide right now
And also note that until I get a chance to push some changes to spin-kickstarts, we're not going to have optimized LVM, which is 36% of the point of Atomic.
The most realistic option to me seems to be to deliver Atomic 21 asynchronously from Fedora 21 final. Ideally within a few weeks? Welcome to other ideas though.
On Tue, Nov 04, 2014 at 10:28:02AM -0500, Colin Walters wrote:
Assuming that this is correct, what needs to change? Is this a kickstart line? We should make the appropriate change _today_.
That's not a globally replicated location, it means we're not taking advantage of mirrorlists. Particularly for cloud, I think we really
Right, we decided a long time ago to defer worrying about mirroring until F22.
want content replicated in each provider's AZ to avoid transit costs. Not sure if Fedora does this now.
We had this set up several releases ago but it was dropped due to lack of popularity, if I recall. Now that we're scaling up our efforts we should revisit.
^ Kushal that's one for the todo list. :)
Also:
- That data comes from the atomic01.qa box that was provisioned as a
testbed for Atomic work, with the idea that official composes would be done in rel-eng
I thought that's what Luke was working on?
- It's only composing rawhide right now
:-/
And also note that until I get a chance to push some changes to spin-kickstarts, we're not going to have optimized LVM, which is 36% of the point of Atomic.
Since beta is out the door, let's make those changes right now and get to testing them.
The most realistic option to me seems to be to deliver Atomic 21 asynchronously from Fedora 21 final. Ideally within a few weeks? Welcome to other ideas though.
We _really_ don't have a mechanism for that, although we have previously shipped updated images in emergencies. We've got people on this -- let's get it done with the actual release — there's still a month to go. (Two weeks of unfrozen, two where we can request exceptions but hopefully won't need to.)
On Mon, Nov 3, 2014, at 11:24 AM, Luke Macken wrote:
I'm not sure exactly where the final bits will live, or what the URL will be, but the fedmsg-atomic-composer is up and running on the composer.stg box and successfully spitting out rawhide & f21 trees.
Nice. Maybe we can deprecate atomic01.qa.fp.org in favor of this? You could change it to take over the rawhide sync to dl.fedoraproject.org at least?
Pushing this out to a production releng box will be simple once we determine where the trees will live on /pub.
Who owns that decision/how do we move forward?
On Tue, Nov 04, 2014 at 10:34:30AM -0500, Colin Walters wrote:
Pushing this out to a production releng box will be simple once we determine where the trees will live on /pub.
Who owns that decision/how do we move forward?
Ticket at https://fedorahosted.org/rel-eng/ — I think the existing alt location is good enough for now and just using that might save wrangling.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, 02 Nov 2014 16:33:57 -0500 Colin Walters walters@verbum.org wrote:
Currently, the Atomic cloud image still tries to contact the compose server internal mirror for updates.
Do we know what the final mirrorlist URL will be? Where are we on getting content sync'd out?
the metalink should be
https://mirrors.fedoraproject.org/metalink?repo=fedora-atomic-21&arch=x8... with the location on the primary mirror being http://dl.fedoraproject.org/pub/fedora/linux/atomic/21/
Dennis
On Fri, Nov 07, 2014 at 07:03:28AM -0600, Dennis Gilmore wrote:
Do we know what the final mirrorlist URL will be? Where are we on getting content sync'd out?
the metalink should be https://mirrors.fedoraproject.org/metalink?repo=fedora-atomic-21&arch=x8... with the location on the primary mirror being http://dl.fedoraproject.org/pub/fedora/linux/atomic/21/
So we _are_ putting this out to the mirrors after all? Is this included in fedora-enchilada or is it separate?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 7 Nov 2014 08:58:29 -0500 Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Nov 07, 2014 at 07:03:28AM -0600, Dennis Gilmore wrote:
Do we know what the final mirrorlist URL will be? Where are we on getting content sync'd out?
the metalink should be https://mirrors.fedoraproject.org/metalink?repo=fedora-atomic-21&arch=x8... with the location on the primary mirror being http://dl.fedoraproject.org/pub/fedora/linux/atomic/21/
So we _are_ putting this out to the mirrors after all? Is this included in fedora-enchilada or is it separate?
it is included in the fedora module which means also fedora-enchilada. we could move it to alt space is people prefer, in the end everything goes on mirrors. depending on where it goes changes how many mirrors will carry it.
Dennis
On Fri, Nov 7, 2014, at 08:03 AM, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, 02 Nov 2014 16:33:57 -0500 Colin Walters walters@verbum.org wrote:
Currently, the Atomic cloud image still tries to contact the compose server internal mirror for updates.
Do we know what the final mirrorlist URL will be? Where are we on getting content sync'd out?
the metalink should be
https://mirrors.fedoraproject.org/metalink?repo=fedora-atomic-21&arch=x8...
Thanks, Dennis. The attached patch should implement this, once we:
1) Get https://admin.fedoraproject.org/updates/ostree-2014.11-1.fc21 through 2) Recompose the tree with it 3) Get a metalink generated pointing at that tree 4) Do some end-to-end testing of this
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, 08 Nov 2014 13:16:19 -0500 Colin Walters walters@verbum.org wrote:
On Fri, Nov 7, 2014, at 08:03 AM, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, 02 Nov 2014 16:33:57 -0500 Colin Walters walters@verbum.org wrote:
Currently, the Atomic cloud image still tries to contact the compose server internal mirror for updates.
Do we know what the final mirrorlist URL will be? Where are we on getting content sync'd out?
the metalink should be
https://mirrors.fedoraproject.org/metalink?repo=fedora-atomic-21&arch=x8...
Thanks, Dennis. The attached patch should implement this, once we:
through 2) Recompose the tree with it 3) Get a metalink generated pointing at that tree
This likely needs work in mirrormanager to work. when mm detects the repo things happen automatically in the background. if mm can not detect a atomic tree it will do nothing and there will be no metalink url
- Do some end-to-end testing of this
On Mon, Nov 10, 2014 at 12:46:05AM -0600, Dennis Gilmore wrote:
On Sat, 08 Nov 2014 13:16:19 -0500 Colin Walters walters@verbum.org wrote:
On Fri, Nov 7, 2014, at 08:03 AM, Dennis Gilmore wrote:
On Sun, 02 Nov 2014 16:33:57 -0500 Colin Walters walters@verbum.org wrote:
Currently, the Atomic cloud image still tries to contact the compose server internal mirror for updates.
Do we know what the final mirrorlist URL will be? Where are we on getting content sync'd out?
the metalink should be
https://mirrors.fedoraproject.org/metalink?repo=fedora-atomic-21&arch=x8...
Thanks, Dennis. The attached patch should implement this, once we:
through 2) Recompose the tree with it 3) Get a metalink generated pointing at that tree
This likely needs work in mirrormanager to work. when mm detects the repo things happen automatically in the background. if mm can not detect a atomic tree it will do nothing and there will be no metalink url
Previously the location was discussed and I thought most of the stakeholders had agreed to keep the Atomic trees on alt.fp.o, not on mirrors. Was this change (putting trees on mirrors) discussed with the other stakeholders?
The reason I ask is that it appears that, for clients to use a metalink, additional work is required on MirrorManager, which wasn't planned.
As we mentioned in IRC, alternately this stuff can sit on mirrors and not be used (yet?) until we have those changes made. But we definitely need it on a specific location (alt.fp.o) as well, so Colin can point to that for now.
I assume this location can safely be changed later, once we have other MirrorManager capability (either fixes in MM1 or, more likely, MM2) available?
- Do some end-to-end testing of this
-
Colin Walters -
Dennis Gilmore -
Luke Macken -
Matthew Miller -
Paul W. Frields