See: https://lists.fedoraproject.org/pipermail/buildsys/2015-April/004604.html
TL;DR: There was a Change to have a Vagrant box for Cloud that was filed but got lost in a shuffle.
Please consider approving this for Fedora 22, it's very close to the Atomic Vagrant box.
Where is the Change? where was it lost? or was it just forgotten to be done. adding new deliverable post Beta is not something that we should ever consider. as I said to Ian, get a change in and we can do it for Fedora 23
https://fedoraproject.org/wiki/Changes/Vagrant_Box_Atomic
This is different from:
http://dl.fedoraproject.org/pub/alt/stage/22_Beta_RC1/Cloud-Images/x86_64/Images/*Vagrant*
?
We are now producing so many things with cloud, docker, atomic and vagrant in their name that it's become hard for me to follow. ;)
No worries, it is confusing. First, there is no Docker involved here.
Now, Vagrant itself is just a wrapper around hypervisor formats like qcow2/VirtualBox. A .box file is effectively those in a preconfigured format + metadata.
There should just be two - not 4. The .qcow2 and .raw.xz for Vagrant don't need to be shipped.
Now, under Cloud there are two products, the "mainline" and "Atomic" variants. Both can come as raw qcow2 or vagrant.
(Personally I'd drop the .raw.xz variants of the base in favor of just .qcow2 - anyone can convert the qcow2 to raw if they want)
It was decided to push this back to Fedora 23. The eve of an already slipped Beta Go/No-Go is too late.
What is the procedure now? That a new Change is created for Fedora 23, and it has to go through the whole approval process before the patch can be applied?
Sorry I missed the meeting to talk about this. I don't think this is really a late change, just one that got a little mixed up in submission and communication.
From a high-level point of view, I'd really like this. It gives a very nice talking point for Fedora Cloud, and one that ties into developer target users for Workstation -- and of course into the separate feature of having Vagrant itself in Fedora.
It's my understanding that the kickstart in the spins repo right now actually has been tested and works, and the deliverables are basically exactly in parallel to the Atomic vagrant boxes we're already producing.
Given that it's non-blocking but really nice to have, might it be possible to add this to the build scripts / deliverables for the test candidates for final (even though I recognize that it's far from ideal),and ship it if it works?
Replying to [comment:10 mattdm]:
Sorry I missed the meeting to talk about this. I don't think this is really a late change, just one that got a little mixed up in submission and communication. From a high-level point of view, I'd really like this. It gives a very nice talking point for Fedora Cloud, and one that ties into developer target users for Workstation -- and of course into the separate feature of having Vagrant itself in Fedora. It's my understanding that the kickstart in the spins repo right now actually has been tested and works, and the deliverables are basically exactly in parallel to the Atomic vagrant boxes we're already producing. Given that it's non-blocking but really nice to have, might it be possible to add this to the build scripts / deliverables for the test candidates for final (even though I recognize that it's far from ideal),and ship it if it works?
<grumble a lot about asking for something that was already asked for and answered. again.>
Yeah, sorry -- I missed the meeting, as I said, and from the log, it doesn't look like there was much discussion or input, and this ticket doesn't provide much context on its own.
To represent Fedora as a proper developer's workstation, Vagrant images are very important. Most of the web-developers who use many different OS in their workstations, use Vagrant as the way to streamline their development, and deployment processes.
It is an important change, it will be good if FESCo can approve this change for Fedora 22.
At the risk of making jwboyer grumble again... It's unclear to me from the ticket whether this was/is being done.
It was in the change request, and Ian and others have done the work to deliver the ks and such. It shouldn't be a major impact - and it's a big missing piece for the Cloud Working Group not to have a vagrant box for developers. (Well, boxes - kvm-based for Linux developers, VirtualBox for folks on Mac OS X or Windows.)
If this is already in the works, thanks! If not, consider this one more voice in support of squeezing this in so we don't go another release cycle without this. Thanks!
The Change was denied for F22 and the ticket is closed. Aside from walters, there wasn't much representation from the Cloud SIG either before or during the meeting. Personally, I did not get the impression that this was very important.
There were concerns from Dennis on the rel-eng impacts, but they seemed to be feasible. There were concerns around shoving yet-another-thing out of process and late. There were other concerns around QA here. I'm going to assume the Cloud SIG is going to do QA of this completely if it were approved.
I can add this to the agenda again for the meeting next week, but it would be VERY helpful for everyone that cares about this to speak up and outline things in the ticket before the meeting. It would also be VERY helpful for FESCo members to comment in this ticket on their thoughts.
The reason I filed this ticket is I felt the issue was my fault for incorrectly obsoleting the Change https://fedoraproject.org/wiki/Changes/Vagrant_Box_Atomic
Another factor to consider here that I forgot to bring up in the meeting is that with Atomic being planned to move to its own distinct page, the mainline Vagrant box can be slotted in much more easily into the web page rather than creating a matrix.
So, beta is in the can, so this would not appear until after beta. It wouldn't get any of the testing or press from that.
There's a websites part to consider, but I would let them note how much work this might be.
Theres a small amount of releng work.
If QA isn't needing to test these there's no QA time involved. That said, it reflects on the entire project when we make something and distribute it and it's broken. We have done this in the past with spins and it's really something we should strive not to increase.
I won't be able to attend today's meeting.
If the work is already done, rel-eng and QA are OK with adding the vagrant box and if it will be tested by QA or Cloud SIG people (to make sure it is not shipped broken) then I can be +1 on this.
Otherwise I'm still -1. It is too late.
From a websites POV it's not that easy to get additional work, as we are working on three new websites for F22 GA.
Anyway, we have a webticket [1] where to put eventually the task(s) Cloud WG needs to get done. Actually (F22-Beta) we have vagrant images in the main download page [2] and links to vagrant Atomic images in the sidebar.
Replying to [comment:19 robyduck]:
From a websites POV it's not that easy to get additional work, as we are working on three new websites for F22 GA. Anyway, we have a webticket [1] where to put eventually the task(s) Cloud WG needs to get done. Actually (F22-Beta) we have vagrant images in the main download page [2] and links to vagrant Atomic images in the sidebar.
So, that sounds as it should be, but right now, it's actually the Atomic images in both places. The change would simply be to make the main one be the Cloud Base Vagrant images instead (presuming those are generated).
Hmm, seems I'm getting lost, sorry.
In the prerelease page (and vagrant images will go to the final DL page too) we have vagrant images for VirtualBox and KVM, in the sidebar we have the base raw atomic vagrant image and the qcow2 image. All 4 images ''should'' be build also for final.
For sure it can be done better and we could make something like we did for cloud base and openstack images, a JS which opens a small box with another Dl button. And that's not a big work, can be done easily if you want. But how would this look like if we get Atomic out of Cloud pages?
I think FESCo should first decide if this should have target F22 or F23, as it involves not only the websites. We can try to get all changes into the websites, as long as you're thinking about something like what we were talking about. Also, if Cloud WG provides text content and other stuff it's much easier for us to get it done the right way and with less time effort.
I just wanted to add website's situation into the discussion ;)
From today's FESCo:
Login to comment on this ticket.