Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update testInfo.go #502

Merged
merged 1 commit into from
Jul 26, 2017
Merged

Update testInfo.go #502

merged 1 commit into from
Jul 26, 2017

Conversation

sebastienvas
Copy link
Contributor

No description provided.

@istio-testing
Copy link
Collaborator

@sebastienvas: The following test failed, say /retest to rerun them all:

Test name Commit Details Rerun command
prow/istio-presubmit.sh 1701240 link @istio-testing bazel test this

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@sebastienvas sebastienvas merged commit f0d452d into master Jul 26, 2017
@sebastienvas sebastienvas deleted the sebastienvas-patch-2 branch July 26, 2017 05:10
@istio-testing
Copy link
Collaborator

Jenkins job istio/presubmit passed

mandarjog pushed a commit to mandarjog/istio that referenced this pull request Oct 30, 2017
* Introduce preprocess step into the mixer dispatch.

This PR adds a Preprocess() method to the AspectDispatcher. This
method (and the associated logic used to invoke it before other
mixer dispatch for Check, Report, and Quota) will be used to
execute Aspects that must preceed all further processing. Example
uses include: environment-specific attribute generation and
identity-related tasks.

Attributes generated in preprocess step will be merged back in
with the original request bags and passed to the existing
dispatch methods.

Currently, there are no existing Aspects that are associated
with the preprocess step (as a result, it acts as simple
pass through). A new aspect kind was added, primarily for testing
purposes. However, it is expected that that aspect will be used
in follow-on PRs.

Note: it is expected that the preprocess aspects will behave and
be configured in the exact same manner as other aspects. However,
in subsequent PRs, we may want to limit restrict the ability to
configure some of these aspects to only be globally-configurable
to prevent possibly conflicts between selectors and the attributes
they depend on. More thinking is needed here. For now, this potential
problem is left alone.

* Add ResolveUnconditional to Resolver interface.

This adds a ResolveUnconditional method to get around issues with
multiple calls to Resolve potentially introduced by Preprocess. This
will allow configuration of Preprocess aspects in ServiceConfig, as
long as that configuration is unconditional (has a selector of "").

This allows introduction of attribute generation adapters in a manner
consistent with the rest of the adapter subsystems (does not require
API changes, etc.).

Former-commit-id: efaac34fc2b79dfa90647c2c6c759b1f9815f52c
rshriram pushed a commit that referenced this pull request Oct 30, 2017
mandarjog pushed a commit that referenced this pull request Oct 31, 2017
* Introduce preprocess step into the mixer dispatch.

This PR adds a Preprocess() method to the AspectDispatcher. This
method (and the associated logic used to invoke it before other
mixer dispatch for Check, Report, and Quota) will be used to
execute Aspects that must preceed all further processing. Example
uses include: environment-specific attribute generation and
identity-related tasks.

Attributes generated in preprocess step will be merged back in
with the original request bags and passed to the existing
dispatch methods.

Currently, there are no existing Aspects that are associated
with the preprocess step (as a result, it acts as simple
pass through). A new aspect kind was added, primarily for testing
purposes. However, it is expected that that aspect will be used
in follow-on PRs.

Note: it is expected that the preprocess aspects will behave and
be configured in the exact same manner as other aspects. However,
in subsequent PRs, we may want to limit restrict the ability to
configure some of these aspects to only be globally-configurable
to prevent possibly conflicts between selectors and the attributes
they depend on. More thinking is needed here. For now, this potential
problem is left alone.

* Add ResolveUnconditional to Resolver interface.

This adds a ResolveUnconditional method to get around issues with
multiple calls to Resolve potentially introduced by Preprocess. This
will allow configuration of Preprocess aspects in ServiceConfig, as
long as that configuration is unconditional (has a selector of "").

This allows introduction of attribute generation adapters in a manner
consistent with the rest of the adapter subsystems (does not require
API changes, etc.).

Former-commit-id: 685455cc638473da2b0442e6f69d5356cbca45ec
vbatts pushed a commit to vbatts/istio that referenced this pull request Oct 31, 2017
mandarjog pushed a commit that referenced this pull request Nov 2, 2017
guptasu pushed a commit to guptasu/istio that referenced this pull request Jun 11, 2018
kyessenov pushed a commit to kyessenov/istio that referenced this pull request Aug 13, 2018
howardjohn pushed a commit to howardjohn/istio that referenced this pull request Jan 12, 2020
* automtls aspect in the enable mesh tls.

* make gen
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.

None yet

3 participants