user not defined api.js

[urdaalex]

RabbitManager.createUser() does not return anything. This line results in user being set to undefined.

Possible solution:
await context.rabbit.createUser(newNamespace.username, newNamespace.password, ['taskcluster-pulse']); user = newNamespace.username;

[Hexcles]

Only the "getters" return values, and the method for creating and deleting
stuff generally return void in rabbitmq lib.

On Tue, Nov 1, 2016, 13:49 urdaalex notifications@github.com wrote:

RabbitManager.createUser() does not return anything. This line
https://github.com/taskcluster/taskcluster-pulse/blob/master/src/api.js#L129
results in user being set to undefined.

Possible solution:
await context.rabbit.createUser(newNamespace.username,
newNamespace.password, ['taskcluster-pulse']); user = newNamespace.username;

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#38, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ABXsjJ7kTJRZh6QsVNTiZCvZjwLUWn1Kks5q56XrgaJpZM4KmkAR
.

[urdaalex]

also now that I look at it, is it even possible to specify parameters by name in function calls here? Excuse my limited JS knowledge

[imbstack]

So far as specifying by name is concerned, we use babel to compile the modern/future js we write into the current runnable stuff. So in tc-pulse, you can write

    await context.rabbit.setUserPermissions({
      user: await context.rabbit.createUser(newNamespace.username, newNamespace.password, ['taskcluster-pulse']),
      vhost: '/',
      configurePattern: '',
      writePattern: `taskcluster/(exchanges|queues)/${newNamespace.namespace}/.*`,
      readPattern: 'taskcluster/exchanges/.*',
    }); 
} catch (err) {
...

but that would only work if setUserPermission is defined as follows:

 async setUserPermissions({user, vhost, configurePattern, writePattern, readPattern}) {

which it isn't, it's missing the curly braces.

As it is written you need to pass in arguments in order.

[imbstack]

But yeah, the fix for this should be to split up the creation of the user and the setting of the permissions into two calls. Just await the results of createUser and then call setUserPermissions with newNamespace.username.

[Hexcles]

Is that the destructive assignment?

Speaking of which, Brian Yip and I briefly talked about the interface of
this API and thought that it was a bit messy and probably error-prone to
specify these "*patterns" in order. Is there a better convention/practice
when it comes to this kind of parameters in modern JS?

On Tue, Nov 1, 2016, 16:11 Brian Stack notifications@github.com wrote:

But yeah, the fix for this should be to split up the creation of the user
and the setting of the permissions into two calls. Just await the results
of createUser and then call setUserPermissions with newNamespace.username.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#38 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABXsjDcpARUDtYa6dMRY2KqXiVwMsOmMks5q58czgaJpZM4KmkAR
.

[imbstack]

@Hexcles: taskcluster uses that style of assignment (yep, destructuring) often and I quite like it. It can even allow for setting defaults. I would support a move to that in the rabbitmanager api.

[itsbriany]

I'm guessing that if we use destructive assignment in setUserPermissions's function signature, then we will also need to do the same for the rest of the rabbitmanager calls?

[Hexcles]

Probably just replace all the dict-like complex parameters with destructing
assignments? Like the "*patterns". If there is just name and/or vhost, we
could probably leave it as is. Not sure if this is not consistent though.

On Tue, Nov 1, 2016, 17:16 Brian Yip notifications@github.com wrote:

I'm guessing that if we use destructive assignment in setUserPermissions's
function signature, then we will also need to need to do the same for the
rest of the rabbitmanager calls?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#38 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABXsjJ8sUftRi48GNFU7IxsWOur-g6llks5q59ZggaJpZM4KmkAR
.