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

[HLRC] Added support for CCR Get Auto Follow Pattern apis #36049

Merged

Conversation

martijnvg
Copy link
Member

This change also adds documentation for the Get Auto Follow Pattern API.

Relates to #33824

This change also adds documentation for the Get Auto Follow Pattern API.

Relates to elastic#33824
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features

Copy link
Contributor

@hub-cap hub-cap left a comment

Choose a reason for hiding this comment

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

heh you know the HLRC PR process well now. Great work.

@martijnvg martijnvg merged commit 579be91 into elastic:master Dec 4, 2018
martijnvg added a commit that referenced this pull request Dec 4, 2018
This change also adds documentation for the Get Auto Follow Pattern API.

Relates to #33824
martijnvg added a commit to martijnvg/elasticsearch that referenced this pull request Dec 4, 2018
The current response format is:

```
{
    "pattern1": {
        ...
    },
    "pattern2": {
        ...
    }
}
```

The new format is:

```
{
    "patterns": [
        {
            "name": "pattern1",
            "pattern": {
                ...
            }
        },
        {
            "name": "pattern2",
            "pattern": {
                ...
            }
        }
    ]
}
```

This format is more structured and more friendly for parsing and generating specs.
This is a breaking change, but it is better to do this now while ccr
is still a beta feature than later.

Follow up from elastic#36049
spinscale pushed a commit that referenced this pull request Dec 4, 2018
This change also adds documentation for the Get Auto Follow Pattern API.

Relates to #33824
martijnvg added a commit that referenced this pull request Dec 5, 2018
The current response format is:

```
{
    "pattern1": {
        ...
    },
    "pattern2": {
        ...
    }
}
```

The new format is:

```
{
    "patterns": [
        {
            "name": "pattern1",
            "pattern": {
                ...
            }
        },
        {
            "name": "pattern2",
            "pattern": {
                ...
            }
        }
    ]
}
```

This format is more structured and more friendly for parsing and generating specs.
This is a breaking change, but it is better to do this now while ccr
is still a beta feature than later.

Follow up from #36049
martijnvg added a commit that referenced this pull request Dec 5, 2018
The current response format is:

```
{
    "pattern1": {
        ...
    },
    "pattern2": {
        ...
    }
}
```

The new format is:

```
{
    "patterns": [
        {
            "name": "pattern1",
            "pattern": {
                ...
            }
        },
        {
            "name": "pattern2",
            "pattern": {
                ...
            }
        }
    ]
}
```

This format is more structured and more friendly for parsing and generating specs.
This is a breaking change, but it is better to do this now while ccr
is still a beta feature than later.

Follow up from #36049
@codebrain
Copy link
Contributor

Hi @martijnvg, this appears to be a breaking change in the response format between versions 6.5 and 6.6:

Examples:

6.5:

{
  "my_auto_follow_pattern" :
  {
    "remote_cluster" : "remote_cluster",
    "leader_index_patterns" :
    [
      "leader_index*"
    ],
    "follow_index_pattern" : "{{leader_index}}-follower"
  }
}

6.6:

{
  "patterns": [
    {
      "name": "my_auto_follow_pattern",
      "pattern": {
        "remote_cluster" : "remote_cluster",
        "leader_index_patterns" :
        [
          "leader_index*"
        ],
        "follow_index_pattern" : "{{leader_index}}-follower"
      }
    }
  ]
}

We have a mechanism by which we can workaround this breaking change in the .NET client (a custom derserializer), but I wanted to check the reasoning behind this change? Are there any intentions to add sibling json nodes to the "patterns" node?

Thanks!

@martijnvg
Copy link
Member Author

Hey @codebrain

This breaking change was part of #36203, which also describes the reasoning.

Are there any intentions to add sibling json nodes to the "patterns" node?

No, at the moment there are no plans for this. But this will allow us to do so in the future if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants