Giter Site home page Giter Site logo

Comments (10)

smawson avatar smawson commented on September 25, 2024 3

I'm very worried about ecosystem fragmentation if we support multiple configuration APIs for istio. Having multiple config stores will also cause problems for the hybrid / multi-zone configuration model. So I don't think this makes sense to do.

Instead we should just run the istio config API inside cloud foundry, just like we do in all environments. I'd like to understand why that wouldn't be an option here.

from pilot.

kyessenov avatar kyessenov commented on September 25, 2024

cc @louiscryan @smawson

from pilot.

cmluciano avatar cmluciano commented on September 25, 2024

cc @xiaolanz for Config WG

from pilot.

cmluciano avatar cmluciano commented on September 25, 2024

cc @istio/pilot-hackers

from pilot.

shalako avatar shalako commented on September 25, 2024

In Istio Slack #cloudfoundry, @kyessenov said:

It seems to me in the same vein as consul/eureka/VM integration - it's fine for custom flags/deployment until we have a proper plugin model generalized in the config group. I would gladly accept contributions, but want to keep config group (@smawson and @louiscryan) in the loop for the architectural direction

Thank you!

from pilot.

rshriram avatar rshriram commented on September 25, 2024

This is cool. Looking forward to the PRs. I would suggest getting started with the concrete PRs for platform and config adapters. When the config story materializes, we can align the code, instead of waiting few months for the config system to land.

from pilot.

andraxylia avatar andraxylia commented on September 25, 2024

Can you please send the proposal to istio-networking email as well, with a pointer to the issue?

from pilot.

smawson avatar smawson commented on September 25, 2024

Following up on my comment, it sounds like etcd is the primary issue, we should see if we can resolve that in coordination with the config API group.

from pilot.

xiaolanz avatar xiaolanz commented on September 25, 2024

One possible config design is that each zone maintains a separate config store. There is only one "master Galley" exposing config API and rolling out configs to all the zones. The zone-local config store is pluggable, which can be either in etcd or other implementations.

This way, we don't need to deal with multi-zone distributed config convergence. Each zone will get the performance benefit from local config access.

from pilot.

kyessenov avatar kyessenov commented on September 25, 2024

Issue moved to istio/istio #1378 via ZenHub

from pilot.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.