Skip to content

Use docker images and newer tag, add vanilla example to echo app#56

Merged
andraxylia merged 3 commits intomasterfrom
installation
Mar 17, 2017
Merged

Use docker images and newer tag, add vanilla example to echo app#56
andraxylia merged 3 commits intomasterfrom
installation

Conversation

@andraxylia
Copy link
Copy Markdown
Contributor

@andraxylia andraxylia commented Mar 17, 2017

#52


This change is Reviewable

@andraxylia andraxylia changed the title Fix typos Use docker images and newer tag Mar 17, 2017
Copy link
Copy Markdown
Member

@rshriram rshriram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And can we please change the SHA to date time tag format?

[{
"name": "iptables",
"image": "gcr.io/istio-testing/init:demo",
"image": "docker.io/istio/init:ceade42",
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the sake of sanity and consistency, can we have one single uber script in the root folder whose job is to figure out the latest stable SHA from dockerhub and stick that into every image? Better still, we could automate this update with @limawhite PR so that we don't end up having different versions of images. Something like istio:stable branch

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just FYI. There is a simple curl API to docker hub that allows one to query the tags for an image.


**Install Istio infra**
**Install Istio control plane and management plane**

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we can debate about control can management plane differences, the main architecture diagram shows a single control plane. Not two separate things. This makes it sound like we have too many moving parts. I suggest we stick to standard control plane, a terminology commonly used in the software defined networking and familiar to many.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Especially for those coming from networking background, the separation is important.

Shall we go back to infra?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In our case, we do not have a management plane yet. Manager and mixer are still control plane elements, configuring the network of proxies or controlling traffic. A true management plane is the API layer and associated set of UI services, toolchain services (ci/cd), etc. that is the plane the user interacts with, provides the configs etc. and that's the plane that kicks off staged rollouts (of versions or configs), does sanity checks, etc etc.

If you are referring to the networking model of setting up snmp, ssh etc to configure the routers, then that totally doesn't apply to us. Networking management plane is out of band access to the devices in data plane, does not have to touch SDN control plane to manipulate forwarding rules. Istio management plane should always go through the control plane to ensure consistent, validated and safe access to the istio deployment as a whole. Out of band access would negate all safeguards we have.

Our control plane, like SDN control plane consists of an entity that sets up forwarding tables proactively. It also does policy enforcement on the data path (still control plane).

Our management plane would be the tools we deploy on top of istio control plane.
My two cents.

And istio infra sounds too colloquial. Infrastructure doesn't seem to fit well in this context given that the term is already used to typically mean the underlying cloud infrastructure.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was referring to an Software Defined Networking model, not to SNMP, this is 2017. Management plane does not access devices directly, this is an anti-pattern.

Maybe the api layer is not yet fully exposed in the Istio code, but the config is there, and the design contains the management plane, so I will not restrict the naming to control plane.

I will call it Istio core, since it contains the logically centralized components.

@@ -7,11 +7,11 @@

kubectl config set-context `kubectl config view | grep current-context | awk '{print $2}'` --namespace <ns>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file could be renamed to Readme.md to avoid linking to specific doc

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok.

containers:
- name: mixer
image: gcr.io/istio-testing/mixer:6655a67
image: docker.io/istio/mixer:20e36eb
Copy link
Copy Markdown
Contributor

@frankbu frankbu Mar 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't there a more recent mixer build we should be using? I was having trouble with this particular sha (20e36eb) anyway - @mandarjog said that access-logs and application-logs are broken.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the latest. I will check on slack.

@andraxylia
Copy link
Copy Markdown
Contributor Author

I will change the files to use the date format, until "stable" is available.

@andraxylia andraxylia requested a review from kyessenov March 17, 2017 19:05
@andraxylia andraxylia changed the title Use docker images and newer tag Use docker images and newer tag, add vanilla example to echo app Mar 17, 2017
@andraxylia andraxylia merged commit b1b2359 into master Mar 17, 2017
rshriram pushed a commit that referenced this pull request Oct 30, 2017
Use docker images and newer tag, add vanilla example to echo app

Former-commit-id: b1b2359
mandarjog pushed a commit that referenced this pull request Nov 2, 2017
Use docker images and newer tag, add vanilla example to echo app

Former-commit-id: b1b2359
kyessenov pushed a commit to kyessenov/istio that referenced this pull request Aug 13, 2018
deva26 pushed a commit to deva26/istio that referenced this pull request Jun 24, 2020
shonecyx pushed a commit to shonecyx/istio that referenced this pull request Dec 24, 2021
* Protego cert integration (istio#56)

* Move microvault to 9080 to avoid conflict (istio#64)

* Add chart variable for mounting optional Secrets

When protego is enabled, hedwig mutationwebhook will report error if optional
Secret doesn't exist, so current template doesn't mount them at all.

For primary-remote multi-cluster setup, primary istiod needs both protego and
CA certs, this change adds additional variables to mount it.

* sidecar microvault need writable /tmp

Co-authored-by: Tong, Jonathan(jotong) <jotong@ebay.com>
stevenctl pushed a commit to stevenctl/istio that referenced this pull request Jun 1, 2022
* ambient-mesh: uproxy l4 implementation with Envoy

Change-Id: Iefb47be59a4c59ed9606b3270db6110fcb007838

* remove separate uproxy bootstrap

Change-Id: Iaa283c918df606be002dd4070cdb2af415502cdb

* fix bootstrap

Change-Id: If0b7d12a135590bdb4f314cc4102d9ec693b72e0

* move uproxygen out of xds package

Change-Id: Ib4ff05d61ace6d08dfc0d4d8745543b1ef9087ec

* update proxy sha

Change-Id: I31dde0ec70fe2fecec5320e1416851f523827fae

* move uproxygen out of xds package

Change-Id: Ib4ff05d61ace6d08dfc0d4d8745543b1ef9087ec

xx

Change-Id: I8b47912164f0a09010789d1b01de327b8883ee95

* fix bootstrap

Change-Id: I12261733f7b746f7c938a19e9cbcc8482b9028b8

* allow sending empty endpoints

Change-Id: I9c515ff55690562ea1c2f5ea0e01aabd814ca82b

* update download uproxy script

Change-Id: I2c6c7d7a96637536ca9a9002e02d862d52e2ad4c

* update envoy

Change-Id: Ic4d76480ff1ab9e962b520381eb6fcaa7ba0dbd8

* fix node-local traffic on KinD

Change-Id: I92787c54a3a7b020c5f476cb5d9f38b0861ed037

* fix-proxy-sha

* super weird

* fix sha and repo

* add ISTIO_BASE_URL

* traffic example in readme

Change-Id: Ia63c7db5882ee549a0ef76c2ab0b917123175dfe

* update go-control-plane

Change-Id: Iedeb67f0485f0b5d888c8d23ab869cd599a51d2f

* gen

Change-Id: I2998e44861ea516ab0e8230da7f9102f811d4632

* fix uproxygen tests after rebase

Change-Id: Ia55ff16ca6a00fc992980a54da076feb6e6f8ad0

* add ambient controller

Change-Id: I6763a97e0696939f088b919162407569a8eb0ead

* fix pep deployer

Change-Id: I4887c43dd591940508b134cd35515bc0da912a66

* send traffic to pep

Change-Id: Ic78f6d6b356446721586f37fb8341d98dbb0f09f

* client pep working (pep node-local, server cross-node)

Change-Id: I1c8469c990e2d01a719bfe2c2f84a753fd3c98d4

* push xds when we update our known peps

Change-Id: I712fe404473b4cc23e5fce4165e99540606d13ec

* fix agent build

Change-Id: Ia6d4eda7827049d52b30238f655fe65cdb716a2d

* fix pep agent return and imports

* internal listener in envoy bootstrap

Change-Id: I0fa0dcd0a0cff399526de4c585ecba8202b66e6d

* use proxyv2 for pep and uproxy

Change-Id: I3600c2582d7f18f17a3990459d268ca74db360ea

* fix NACKs due to invalid matcher

Change-Id: Ie00f96b26983cbaa7c77629080473a03af49034f

* remove debug files

Change-Id: I65921405f5bb8b830ad794a1df1006b3f91f82d3

* refactor ambient discovery (istio#56)

* small fixes

Change-Id: I5b4311fc12962c6d985bdc80f74c0625651dc7c9

* copyright banners

Change-Id: I8a609db636c41dc148e7279d9d5b3a48591b9842

* fix tests for match repair

Change-Id: If2009405f67a1c214e46ec2c53a8f227980cffa4

* remove unused script

Change-Id: I0f8aa64285284069488f82021e1413fb29ca0285

* add old redirect script

Change-Id: Id220c20acfadf5fac012cf7c3c73a607039e1af0

* add NET_ADMIN to kind.localcontrolplane

Change-Id: I4312f437a0d7073c4cedf8e88a9e89671d29aa42

* fix outbound cluster name

Change-Id: Ia46d8367443e78754bc896687795a5fe091121db

* remove envoyFriendlyIdentity

Change-Id: I3d8a403bcbf2f5dde0a0374dd5784e9191751230

* clean up more naming stuff

Change-Id: I9137a6833929dd5e3708845b080d9dd4d77de379

* restore inbound changes to support tproxy

Change-Id: I952a717000fd7a77a069a4988ee36324b54e2a4a

* expand permissions; remove hardcoded discovery addr

Change-Id: I9823886e897fbcd1e040565494fd24d62f72ee89

Co-authored-by: EItanya <eitan.yarmush@solo.io>
Co-authored-by: Greg Hanson <gregory.hanson@solo.io>
stevenctl pushed a commit to stevenctl/istio that referenced this pull request Jun 1, 2022
* ambient-mesh: uproxy l4 implementation with Envoy

Change-Id: Iefb47be59a4c59ed9606b3270db6110fcb007838

* remove separate uproxy bootstrap

Change-Id: Iaa283c918df606be002dd4070cdb2af415502cdb

* fix bootstrap

Change-Id: If0b7d12a135590bdb4f314cc4102d9ec693b72e0

* move uproxygen out of xds package

Change-Id: Ib4ff05d61ace6d08dfc0d4d8745543b1ef9087ec

* update proxy sha

Change-Id: I31dde0ec70fe2fecec5320e1416851f523827fae

* move uproxygen out of xds package

Change-Id: Ib4ff05d61ace6d08dfc0d4d8745543b1ef9087ec

xx

Change-Id: I8b47912164f0a09010789d1b01de327b8883ee95

* fix bootstrap

Change-Id: I12261733f7b746f7c938a19e9cbcc8482b9028b8

* allow sending empty endpoints

Change-Id: I9c515ff55690562ea1c2f5ea0e01aabd814ca82b

* update download uproxy script

Change-Id: I2c6c7d7a96637536ca9a9002e02d862d52e2ad4c

* update envoy

Change-Id: Ic4d76480ff1ab9e962b520381eb6fcaa7ba0dbd8

* fix node-local traffic on KinD

Change-Id: I92787c54a3a7b020c5f476cb5d9f38b0861ed037

* fix-proxy-sha

* super weird

* fix sha and repo

* add ISTIO_BASE_URL

* traffic example in readme

Change-Id: Ia63c7db5882ee549a0ef76c2ab0b917123175dfe

* update go-control-plane

Change-Id: Iedeb67f0485f0b5d888c8d23ab869cd599a51d2f

* gen

Change-Id: I2998e44861ea516ab0e8230da7f9102f811d4632

* fix uproxygen tests after rebase

Change-Id: Ia55ff16ca6a00fc992980a54da076feb6e6f8ad0

* add ambient controller

Change-Id: I6763a97e0696939f088b919162407569a8eb0ead

* fix pep deployer

Change-Id: I4887c43dd591940508b134cd35515bc0da912a66

* send traffic to pep

Change-Id: Ic78f6d6b356446721586f37fb8341d98dbb0f09f

* client pep working (pep node-local, server cross-node)

Change-Id: I1c8469c990e2d01a719bfe2c2f84a753fd3c98d4

* push xds when we update our known peps

Change-Id: I712fe404473b4cc23e5fce4165e99540606d13ec

* fix agent build

Change-Id: Ia6d4eda7827049d52b30238f655fe65cdb716a2d

* fix pep agent return and imports

* internal listener in envoy bootstrap

Change-Id: I0fa0dcd0a0cff399526de4c585ecba8202b66e6d

* use proxyv2 for pep and uproxy

Change-Id: I3600c2582d7f18f17a3990459d268ca74db360ea

* fix NACKs due to invalid matcher

Change-Id: Ie00f96b26983cbaa7c77629080473a03af49034f

* remove debug files

Change-Id: I65921405f5bb8b830ad794a1df1006b3f91f82d3

* refactor ambient discovery (istio#56)

* Base working with new manifests

Change-Id: I86b6ff97702231a98935a2808c3d3e0b63dbdd6b

* Client PEP working

Change-Id: Id2861dadd17f6d703691f8e62d46be075c307c13

* Basic cases working

Change-Id: Id8e5a4dbd123831e7ea95d9afdb7b91468cf56c6

* Per VIP CONNECT matchers

* Mostly passing tests, besides envoy issues

Change-Id: I13f41cee50a6e8251f0791168677f0cd1458f7f4

* more wip

* Inbound config generated but not used

Change-Id: I854de051fe444ac54fb10167776987647a36ee94

* All service cases passing

Change-Id: I5b96aaae42775a170cdc559e20dd336c457c05d5

* seemingly more working now

Change-Id: If594f13d4d8651a014f10a955cfb74c120a3ebd3

* Get remote inbound authz

Change-Id: I6315987c83f81de555e2afb936fe0f3ff9a7dd1a

* cleanup logs

Change-Id: I2b0f48cc487e089fa0cc22473a85a1bca5961955

* format

Change-Id: I2b94b6704f3003e6b6556c5735558ffaccfe2307

* cleanup

Change-Id: I12b94e3e2ab6d2af89773a24526ffa1dd85aeb4a

* fixes and logging

Change-Id: I09f8aadf48b9864312fb6e7c9bac063afc220eea

* Minor fixes and more debugging

Change-Id: Ie6c8b6cfc8fcd11ccf9324a744229c4ce3c02d49

* passing tests on kind

Change-Id: I913edc5009d79539275c7316c815408d9662c851

* Fix BPF

Change-Id: Id7ac69a9d2eceb0dc5e4ca95cbfc0a38f4653226

* refactoring

Change-Id: I1e9c38e7f3c471612110aeca2480bf40bb8f371f

* Support client PEP

Change-Id: I65f706bb265a8169522f42034b3df95f0183ed77

* Get probes and external traffic working

Change-Id: I6ea3330247dd4a3898884c32042baf234097d167

Co-authored-by: Steven Landow <landow@google.com>
Co-authored-by: EItanya <eitan.yarmush@solo.io>
Co-authored-by: Greg Hanson <gregory.hanson@solo.io>
antonioberben pushed a commit to antonioberben/istio that referenced this pull request Jan 29, 2024
support extraSecretMounts in query resource
asmigala pushed a commit to asmigala/istio that referenced this pull request Jul 24, 2024
…ase-1.22-merge_upstream_istio_release_1_22-b34c6a22

Automator: merge upstream changes to openshift-service-mesh/istio@release-1.22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants