Contributors mailing list archives
Re: Odoo Operator PSCby
I agree with Stéphane.+1 for the OCA web page publizicing the different deployment systems made by different OCA members.The cloud landscape is currently growing at very fast pace (just go see https://landscape.cncf.io/, some of them were "winners" some months ago, some are now... this is like npm for deployments), it's soon for OCA to endorse one officially.About language, I guess you'd have much more contributions if you made an Ansible operator instead of a Go one (although ansible operators didn't exist in the moment you started your project AFAIK... another reason this is still too soon).Regards.El jue., 21 mar. 2019 a las 15:21, Stéphane Bidoul (<email@example.com>) escribió:Hello David,I think it is premature to include such kind of project related to Odoo deployment in OCA.There are many different approaches out there, and it does not make much sense for OCA to endorse one or the other at this point in time.Except for additional visibility, including such projects in the OCA organization would not bring benefits to OCA nor the projects, as most OCA processes and none of the infrastructure would be applicable.Maybe later, when the landscape matures, but for now -1 from my side.In the meantime, I'd be happy that odoo-community.org would host a page with a directory of such initiatives, to help building communities.Best regards,-sbiOn Thu, Mar 21, 2019 at 2:52 PM David Arnold <firstname.lastname@example.org> wrote:Hi,I'd really reiterate and underline my interest in broadening this singular effort.The silent community of interested parties goes into the 100 members already (judging by riot.io and telegram group mebers), and many are looking forward to see this being adopted in a broader scene.I can understand that thise is something completely new to many, furthermore it's written in go. But as I have tried to argue already on a different occasion, this shall be no concern to OCA.In case of doubt, I'd argue we should open up such repo and observe the dynamic. Closing this possibility down out of (in a certain way) discomfort with the unkown would be contraproductive, in this instance.I think I'm well prepared to argue this proposal through all objections, so if there are any concerns, please speak out loud now to help progress this cause.Best Regards,David A.On Fri, Mar 8, 2019 at 2:02 PM David Arnold <email@example.com> wrote:Hi Board,Could anyone create OCA/odoo-operator and give me the necessary access? Or otherwise point me in the right direction?Best Regards,David A.El sáb., 23 feb. 2019, 6:23 a.m., David Arnold <firstname.lastname@example.org> escribió: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