[Container-tools] Creating a download location for ADB Vagrant boxes

[Daniel Veillard]

On Thu, Oct 08, 2015 at 09:12:04PM +0530, Lalatendu Mohanty wrote:
> On 10/08/2015 08:40 PM, Karanbir Singh wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >On 08/10/15 12:30, Lalatendu Mohanty wrote:
> >>so, 'try out' only ?
> >>>Nope. I should have used better words. Its for application
> >>>developers who will benefit using the Vagrant box (Refer the
> >>>Project Readme)
> >my take on that is that its meant for an onramp into an environment to
> >really do things.
> >
> >>the key being that if you want to provide the people on this
> >>mailing list with a very fast release cycle, perhaps nightly, so
> >>they can validate their own work rapidly V/s providing the wider
> >>contributor base V/s provider the wider userbase ( ! contributor
> >>).
> >>
> >>For the second two of those situations is where it makes sense to
> >>use centos.org resources, and then do quickstart guides,
> >>announces, mechanics from the CentOS side of things.
> >>
> >>I suspect the first of those groups is likely happy with a yum
> >>update in an established box, nightly ?
> >>
> >>>The kickstart file for the Vagrant box is changing . So its just
> >>>not yum update. Also we might want to change the default
> >>>Vagrantfile which comes with the Image (may be an enhancement to
> >>>image-factory or a separate script).
> >surely you dont mean to imply that every XX days you intend to orphan
> >every last one of the users who happens to have onramped with the last
> >box.
> 
> Nope, if a user follows  Vagrant way of updating the box , he/she will be
> fine. This process does not change for the ADB Vagrant box no matter where
> we put it.
> >
> >think of a release as features, the box is their way to get there, but
> >once there how are you going to maintain their work ? I dont think its
> >a great user experience if you are intending to force everyone to
> >update constantly, starting from scratch - specially when the box's
> >ship with no functional two way sync.
> 
> We are working on providing a 2 way sync or equivalent.
> >
> >how much of the payload in the box is coming from unpackaged content ?
> >that would be the biggest challenge here. the rest of the environment,
> >i suspect folks will live with.
> >
> Everything should be packaged properly. We have no plan to take un-packaged
> content.
> >>>Using CentOS resources fine with me. Actually that would be
> >>>welcome. However I guess we have to wait little more to get all
> >>>required resources [1]
> >>>[1]
> >>>https://lists.centos.org/pipermail/centos-devel/2015-October/013917.h
> >tml
> >
> >what
> >resources are you waiting for ?
> Honestly I dont have anything to add, apart from what I have mentioned in
> [1]
> 
> [1] https://lists.centos.org/pipermail/centos-devel/2015-October/013917.html

  To make it cristal clear we need a place where the ADB maintainers can
write the new images and export them via http. We can't do that on
cloud.centos.org , we can't reference the build system URL directly so
we need another spot. If that's not possible from a centos.org machine,
please tell us quickly so we plan accordingly.

  Thanks,

Daniel

-- 
Daniel Veillard      | Open Source and Standards, Red Hat
veillard at redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | virtualization library  http://libvirt.org/