@mvadkert Any thoughts on this?

interesting, we were against this before, but I understand the use case @prpatnai

So you are not feeding the whole UMB message to the elasticsearch? You could filter also based on topic, as it the last part of that string?

But for example the artifact.type is also in the messages ... so there is some place for discussion about it?
If so, I would put it under pipeline.status ... and I wonder if it needs to be required ...

@happz @msrb @astepano @bgoncalv @ralph feedback also welcome

@prpatnai

I have already created a PR and have to create one more to make some changes in the json file.

Where is that PR?

I created a pull request on Github for the cotralib repo. But @jbieren asked me to open the issue here.

I see, ok. From my POW I would like to avoid adding new required parameter basically to all messages if not really necessary. Unfortunately we just lately released 1.0.0 spec and such change would basically require to release version 2.0.0.

1. In case of an optional parameter we could just release 1.1.0 what I see a less problematic option.

2. Anyway, the standard gives you freedom to add any additional fields as you need, it is only for your use case. Once you would start requiring that from others, it should land in the standard :)

So which option is your case? Are you expecting others to also expose status message ?

interesting, we were against this before, but I understand the use case @prpatnai

So you are not feeding the whole UMB message to the elasticsearch? You could filter also based on topic, as it the last part of that string?

But for example the artifact.type is also in the messages ... so there is some place for discussion about it?
If so, I would put it under pipeline.status ... and I wonder if it needs to be required ...

@happz @msrb @astepano @bgoncalv @ralph feedback also welcome

I was filtering Pipeline status for CPaaS and I guess pipeline.status return results only for CVP.