usernames and passwords in list?

[bjin01]

Hi,
While writting python script to login to peripheral suma I don't understand why username(s) and password(s) need to be in list.
I understand that if unicast we need to provide login credentials for each peripheral suma but how are the login(s) mapped to the peripheral suma?

I mean this line in sample python script.
usernames = ["admin" for s in serverIDs]

I created a "advanced login" python script which parses a yaml config file to loop over pre-defined suma servers, but I'm using multicast but I presumed each peri suma has different login and therefore I let user config it in yaml file.
https://github.com/bjin01/patchsystems/tree/master/sumahub

My question is, do you also plan to allow a config file to predefine multiple logins for peripheral sumas? If yes, I assume you might make the code into hub in golang instead of as I did in python, correct?

[rjmateus]

Hey @bjin01

Users can configure the same user and passwords on the peripheral server using the uyuni configuration salt formula [1] [2]. With this salt formula, one can configure organizations, users (and permissions), system groups, and activation keys.

There are different login methods available. If the same user and password are defined in all peripheral servers then one can use loginWithAuthRelayMode or loginWithAutoconnectMode.

If different user/password combinations are needed for each server, then the manual login should be used. At the moment we do not support load system list and login information from a yaml file. It can be added in the future in case it's requested for some use case but is not currently in our plans.

[1] https://documentation.suse.com/external-tree/en-us/suma/4.1/suse-manager/salt/config-modules.html
[2] https://github.com/SUSE/salt-formulas/tree/master/uyuni-config-formula

[rjmateus]

cc @admd @moio

[bjin01]

Hey @bjin01

Users can configure the same user and passwords on the peripheral server using the uyuni configuration salt formula [1] [2]. With this salt formula, one can configure organizations, users (and permissions), system groups, and activation keys.

There are different login methods available. If the same user and password are defined in all peripheral servers then one can use loginWithAuthRelayMode or loginWithAutoconnectMode.

If different user/password combinations are needed for each server, then the manual login should be used. At the moment we do not support load system list and login information from a yaml file. It can be added in the future in case it's requested for some use case but is not currently in our plans.

[1] https://documentation.suse.com/external-tree/en-us/suma/4.1/suse-manager/salt/config-modules.html
[2] https://github.com/SUSE/salt-formulas/tree/master/uyuni-config-formula

Thanks rjmateus for quick response.
But my main question was why has var "users" and "passwords" passed to client.hub.attachToServers need to be a LIST. If I store the users and passwords in separate list how does hub know which pair of user+password belongs to which peripheral suma? I'm thinking that nested dictionary in list in python would be better [sumahost1: {username: bjin01, password: something}, sumahost2: {username: bjin02, password: something}]

client.hub.attachToServers(hubSessionKey, serverIDs, peripheral_usernames, peripheral_passwords)

Better:
client.hub.attachToServers(hubSessionKey, serverIDs, perisumalist)

If I think in golangit would be a struct something like this (thinking loud):

var PeriSumas struct{
Sumahost string
SumaUser string
SumaPasswd string
}

var allsumalist []PeriSumas

[rjmateus]

Hey Bo,
They match by the array index. So server in position 0, will use username in position 0 of peripheral_usernames and password in position 0 of peripheral_passwords.

The alternative you are proposing makes also sense and can be an alternative implementation.
However, this was the way the API structure was initially defined. If you think it doesn't address your needs we can revisit it and try to adapt.

This feature is not in technical preview anymore, so any change to the API definition could be harder to implement.
@moio any thought on this one?

[admd]

You will notice that our API is designed in a way that mostly each method's output could be used as it is, as input for further methods. We mostly follow this method chaining approach.

In your particular example, we could have come up with what you have suggested but that's not the case, and as Ricardo suggested it might now be hard to change it considering that it is not a tech preview anymore.

[bjin01]

You will notice that our API is designed in a way that mostly each method's output could be used as it is, as input for further methods. We mostly follow this method chaining approach.

In your particular example, we could have come up with what you have suggested but that's not the case, and as Ricardo suggested it might now be hard to change it considering that it is not a tech preview anymore.

Thanks for the explain.
Based on your answer could you help me and explain how can I write in python to make api calls with several peripheral sumas in which each suma has a different username and passwd?
I would like to pass a list of sumas, usernames and passwords. At the moment I have to create a list for usernames and passwd for each suma a separate list.
Is it possible to pass over a list of dictionary in python to api call?
e.g.
client.hub.attachToServers(hubSessionKey, serverIDs, peripheral_usernames, peripheral_passwords)

Notes:
serverIDs - is a list of Sumas returned by serverIDs = client.hub.listServerIds(hubSessionKey)
peripheral_usernames - is a list but only hold one username because each suma has different username
peripheral_passwords - is a list but only hold one password because each suma has different password

Now the list serverIDs holds multiple peripheral SUMAs. In my python script I have to loop over this list take each single serverid find the name of the serverid, compare it with user given suma server name and compose the lists for username(s) and password(s).

This is ok but really not "user friendly". Hope the complexity is clearly explained.
Thanks

[moio]

Now the list serverIDs holds multiple peripheral SUMAs. In my python script I have to loop over this list take each single serverid find the name of the serverid, compare it with user given suma server name and compose the lists for username(s) and password(s).

What are you ultimately trying to achieve?

[bjin01]

Now the list serverIDs holds multiple peripheral SUMAs. In my python script I have to loop over this list take each single serverid find the name of the serverid, compare it with user given suma server name and compose the lists for username(s) and password(s).

What are you ultimately trying to achieve?
The thing is very simple. I have a yaml config file in which people can write their peripheral suma server with username and passwd. Now I need to use this data to make hub api calls. In my python I created for username and password for each peripheral suma a list and call the hub api. But this is not really nice because
erverIDs = client.hub.listServerIds(hubSessionKey)
is return a list of known peripheral SUMAs but each suma has its own username and passwd. But I cannot use the returned serverID with the list of usernames and passwords for all SUMAs because the order of the serverID is "unknown" and not matching to the order of usernames and passwords.

[moio]

This sounds to me like a valid objection.

Rephrasing: we assume that there's different credentials for each Peripheral Server. Users know the (FQDN, username, password) tripled for each Server and they have no problem in creating the three arrays, in order, of all FQDNs, usernames and passwords.

But now they need an array of the Server IDs, and they need it in the same order of the FQDNs, usernames and passwords they already have (this is a requirement for attachToServers.

We give them hub.listServerIds but, tragically, the list of IDs will invariably not be in the correct order, so they are left with the boring task of looking up the FQDNs for each ID, then sorting them correctly according to their arrays - and that's before they can use any of the Hub XMLRPC API functionality. Not nice.

@admd, @bjin01: How about a new variant of hub.listServerIds that also receives a list of FQDNs and returns only IDs matching those FQDNs in the same order?

[bjin01]

This sounds to me like a valid objection.

Rephrasing: we assume that there's different credentials for each Peripheral Server. Users know the (FQDN, username, password) tripled for each Server and they have no problem in creating the three arrays, in order, of all FQDNs, usernames and passwords.

But now they need an array of the Server IDs, and they need it in the same order of the FQDNs, usernames and passwords they already have (this is a requirement for attachToServers.

We give them hub.listServerIds but, tragically, the list of IDs will invariably not be in the correct order, so they are left with the boring task of looking up the FQDNs for each ID, then sorting them correctly according to their arrays - and that's before they can use any of the Hub XMLRPC API functionality. Not nice.

@admd, @bjin01: How about a new variant of hub.listServerIds that also receives a list of FQDNs and returns only IDs matching those FQDNs in the same order?

This would be brilliant from my point of view (user point). Thanks.

[bjin01]

This sounds to me like a valid objection.
Rephrasing: we assume that there's different credentials for each Peripheral Server. Users know the (FQDN, username, password) tripled for each Server and they have no problem in creating the three arrays, in order, of all FQDNs, usernames and passwords.
But now they need an array of the Server IDs, and they need it in the same order of the FQDNs, usernames and passwords they already have (this is a requirement for attachToServers.
We give them hub.listServerIds but, tragically, the list of IDs will invariably not be in the correct order, so they are left with the boring task of looking up the FQDNs for each ID, then sorting them correctly according to their arrays - and that's before they can use any of the Hub XMLRPC API functionality. Not nice.
@admd, @bjin01: How about a new variant of hub.listServerIds that also receives a list of FQDNs and returns only IDs matching those FQDNs in the same order?

This would be brilliant from my point of view (user point). Thanks.

The yaml file for people to enter multi peripheral suma info looks so:

hub: sumahub.bo2go.home
hub_user: bjin01
hub_password: suse1234

peripheral_sumas:
  suma1:
    servername: bjsuma.bo2go.home
    username: bjin
    password: suse1234
    active: True
  
  suma2:
    servername: testserver
    username: testuser
    password: testpasswd
    active: True

[bjin01]

This sounds to me like a valid objection.
Rephrasing: we assume that there's different credentials for each Peripheral Server. Users know the (FQDN, username, password) tripled for each Server and they have no problem in creating the three arrays, in order, of all FQDNs, usernames and passwords.
But now they need an array of the Server IDs, and they need it in the same order of the FQDNs, usernames and passwords they already have (this is a requirement for attachToServers.
We give them hub.listServerIds but, tragically, the list of IDs will invariably not be in the correct order, so they are left with the boring task of looking up the FQDNs for each ID, then sorting them correctly according to their arrays - and that's before they can use any of the Hub XMLRPC API functionality. Not nice.
@admd, @bjin01: How about a new variant of hub.listServerIds that also receives a list of FQDNs and returns only IDs matching those FQDNs in the same order?

This would be brilliant from my point of view (user point). Thanks.

The yaml file for people to enter multi peripheral suma info looks so:

hub: sumahub.bo2go.home
hub_user: bjin01
hub_password: suse1234

peripheral_sumas:
  suma1:
    servername: bjsuma.bo2go.home
    username: bjin
    password: suse1234
    active: True
  
  suma2:
    servername: testserver
    username: testuser
    password: testpasswd
    active: True

And it would great if the
client.hub.attachToServers(hubSessionKey, serverIDs, peripheral_usernames, peripheral_passwords)
attachToServers would accept a list/array of dictionaries in python. In Go would be a slice of struct.

var PeriSumas struct{
  Sumahost string
  SumaUser string
  SumaPasswd string
}