Hi all,

Sorry for duplication if it is the case, I can not put an hand on any older issue about it

With the API we can either specify the spec, or the flavor. I did it with run https://nuv.la/run/e8d46f19-4858-4b4b-af9c-e2692a6f0d4e

The thing is that the VM created only have 1 core and 2GB of ram while we asked for 8vcpu and 16ram.

Am I doing it wrong ? Does the function not available yet ?

Best regards

Functions such as:

• module upload/download
• execute
• etc.

Should be transferred from the SlipStreamClient to this API and exposed in the Clara client.

In the end, the SlipStreamClient (as currently defined) should only include VM related commands (e.g. put, set, random).

Signature
parameters: cimi_filter=''
returns: list of credentials that user can see and that matched the filter.

Append and type^='cloud-cred' to the filter.

Needed for HBP MOOC to work with Exoscale S3.

Currently this is not possible with current method because the download operation on external-object doesn't return a CIMI object but directly a the file.

Workaround:

from slipstream.api import Api

def download_file(session, url, filename):
    r = session.get(url, stream=True)
    with open(filename, 'wb') as f:
        for chunk in r.iter_content(chunk_size=1024): 
            if chunk:
                f.write(chunk)
    return filename

api = Api()
api.login_internal('username', 'password')

download_file(api.session, api.endpoint+'/api/external-object/00fd20531fe36a3e113d8e3100a52eff/download', 'report.tzg')

Modify the client so that authentication uses the CIMI session resources. Both username/password and api key/secret must be supported.

The API sets a login cookie that it is unable to log in with. A workaround is deleting the cookie file on each login attempt, but this is impractical. Ensure that the saved cookie is usable.

Could you add into the API the ability to fulfill following user stories ? The idea, with issue #2, is to be able to completely configure a new account.

User stories

• As a user I can add edit and delete my cloud configurations (username, password, domain, ...)
• As a privileged user I can add edit and delete cloud configurations of less-privileged user (username, password, domain, ...)

I am aware of https://nuv.la/api/service-offer but it does not return me an xml when I ask for (?media=xml). I also don't know the accuracy and completeness of the information returned.
As soon as I have a way to get the flavor in xml, I will implement the function and make a pull request.

Code proposition with this pull request

The Api internally inside the library is documented but there's no proper documentation and on the github Readme or on the SlipStream API Reference.

Actually the documentation on github is wrong, an example is the following official README on github:

from slipstream.api import Api
api = Api('https://nuv.la')
api.login('username', 'password')
api.list_applications()

The above raises an error at runtime with:

Traceback (most recent call last):
  File "SlipStreamdeploysample.py", line 10, in <module>
    api.login('username', 'password')
TypeError: login() takes exactly 2 arguments (3 given)

I then went through the Python Api library which is:

def login(self, login_params):

With the login_params parameter being a dictionary.

But inside the same class there is the following function:

def login_internal(self, username, password):

and it utilises def login(self, login_param): and has username and password parameters as strings.

Which shows the README docs is a wrong and need fixing or must be updated if so.

Another issue I wanted to mention is the lack of examples with the package. As a user, having clear and practical examples helps understanding the Api and makes you understand the docs better in most cases.

An example could be the following:

from slipstream.api import Api
api = Api('https://nuv.la')
api.login_internal('username', 'password')

# To deploy and get deployment ID
deployment_id = api.deploy('app/mysql/v1', cloud='ec2-us-west-2')

# To terminate
api.terminate(deployment_id)

# To logout
api.logout()

The above is a simple basic deployment example but there's no similar example provided in the docs, on the other hand more complex examples are needed since all production deployments are a lot more complex than the above.

Code proposition with this pull request

Hi SixSq,
I tried to implement it by my self, but I ends up on strange behavior. Let's say I want to change the organization and lastName of user 'lemigns_DMM9', I tried:

• use HTTP PATCH verb on url '/user/lemigns_DMM9' with xml content <?xml version='1.0' encoding='UTF-8'?> <user lastName="D5EDQ" name="lemigns_DMM9" organization="new !" state="ACTIVE" /> but i get 'slipstream.api.api.SlipStreamError: First name cannot be empty.'
• use HTTP PATCH verb with all informations (with new value) and a duplicate appears in /user
  
  note that whether I click on first or second user I logicaly ends on the second one
• use HTTP PUT verb with all informations and also get a duplicate

Note also that when I then try to update another user TOTO, the duplicate of lemigns_DMM9 disapear and a duplicates of TOTO appears.

I'm using slipstream 3.14 started from nuv.la workspace

• internal
• api-key

As a user of the Python API, I should be able to:

• list all available commands
• know for each which arguments are needed

Code proposition with this pull request

Ticket moved from slipstream/SlipStreamClientClara#6

We also need to review naming. Current usage corresponds to the top part of the dashboard. "Usage summary" are different and probably better suited for "usage". This need to be reviewed.

All but new run related bits.

Detect session expiration and reauth. This is needed for services which use the API and should always implement this kind of mechanism

In order to stop pulling all deployement and checking their status, we have to use the events. To do so, we need the event to be returned by the python API.

I'm willing to do it, but help is wanted on what information should be presented in objects created from the information returned by the REST API (acl?). What are the different severity and type. Some docs

Code proposition with this pull request

'/root/.slipstream/cookies.txt' does not look like a Netscape format cookies file

According to the new Runtime Parameter resource implement CIMI based

• GET with SSE
• PUT

Cris: I’ve seen the nuvlabox-agent being stuck for minutes

HTTPSConnectionPool(host='nuv.la', port=443): Read timed out. (read timeout=None)
Traceback (most recent call last):
  File "/usr/sbin/nuvlabox-agent", line 174, in main
    nuvlabox_info = nb.get_nuvlabox_info(api)
  File "/usr/sbin/nuvlaboxnano.py", line 154, in get_nuvlabox_info
    return api.cimi_get(NUVLABOX_ID).json
  File "/usr/local/lib/python2.7/dist-packages/slipstream/api/api.py", line 568, in cimi_get
    resp_json = self._cimi_get(resource_id=resource_id, params=cimi_params)
  File "/usr/local/lib/python2.7/dist-packages/slipstream/api/api.py", line 542, in _cimi_get
    return self._cimi_request('GET', uri, params=params)
  File "/usr/local/lib/python2.7/dist-packages/slipstream/api/api.py", line 521, in _cimi_request
    data=data)
  File "/usr/local/lib/python2.7/dist-packages/slipstream/api/api.py", line 221, in request
    response = self._request(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/slipstream/api/api.py", line 218, in _request
    return super(SessionStore, self).request(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 524, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 637, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 529, in send
    raise ReadTimeout(e, request=request)
ReadTimeout: HTTPSConnectionPool(host='nuv.la', port=443): Read timed out. (read timeout=None)

Currently, and if my pull request is accepted, if can have the abort message when doing list_deployments but not when doing get_deployment.

Hi,

When I create an account with a cloud configured (username, domain, ...) and a default cloud I can not connect with this account, while when not defining a default cloud I can connect.

I cannot see the account either when being super

When looking at this user in xml it works, but the description attributs are missing from parameters.

With a user with no default cloud, when I look at the cloud I have configured indeed descriptions are missing

I think the bug is that missing attribut makes the UI crash for default cloud, but not the others.

Note that once I can edit and re-save a user, all description appears, both in xml and UI

Code proposition with this pull request

When doing this

api = Api(config["endpoint"], insecure=True)
api.login(config["username"], config["password"])
for o in api.list_virtualmachines():
    print o

It fails because the api wants to have _deployment_id with a value. As it makes sense to refuse to list all VMs without filtering on the deployment id, could we just remove the default value for parameter deployment_id=None to make it clearer ? Or is it that you want the api to keep track of the previously provided deployment_id (I prefer the first option)?

Would it be possible to create an account in slipstream programmatically ? With the API or any other entry point ?

Ticket moved from slipstream/SlipStreamClientClara#5

Resources such as deployments should support paging

I.e. allow to opt for requests.Session (or others) instead of the default MozillaCookieJar.