Create a restful API to retrieve resource bundle

[machi1990]

Currently, it is not possible to retrieve resources whose type is Bundle via the rest API.
It's a perfect use case for someone to create a resource with type Bundle via the grpc client on one component and on the other component using the rest API wanting to list all resources (Single and Bundle resources) or even filtering by bundle resource
e.g

ocm get /api/maestro/v1/resources -p search="type='Bundle'"

At the moment, the above query returns an empty list all the time even if there are resources with type Bundle in the database.

The reason is that the query performed by the backend is

SELECT * FROM "resources" WHERE ((resources.type = 'Bundle' AND resources.type = 'Single')) AND "resources"."deleted_at" IS NULL LIMIT 100  

notice the (resources.type = 'Bundle' AND resources.type = 'Single')

@qiujian16 @clyang82

[clyang82]

Thanks @machi1990 for reporting this. The current design is

1. restful api supports CRUD for Single resource only
2. gRPC supports CRUD for Bundle resource.

In order to support your case, it may introduce the trouble that one resource can have multiple operators (restful and gRPC).

[clyang82]

It is also related with setting manifestbundle and manifest as supported codecs in maestro agent by default.

[machi1990]

In order to support your case, it may introduce the trouble that one resource can have multiple operators (restful and gRPC).

I fail to see an issue with this; can you elaborate what's the issue with a resource being operated by multiple operators?

[machi1990]

It is also related with setting manifestbundle and manifest as supported codecs in maestro agent by default.

I think exposing the codecs config as done in #94 is fine

[clyang82]

1. the green boxes what we have today.
2. the gray boxes we do not have today.

Thoughts?

[machi1990]

@clyang82 apologies, I missed the ping in this card.

the green boxes what we have today.

I've tested all the green boxes succesful; except for the WATCH (subscribe API) which I've opened a discussion thread on.

the gray boxes we do not have today.

Correct, the /api/maestro/v1/manifests is what is missing today. How do you envision its design - the API schema, and its list capabilities?

[machi1990]

Correct, the /api/maestro/v1/manifests is what is missing today. How do you envision its design - the API schema, and its list capabilities?

To expand on this, will there also be a /api/maestro/v1/manifests/<id> ?

[qiujian16]

I think so, we should have both list and get.

[clyang82]

link this issue together #103

[machi1990]

I am happy for this issue to be closed in favor of #103