By "break this" do you mean at some point we should remove the logs from the GET? In any case I will close the PR.
Thanks Tyson On 10/2/18, 4:21 PM, "Rodric Rabbah" <[email protected]> wrote: Hi Tyson - this was the intent of the API design: there is a separate resource for LOGS and the RESULT. The reasoning also that the metadata is typically small but the logs could be much larger. Separating the two was also intended for easier streaming of the responses. Because of implementation made it easier to bundle the response, we have the current “feature” where GET on the activation id returns the entire record. I think we can break this because the clients can sugar the underlying calls. -r > On Oct 2, 2018, at 12:07 PM, Tyson Norris <[email protected]> wrote: > > Hi – > I created this PR [1] due to noticing that `wsk activation get` does NOT return logs from a LogStore which stores logs outside of the Activation entity. > But it bring up a question of: Does IBM or any other operator who might use a custom LogStore desire to have logs included with `activation get`? > Currently returning logs is only possible using `wsk activation logs` > > Personally, I think it is “nice” to have a separate explicit request for logs and activation metadata, and this is the way that the current OW Activation API operates with regards to an external LogStore (splunk, elk, etc), but after all it is inconsistent from the case where logs are NOT using external storage. > > WDYT? > > Thanks > Tyson > > [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-openwhisk%2Fpull%2F4044&data=02%7C01%7Ctnorris%40adobe.com%7C30a7422c5e8f4184015408d628bdcb36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636741192954948579&sdata=uvYACmWD3PWVl3pWzCZpzZer1jVFhdpv8pc%2Fz0Bh7z4%3D&reserved=0
