support for opaque config objects and references #160
Description
@kyessenov commented on Thu Jul 13 2017
For transcoding, we need to store large configuration objects (protobuf descriptors) to provide transcoding at the proxy level. I'd like to have a way to store them in Galley and a naming scheme to get them back.
@jmuk commented on Mon Jul 17 2017
I think the final direction would be made after @mandarjog is back, but I talked with @lizan a bit to clarify some details. Here's my understandings;
requirements:
- users will write their .proto files.
- Istio proxy would do the transcoding based on the descriptor data of the proto file.
- note that the descriptors need the imports, that could be large.
So maybe a natural workflow would be
- users invoke
protocwith--descriptor_set_out(and--include_imports). Upload the binary file into Galley. - Galley should accept these binary files as-is. No transformations, no validations, it just behaves as a simple file storage.
- Proxy fetches the binary data from Galley and uses it for transcoding.
Actually it breaks some assumptions Galley has currently;
- users write/upload their configurations in yaml format or json
- Galley works with its "validator" -- the validator can convert the yaml config into certain binary. Galley doesn't care about the contents in the binary chunk.
- Watcher clients (i.e. Mixer/Pilot. or Proxy?) will receive the converted binary data, handle the data as they like.
If Galley accepts config data which users write and make transformation and validation server-side, it might be natural for Galley to accept the proto files and make a "validator" to transform it into binary descriptors data -- although this doesn't fit quite well into the internal exchanging data structure between Galley and validators (i.e. ConfigFile message).
@jmuk commented on Wed Jul 19 2017
@geeknoid may also be interested in, how the descriptors data can fit into the config structure Galley will have.
@geeknoid commented on Thu Jul 20 2017
I think we can generalize the API surface to tolerate binary blobs.
The value in ingesting text is that Galley is in the validation business. We can ensure semantic validity of the individual chunk of state, but also provide referential integrity of the chunk relative to the rest of config. This validation will simply not be possible for blobs.
@ayj commented on Thu Aug 17 2017
No longer relevant with k8s apiserver alignment.
@kyessenov commented on Thu Aug 17 2017
Doesn't really answer my question - how do we store third party extensions in CRDs?
@ayj commented on Thu Aug 17 2017
Oops, looks like I closed the wrong issue.
The maximum resource size in Kubernetes is 1MB (etcd limitation). An opaque Istio CRD type for this purpose could work if the size limitation isn't an issue. Otherwise we'd need to carve up the opaque resource into smaller parts, compress/optimize resource format, or use an alternate storage backend.