Contributors mailing list archives
Re: Odoo Operator PSCby
You see from my previous mail: Lots of hands and brains still needed. - That's a very warmly welcoming invitation! :-)El sáb., 23 feb. 2019, 6:07 a.m., David Arnold <email@example.com> escribió:My thought about license is in line with Graeme's comment. Maybe it is wise to prepend an interpreting comment to clarify that the Operator is no dependency of Odoo itself. (It's already in the license commit)If somebody will build a SuperSaaS on top of it, then things might look quite differently, though.The idea of the operator is not so much about code, it's about a starting point for sharing and fostering reified core sysadmin knowledge.As a roadmap:- Link with Stolon / Patroni (not CrunchyData, because while it's the first and most feature complete it's not the future's choice)- Link with SSO upstream operator (keycloak?)- Link with a mailhog operator (or incorporate mailhog ops)- Link with HackMD (Etherpad drop in, module needed)- Link with mattermost upstream operator (Chat, ok Odoo is great, but matter most is greater)- Maybe link with OnlyOffice operator- Incorporate Shopinvader operator- Add varnish caching after the LB (don't mix LB and caching layer) - enables CNAMEing from untrusted client's DNS instances.- Adopt modules for Redis Session store (in memory, distributed)- Adopt distributed FS for filestore- Develop a /metrics endpoint module for Odoo metrics (Prometheus scraping)- Implement helpers for computing "on the edge" (k8s deployment in sub standard client's "Datacenter")- metrics based auto scaler- cluster federationMost lower level features are already done (POC! No tests) like:- Init (with SQL strings and acsone's dB templating)- Copy (for a testing dB operator)- Migrate (based on dodoo migrate, an adoption of marabunta)- Backup (with rsync based filestore snapshots, "naive" delta backups)- Let's Encrypt cert provisioning- DB namespace creation- hostname based L7 routing- Independent scalability of http server, longpolling, and cron- multi level config, cluster scope, track scope, version scopeEl vie., 22 feb. 2019, 9:37 p.m., Graeme Gellatly <firstname.lastname@example.org> escribió:
This isnt a module and doesn't link to odoo so compatibility of licence highly unlikely to be an issue.On Sat, 23 Feb 2019, 2:27 PM Eric Caudal, <email@example.com> wrote:
The only requisit on license is that it is OSI compatible. Usually LGPL or AGPL are usual good fit but there are many others (they must be compatible with Odoo LGPL license for modules linked to it).
AFAIR we have never had a dual license before and not sure about constraints.
Eric Caudal [Founder and CEO] - Shanghai Elico Limited
Skype: elico.corp - Phone: + 86 186 2136 1670 (Cell) // + 86 21 6211 8017/27/37 (Office)
More information: https://www.elico-corp.com
Odoo Gold Partner // Best Odoo Partner APAC 2014, 2016 and 2018!
On 2019-02-22 8:07 p.m., Kiril Vangelovski wrote:
Not sure if it is a per-requesit for submitting it to the OCA. The CLA doesn't have such a requirement. However this can simply become hard to put into practice if there will be other contributors who may not agree for their work to be licensed differently.
If it is not an issue though to keep it in a single license I don't see why this shouldn't be accepted. Maybe someone who has the authority can check and comment.
On 22.2.19 00:22, David Arnold wrote:
Thanks Kiril, true.Luckily I still can change that. :-)
Thanks for pointing this out. I assume its a pre-req to move the work towards OCA.
El jue., 21 feb. 2019, 6:07 p.m., Kiril Vangelovski <firstname.lastname@example.org> escribió:
I think that having a Kubernetes based deployment automation tool for Odoo is great and it would be good if there is such a project in the OCA.
I saw that there is an alternative licensing option. I don't think it is possible to distribute in dual license if you are to accept contributions and have other copyright holders beside yourself.
On 21.2.19 23:22, David Arnold wrote:
Thank you for this flamboyant pladoyer!
Said. Done. What is the next step? Can sombody from the OCA veterans orientate me in the right direction?
I was planning to finish the operator development under full light and public scrutiny in an OCA repository.
While being clear on that it's still incubating.
I think: In a process of consolidating those patterns, the earlier we can lay the ground for sufficient amount of mind share the stronger we can grow the final solution.
Sidenote: While CrunchyData is exciting, the really exciting stuff is this issue: https://github.com/envoyproxy/envoy/issues/2861 ->Lift psql domain specific load balancing into the LB / mesh layer of the infrastructure stack.
Most of what's possible is already there in this feature branch: https://github.com/xoe-labs/odoo-operator/tree/feat/implement-instance-controller
I'm only missing a varnish cache and some 12-factor readiness for a pretty decent POC... :-)
I have to say, I strongly support this idea. We are talking about Kubernetes here, the Operator Framework by CoreOS / RedHat is a set of tools designed to industrialize maintenance operations around dockerized applications. For example managing new deployments, base backup/restore, migration etc... without having to have the needed tools inside the base docker image of the application.
The Operator Framework is becoming increasingly popular for such usage and I believe the Odoo community should follow the trend, this is probably part of the future of DevOps. Note that RedHat is now one of the main influencing company inside the Kubernetes community, what they are doing is very interesting to follow.
For more advance and mature reference but still on a example which matter to us, I invite you to have a look at the Crunchy Postgres Operator https://github.com/CrunchyData/postgres-operator. Looking at the features here would probably give you an idea of what would be possible in an Odoo context.
For what I know, there isn't a docker base image recommended by the OCA, there are some popular ones but very different since not everybody agree on the best design. Operators are probably the next generation of base image, having one endorsed by the OCA at such an early stage would probably help to avoid the same situation in the future.
Le 21/02/2019 à 13:46, David Arnold a écrit :
Sure: it's work based on the CoreOS (now RedHat/IBM) Operator pattern and can be found here: https://github.com/xoe-labs/odoo-operator
Please note: It's incubating / early alpha.
Hello David, Could you share some insight, such as maybe what the repository is about? "The Operator front" does not ring any bell for me... Alexandre On 21/02/2019 05:31, David Arnold wrote: > Hi all, > > I'd like to propose to transfer the work I'm advancing on the Operator > front into an OCA/odoo-operator repository. > > Any objections or considerations? > > Best Regards, > > David A. > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > Post to: mailto:email@example.com > Unsubscribe: https://odoo-community.org/groups?unsubscribe >-- Alexandre Fayolle Chef de Projet Tel : +33 4 58 48 20 30 Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac Cedex http://www.camptocamp.com-- Lambda IS DOOEL - free/libre information systems service provider Kiril Vangelovski - consultant/developer web: https://www.lambda-is.com tel: +38971753823-- Lambda IS DOOEL - free/libre information systems service provider Kiril Vangelovski - consultant/developer web: https://www.lambda-is.com tel: +38971753823