Open Stack

Hello Denis,
unfortunately, I don't have deep knowledge of Zun so i can speak from Glare
side only.
So Glare can serve as some kind of artifact storage for container files but
we need to define artifact structure first.
Please note that artifact is immutable after activation so once you need to
change some files you need to create new artifact.
Also there is possibility to store container images in Glare also but this
requires an integration from Zun to consume blobs from Glare.
So it requires some improvements outside Glare.

Best regards,
Kairat Kushaev

On Tue, Dec 13, 2016 at 8:16 PM, Hongbin Lu <hongbin.lu at huawei.com> wrote:

> Denis,
>
>
>
> Per my understanding, container image building is out of the scope of the
> Zun project. Zun assumes an image has been built and uploaded to a image
> repository (i.e. Glance, docker registry), then the image will be pulled
> down from the repo to host. However, feel free to let us know if anything
> else we can do.
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> *From:* Denis Makogon [mailto:lildee1991 at gmail.com]
> *Sent:* December-12-16 4:51 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [Zun][Glare][Glance] Building Docker images
>
>
>
> Hello to All.
>
>
>
> I’d like to get initial feedback on the idea of building Docker images
> through Zun involving Glare as artifactory for all static components
> required for image.
>
>           So, the idea here is in being capable to build a Docker image
> through Zun API with storing all static data required for docker image
> building in Glare or Swift. In order to keep the same UX from using Docker
> it would be better to use Dockerfile as description format for image
> building.
>
>           In image creation process Glare could take role of artifactory,
> where users stores, let’s say source code of his applications that would
> run in containers, static data, etc. And those artifacts will be pulled
> during image creation and used to inject into image (similar process of
> context creation during Docker image building using native CLI). Please
> note that artifacts are completely optional for images, but would give a
> capability to keep artifacts in dedicated storage instead of transferring
> all data through Zun API (the opposite concept to Docker build context).
>
>
>
>           Once image is created, it can be stored in underlying Docker in
> Zun or can be published into Glance or Swift for further consumption (if
> user will need to save image, he’ll use Glance image download API). I’ve
> mentioned Swift VS Glance because Swift has concept of temp URLs that can
> be accessed without being authorized. Such feature allows to use Swift as
> storage from where possible to export image to Docker using Import API [1].
>
>
>
>
>
> Any feedback on the idea is appreciated.
>
>
>
> Kind regards,
>
> Denis Makogon
>
>
>
> [1] https://docs.docker.com/engine/reference/commandline/import/
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161216/3394252a/attachment.html>