[Feature] gcloud-logging

[VikramTiwari]

Is there any plan to include logging api in this package? If so what is the expected timeline?

Link: https://cloud.google.com/logging/docs/api/gcloud-logging

[jgeewax]

PR's are welcome ! :)

Seriously though -- I think @stephenplusplus may be able to help answer....?

[stephenplusplus]

I think the next two APIs we want to implement are Resource Manager and logging. A rough guess is probably an ETA of early-Mid October for both. PRs definitely welcome to speed up the process :)

[VikramTiwari]

@jgeewax @stephenplusplus There's already some work going on with trace, I am guessing that they will also include logs in the lib once everything is stable on the core api end. Best will be to have that whole lib included in this project.

As for PRs, step 0 - forking done! 👍 :)

[stephenplusplus]

Awesome, keep us posted! Feel free to send a PR whenever you have something ready to discuss or get feedback on; don't worry about waiting until it's perfect. I'll tackle supporting Resource Manager first, but feel free to ping me for any help with logging.

Thanks for helping!

[stephenplusplus]

@VikramTiwari I'm getting started on this. I'll hopefully have a preliminary PR up for review in a couple days.

[VikramTiwari]

@stephenplusplus Aha! Nice. 😄 Sorry but i have been busy hence couldn't contribute anything.

[stephenplusplus]

No problem at all! Just make sure to leave some time to test it out for us :)

[VikramTiwari]

haha Alrighty! Committed for that. :)

[stephenplusplus]

@jgeewax running into "The caller does not have permission" API errors while testing my Logging implementation. Specifically, it's a call to https://cloud.google.com/logging/docs/api/ref/rest/v1beta3/projects.sinks/create -- I'm guessing service accounts aren't sufficient for this API?

[jgeewax]

@munangst : Does projects.sinks/create require 3LO? Or can a service account do that?

[munangst]

The issue is that sinks.create (and also sinks.delete, sinks.update, and logs.delete) requires the caller to be a project owner, and service accounts can't be owners. Our expectation was that typically these operations are infrequent (since they set up long-lived log export destinations) and users would perform them manually as an admin using gcloud or the Developers Console. However, we've gotten some recent feedback that users want to manage log sinks with service accounts (e.g., to allow automation to set up new projects) so we're reconsidering this. We're also planning to support Cloud IAM policies in the future so that you can manage permissions at a level finer than Project Viewer/Editor/Owner.

Can you explain a bit more about the use case? Is it feasible to pass the user's credentials for this operation instead of using a service account?

[stephenplusplus]

I can't come up with a specific use case, but in general our library make the upstream APIs available for any of our users to easily fit into theirs. We do run into these one-off/bootstrap procedures from time to time that are best done with a UI (Pub/Sub creating a topic, Storage creating a bucket). In this case, since our library has full support for Storage, and a possible sink can be a bucket, if a user did have a need for programmatic creation of a sink, we can simplify the connection between a new sink and a Bucket destination:

var gcloud = require('gcloud')({
  projectId: 'my-project-id',
  keyFilename: 'path-to-service-account-keyfile.json'
});

var storage = gcloud.storage();
var logging = gcloud.logging();

logging.createSink('new-sink-name', {
  destination: storage.bucket('logging')
}, function(err, sink) {});

Internally, that would grant the logging account as an owner on the bucket, create the sink, and give the user programmatic access to make further modifications to the sink (getting/setting metadata, deleting).

@jgeewax might be able to speak to specific use cases.

Is it feasible to pass the user's credentials for this operation instead of using a service account?

As far as I know, this would be pretty tricky. In production, a user would be using our library headlessly, so I'm not sure how the user auth process would begin. This could just be due to my still-maturing familiarity with all of the auth options, so if anyone can explain how we can easily get the credentials we need, please correct me.

[jgeewax]

Is it feasible to pass the user's credentials for this operation instead of using a service account?

It really should be...

For example, the resource manager API only works with user account credentials... so this should look like

$ gcloud auth login
$ node myscript.js

And myscript should use the user-creds .... Do we really not do that anywhere in our auth situation?

[stephenplusplus]

Do we really not do that anywhere in our auth situation?

We do via https://github.com/google/google-auth-library-nodejs. We get a token successfully this way, and pass it with the request. The response is still "The caller does not have permission" -- does this mean I'm getting a token that doesn't work? Or maybe my project/account needs to be whitelisted?