[openstack-dev] [storlets] Docker images re-structuring

kajinamit at nttdata.co.jp kajinamit at nttdata.co.jp
Thu Jun 30 05:03:15 UTC 2016


Hi Eran,


Thank you for bringing up a great idea.

> 1. Much easier to upgrade.
> 2. Less time from fix to test.
That's a big problem I experienced in my testing.
Storlet agent should be managed by infra operator side,
not by application developer side, as a part of infra software.

It's a little bit strange and hard work for system operators,
to ask all application developers to upgrade their container
when infra software is updated.

Your idea seems to show the appropriate way to go.

As I discussed with you in the last irc meeting(yesterday),
We should be careful about the runtime on which storlets stuff
works. (jre and python)
IMO, they should also be managed by infra side, and placed outside
docker container.

We have to consider some more things to realize the idea,
but anyway it makes much sense to me!

Thank you,
Takashi

-----Original Message-----
From: eran at itsonlyme.name [mailto:eran at itsonlyme.name] 
Sent: Tuesday, June 28, 2016 6:05 PM
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] [storlets] Docker images re-structuring

Currently, our Docker images are built form the following layers:
1. Ubuntu 14.04
2. JRE 8
3. Storlets stuff
4. Dummy layer having the tenant id as a name.

Only yesterday (after more then 2 years...), it occurred to me that the 3rd layer is a bit of a (understatement) mistake. Why not place the storlets stuff (daemon_factory, SDaemon, SCommon, etc.) in a read only mountable volume?

Pros:
1. Much easier to upgrade.
2. Less time from fix to test.
3. Less disk space that is wasted on Docker images as upgrades accumulate.

Thoughts?

Thanks,
Eran


__________________________________________________________________________
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



More information about the OpenStack-dev mailing list