Skip to content

Add support for submessages in template - part1. #1617

Merged
guptasu merged 2 commits intoistio:masterfrom
guptasu:submessages3
Nov 14, 2017
Merged

Add support for submessages in template - part1. #1617
guptasu merged 2 commits intoistio:masterfrom
guptasu:submessages3

Conversation

@guptasu
Copy link
Copy Markdown
Contributor

@guptasu guptasu commented Nov 9, 2017

What this PR does / why we need it:
Note this is part 1 of sub message support. It is based on the proposal https://docs.google.com/document/d/1GL_EOitfBJDfgbQJOSROceK5RdqNPuiggeAebaNqyf8/edit#
This PR contains the code generation for the go Instances and the augmented proto messages (Type and InstanceParam)

Part 2 (following PR) will contain the bootstraping code generation (code that runs at run-time, inside Mixer framework and instantiates these sub-message artifacts generated in this PR).

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #

Special notes for your reviewer:

Release note:

supports submessages inside the Mixer Template system.

@guptasu guptasu changed the title Add support for submessages in interface generation. Add support for submessages in template - part1. Nov 9, 2017
Copy link
Copy Markdown
Contributor

@douglas-reid douglas-reid left a comment

Choose a reason for hiding this comment

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

There's a lot going on here, but it looks reasonable to me. Just a few very small questions.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

fwiw: you can use raw string literals if you would like to avoid escaping nested quotes.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

should Resource1 be referenced anywhere? what is this testing? Is this just verifying that all messages within the proto file get types and instance params, etc. ?

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.

So, every message in the proto will have an equivalent *InstanceParam and *Type. For simplicity I choose to generate these artifacts for every message irrespective if they are reachable from the parent 'Template' message or not. We can certainly traverse from the Template and only include what is reachable, however, doing it the existing way is simple and I hope people just don't write dead messages (not referenced from anywhere). The Template developer should be a reasonable person :-), and will fix the dead message if he/she accidentally defines any.

Thoughts ?

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.

As you stated in your comment, this PR and the test is testing what gets generated for Go Instances, Type and InstanceParam messages.

Copy link
Copy Markdown
Contributor

@geeknoid geeknoid left a comment

Choose a reason for hiding this comment

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

lgtm

Copy link
Copy Markdown
Contributor Author

@guptasu guptasu left a comment

Choose a reason for hiding this comment

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

@douglas-reid PTAL. I have addressed your comments.

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.

So, every message in the proto will have an equivalent *InstanceParam and *Type. For simplicity I choose to generate these artifacts for every message irrespective if they are reachable from the parent 'Template' message or not. We can certainly traverse from the Template and only include what is reachable, however, doing it the existing way is simple and I hope people just don't write dead messages (not referenced from anywhere). The Template developer should be a reasonable person :-), and will fix the dead message if he/she accidentally defines any.

Thoughts ?

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.

As you stated in your comment, this PR and the test is testing what gets generated for Go Instances, Type and InstanceParam messages.

@yutongz
Copy link
Copy Markdown
Contributor

yutongz commented Nov 10, 2017

/test istio-presubmit

@douglas-reid
Copy link
Copy Markdown
Contributor

/lgtm

@istio-merge-robot
Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: douglas-reid

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these OWNERS Files:

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

…l contain the bootstraping code generation (code that constructs the recurrsive submessages)
@guptasu guptasu merged commit c349b99 into istio:master Nov 14, 2017
yutongz added a commit that referenced this pull request Nov 14, 2017
sebastienvas pushed a commit that referenced this pull request Nov 14, 2017
istio-merge-robot pushed a commit that referenced this pull request Nov 16, 2017
Automatic merge from submit-queue.

Fix submessage support part1

**What this PR does / why we need it**:
NOTE: The changes in this PR were already approved by @douglas-reid @geeknoid. Old PR contained 12 files (#1617) but was reverted because of missing 2 generated pb.go file. I have added the missing 2 generated file in this PR (this PR therefore contains 14 files).

Note this is part 1 of sub message support. It is based on the proposal https://docs.google.com/document/d/1GL_EOitfBJDfgbQJOSROceK5RdqNPuiggeAebaNqyf8/edit#
This PR contains the code generation for the go Instances and the augmented proto messages (Type and InstanceParam)

Part 2 (following [PR](#1702)) will contain the bootstraping code generation (code that runs at run-time, inside Mixer framework and instantiates these sub-message artifacts generated in this PR).

**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #

**Special notes for your reviewer**:

**Release note**:

```release-note
none
```
SRohitRaj pushed a commit to SRohitRaj/Istio that referenced this pull request Jun 7, 2024
Automatic merge from submit-queue.

Fix submessage support part1

**What this PR does / why we need it**:
NOTE: The changes in this PR were already approved by @douglas-reid @geeknoid. Old PR contained 12 files (istio/istio#1617) but was reverted because of missing 2 generated pb.go file. I have added the missing 2 generated file in this PR (this PR therefore contains 14 files).

Note this is part 1 of sub message support. It is based on the proposal https://docs.google.com/document/d/1GL_EOitfBJDfgbQJOSROceK5RdqNPuiggeAebaNqyf8/edit#
This PR contains the code generation for the go Instances and the augmented proto messages (Type and InstanceParam)

Part 2 (following [PR](istio/istio#1702)) will contain the bootstraping code generation (code that runs at run-time, inside Mixer framework and instantiates these sub-message artifacts generated in this PR).

**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #

**Special notes for your reviewer**:

**Release note**:

```release-note
none
```
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.

7 participants