Contributors mailing list archives

Ok, let me try to defeat the maturity argument, which backs both negative votes.

 

We all agree, it's about the most beneficial approach for the OCA ecosystem, as a whole. Left alone individual motivations, I understand the options for promoting the common interest are:

- Wait and observe / monitor (passive option)

- Push forward / endorse (active option)

Being antagonists, both options have their pro and cons:

Passive option pros -> Active option cons:

- Keep tech neutrality

Passive option cons -> Active option pros:

- Makes it easier for siloes ("different approaches") to stay in place

- Doesn't get the space moving (consolidation / mind share)

- Doesn't stir up awareness for the topic

We might agree, that in a space where ecosystems compete, the odds are high for OCA of not putting this important and, yes, "hip" topic high on the official agenda.

I understand, though, that for a healthy ecosystem particular interests need also be preserved, so it's a balancing act.

In my opinion, multilateralism is the best blueprint which expressedly reconciles those tiny words "as well as" in a broader inclusive strategy.

To my criterion, nothing of strategic relevance indicates that GitHub OCA organisation should be an "as well as" - free zone.

This means a multilateral approach within the GitHub organizations would buy us the best of both, and goes one step ahead of "just" a page listing.

Additional comments:

On a word of the literal meaning on the argument of maturity:

- Looking at factual adoption rates, I guess it's pointless to argue about the maturity of kubernetes (which is what we are talking about here, specifically).

- The rest is just (small amounts of) noisy scripting: I guess it's pointless to argue weather it is mature or not to express an idea or concept in English, German, French, Spanish, or what ever language you speak. It doesn't say anything about the maturity of the idea / concept itself. 

Closing in on this aspect, OCA would have it's very particular ontology in order to make the maturity argument a solid one. But it does not.

I built the core operator capabilities around Stephane's / Acsone's approach of enhancing Odoo through click-odoo server extensions. Yes it's a fork, but that's only due to the need for control over the tool's life cycle at this point in time, as all parts still evolve fast. Constant upstream feedback is provided.

This is a distinct feature: you can rip them apart and use them in your favorit scripting language, be it French, German, Spanish, etc.

The main motivation, though, to expose the same interface to the automated and the human operator.

El mié., 27 mar. 2019, 4:53 a.m., Jairo Llopis <jairo.llopis@tecnativa.com> escribió:

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 (<stephane.bidoul@acsone.eu>) 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,

-sbi

On Thu, Mar 21, 2019 at 2:52 PM David Arnold <dar@xoe.solutions> 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 <dar@xoe.solutions> 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 <dar@xoe.solutions> 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 <dar@xoe.solutions> 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 federation

Most 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 scope

El vie., 22 feb. 2019, 9:37 p.m., Graeme Gellatly <gdgellatly@gmail.com> 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, <eric.caudal@elico-corp.com> wrote:

Hi,

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.

Kiril

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.

Best,

David A.

El jue., 21 feb. 2019, 6:07 p.m., Kiril Vangelovski <kiril@lambda-is.com> escribió:

Hi David,

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.

Kind Regards,

Kiril Vangelovski

 

On 21.2.19 23:22, David Arnold wrote:

Yannick, 

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... :-)

Best Regards,

David A.

On Thu, Feb 21, 2019 at 5:02 PM Yannick Buron <yannick.buron@gmail.com> wrote:

Hello all,

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 :

Hi Alexandre,

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.

Best Regards,

David A.

El jue., 21 feb. 2019, 7:37 a.m., Alexandre Fayolle <alexandre.fayolle@camptocamp.com> escribió:

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:contributors@odoo-community.org









> 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

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

-- 
Lambda IS DOOEL - free/libre information systems service provider

Kiril Vangelovski - consultant/developer 

web: https://www.lambda-is.com
tel: +38971753823

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

-- 
Lambda IS DOOEL - free/libre information systems service provider

Kiril Vangelovski - consultant/developer 

web: https://www.lambda-is.com
tel: +38971753823

_______________________________________________

Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Jairo Llopis

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe