forget the 2 last lines and locale-gen pt_BR.UTF-8 that could go in a sub-image.

So it means at Akretion, we have:

Devstep - Voodoo (for dev)

/

Heroku Cedarish

\

Herokuish - Odoocker (for prod, no Postgres inside)

These two Dockerfile are opiniated toward pre-fetching the recipe eggs (using the real setup.py of Odoo 7, 8 and 9) so that to spin Odoo on it you just need to run the bin/buildout of the Anybox Recipe (which is fast provided you set a few symlinks to the cached eggs. But that's a choice that is quite compatible with the OCA choice of using the Anybox recipe...

What is added atop of Heroku Cedarich (here behind herokuish) could be shared with others and OCA or not but that would assume people are ok to build atop of Cedarish (not what you do for instance).

But then that would be just 30 lines of shared bash including the eggs pre-fetching scripts for Odoo 7, 8 and 9. IMHO not worth making noise at the OCA for 30 lines of bash...

That would define a simple base image able to run Odoo (like you do without pre-fetching the recipe eggs and without using Cedarish).

In my opinion, at this stage any tool, aiming at doing more than that will assume very strong opinions such as;

docker compose at leats for dev?

or embedded posgres for dev?

production image instead?

way to deal with the postgres and other config params: dinosaur like Odoo or 12 factors instead?

and I think it's way to early to say some of these approaches are standard enough at the OCA level before things are battle tested by a community before. And also as I said different tools will serve different needs and different integrator businesses. That would be very pretentious to claim for the silver bullet container when this field see so much innovation today.

In fact this field evolve at a speed I don't believe the OCA would ever follow. That's why I say the OCA should focus on Odoo modules and now the recipe, nut anything past this is really a lot of trial and error by nature...

Hi Rafael,
I dont intend to store any docker in OCA: just docker files and
scripts as you suggest.
There might be several docker files level with different complexity
or customization or platforms. We might want to regulate it a bit
but we can see that later.
I like the docker with bare odoo but having a docker+postgres (like
voodoo) is a nice alternative (all-in-one windows like).
We will work with XCGD (and any contributor) on proposing solution
and directions for contribution.
Best regards

I think we wanted the same simplicity goal as you with
Voodoo. Still we made it complete enough so it really supports
our own complex projects at Akretion too... (like we really
like pinning revision using the Anybox recipe, and it's our
deliverable lingua franca as I explained etc...).

You have this firewalll issue in China. Here in Brazil our
issue is expensive servers. In France servers are so cheap
that their cost don't matter at all and the economy is around
customized projects. So you see, every use case will call
different solutions. At the end of the day, our Dockerfiles
will be different and reflect our very specific needs...

Now what could be maintained at the OCA IMHO are small
scripts that could be used inside these Dockerfiles, But I'm
not even sure...

We reuse that script both and the dev and production Docker
images for instance.

But may be even that is already too specific; I won't even
submit that to the OCA (and it's hacky too).

You may suggest maintaining the list of Debian dependencies
packages. But as we start our stacks for Heroku Cedarish we
would use only a fraction of it, so...

May be our dev Docker images will make use of OCA scripts
like to lint repos or launch OCA tests (or test the project in
a containairized Runbot)...

But overall, I see it more like we will share the libs used
by our Docker tools inside the OCA, not the final Docker tools
themselves, at least until there is some consolidation outside
of the OCA (if that happens with Voodoo, that wouldn't be a
problem on our side moving it to the OCA, but the plebiscite
should happen first, just like it happened with Anybox
Recipe).

Hi Rafael,
I will have to have a look at Voodoo ;).
My idea of docker is actually to keep it simple to allow
users to have a solid docker they can rely on without
needing a high level of install/setup. Only few commands
and go.
The second point is to allow the build of OCA docker
repository, always up to date and always available.
We have built a docker file that allows
oca_requirements.txt usage so that users can easily test
repos.
This kind of features will probably satisfy 95% of the
public and allow easy discovery of Odoo/OCA without
polluting environment.
NB: In our specific case (China), we have to struggle as
well with mirroring and docker mirroring works fine (from
> 12h to download a docker from abroad to 3 min when
using a mirror).
Anyway I agree with your approach and several tools might
meet several requirements.

I think deployment will have many peculiarities
depending on what want to achieve. Meanwhile a
Dockerfile such as presented by Eric is really
trivial to build and maintain (even accepting pull
in his repo), I don't see any benefit of the OCA
here... Even Voodoo which is a bit more engineered
is trivial to maintain...

That is different for the Anybox recipe because
it's still a large piece of software. And despite we
may use the recipe differently, many of us will
still use that part of the puzzle, so it makes sense
to have it in the OCA (even if I was ok keeping
Anybox in the name as I said).

Further, At Akretion we start using the Anybox
recipe as a deliverable lingua franca. Like we
happily host and make the infrastructure of our
customers. But if they prefer do it themselves or
work with other partners, we are OK as long as we
can deliver them a buildout.cfg, so at least it
means if they screw their production stack, that's
not us paying their mistakes.

Finally, I think Docker and the recipe complete
each other nicely and this is exactly what we do
with Voodoo. Think that instead of using Virtualenv,
we use a Dockerized virtualenv, but a voodoo project
repo is totally deployable with virtualenv as usual
for those who prefer. It's just we can get the
project up on any computer in just 5 minutes without
cluttering the developer small SSD disk with tons of
native dependencies.

I personnally see no issue with having
both in OCA. I've been using buildout since
long before docker existed, I depend on this
recipe for a large number of customers, and
this buildout recipe has gathered a
significant community.

I am committing to participating in the
maintenance it as long as I'm part of the
association. I can't say the same for a docker
based solution which is not part of the stack
I deploy for my customers, but I won't block
an initiative to maintain a docker based
solution in the OCA.

So
basically we have 2 out of 7 main
features that would high-lite in a
"diff docker anybox_recipt".
Couldn't those be spun out?

Obviously,
things are working well, are
stable and every one is accustomed
to this. But I feel, my question
if, on the long run(!), it is
sustainable
to maintain features inside the
resource-limited odoo community,
while other ecosystems solve them
probably 100 times better (because
they do nothing else).

I'm
just thinking loud because
everyone is complaining about not
having
the appropriate resources...

Just for the
record, I'm not
suggesting we should
make an exception in
this case, and I
certainly won't
force an exception
by abusing my commit
rights and
forcefully pushing
the module in the
OCA.

I've discussed things
with Georges this
afternoon and what I
proposed him was:

* we change the name of
the recipe

* we modify the original
recipe by publishing a new
version on pypi which will
be empty save for a
dependency on the new name
of the recipe

* we add a compatibility
entry point on the new
recipe with the old name in
order not to break existing
buildout files

and globally he is ok with
this.

I also feel such important
decisions (accepting a whole new
contribution etc.) deserve
public discussions, so I
launched the thread to tell the
community about this and give
everyone an opportunity to
discuss.

I defended the idea
that Odoo module should
not have a company name
because several
companies would too
easily work on the same
topic and changing a
module name has impact
in the database and
because it seems more
important to have a name
that reflects what a
module does.

Now, for things like
the Anybox recipe, I
think Anybox will have
done 90% of the work no
matter the help now.
It's not an Odoo module
and I don't see reasons
to be as strict. So for
me I would leave the
current name...

More generally,
overall I like what we
do with the OCA, but let
me tell I'm concerned
with the business model
of the thing: yes the
OCA receives some
donations, but
nonetheless 99% of the
R&D is invested by
the contributing
integrators themselves.

May be some large
integrators can do that
as pure give away, but
I'm not even sure. But
generally, I think the
model works IF AND ONLY
F: an integrator company
can get enough prestige
from having its work
accepted by peers at the
OCA, then this can be a
commercial advantage
just as large as
investing in marketing,
at least in some
rational high ends
markets. THEN the model
works and is
sustainable.

Now, if the OCA ends
up totally anonymising
and hiding who did some
work, if the OCA gives
the same visibilty to
somebody who created and
carried a project 5
years as somebody that
just helped over the
last 6 moths, then my
friends we are shooting
ourselves in the feets
big times... Because
what we get then, is a
some ugly lobbying to
fake some project
participation and hijack
the project credits, and
this is something
already happening.,.

So I hope the OCA
don't loose this
economics reality. And
this is for this reason
I would be totally ok
leaving the Anybox name
in this case...

I'm at the
PyconFR sprint
sitting next
to Georges
Racinet and a
number of
Anybox
contributors.

Georges
proposed a few
months ago to
share the
maintenance of
the anybox
buildout
recipe(s)
(openerp and
odoo) with the
community.
This was met
with approval
but as far as
I remember the
issue of the
name (our
policy says we
should not
have company
names in
module names)
was not
clearly
resolved.

1. I propose
the creation
of a new OCA
repository
OCA/buildout_recipe
under the
responsibility
of the Tools
project
steering
comittee. I
will make the
required PRs
to include the
anybox
recipes, once
the naming
issues are
resolved