Python lib Juju disconnect

juju
#1

Hi guys, I started developing the creation of machines remotely via API requests, but I found a moment that when asynchronously connected to the controller and the model, after receiving a response, the function still freezes for 10 seconds, please tell me what can be done?

That is, with any connection to the controller, regardless of what data I want to get, the session still hangs for 10 seconds.

I tried to use the built-in disconnect method, and also tried to interrupt the asynchronous function, but there is no result. Used the [pythonlibjuju](https://pythonlibjuju.readthedocs.io/en/latest /)

the asynchronous function looks like this, this function gets the data of all parameters that are specified inside the model

async def application_data(data_js):

    controller = Controller()

    model = Model()

    try:

        await asyncio.gather(controller.connect(data_js['controller_name']), model.connect(str(data_js['controller_name']) + ':admin/' + str(data_js['model_name'])))

        array = []

        try:

            for app in model.applications:

                for unit in Application(model=model, entity_id=app).units:

                    array.append(unit.data)

            source_data = json.dumps(array, indent=4)

            print("SOURCE - DATA", source_data)

            return source_data

        except JujuAppError:

            source_data = "Applications Errors"

            return source_data

    except JujuConnectionError:

        source_data = ("Connection Errors")

        return source_data

    finally:

        await model.disconnect()

        return source_data
#2

Hi @dev-turar, thanks for bringing this up. So couple of things first:

  • The documentation in python-libjuju is old, we really need to review and renew it for sure. We do have plans in place to do that soon.
  • The field data is really for internal use only. I’m not entirely sure what information you’re trying to get by accessing the unit.data, but there’s a bunch of utility functions that’ll receive useful information in unit.py, e.g. workload-status etc. If there’s a particular piece of information you’re unable to get with these, then please feel free to open a feature request and we’ll implement it asap for you :+1:
  • pylibjuju’s objects are tightly connected in the background to the actual juju model running on the controller, so creating new objects and trying to bind them manually (e.g. Application(model=model, entity_id=app)) complicates things a lot.
  • If your program terminates after returning from this function then you don’t need to call the model.disconnect() in the end since all the objects (e.g. websocket, etc) for the underlying connection will be collected anyway. It’s a good practice to do so only if you’ll need to establish another connection in the same process.

I went ahead and rewrote your code with what I think you intend to do, so I suggest you try it out with this, and if the problem persists then please open a bug so we’ll get on it for you right away :+1:

async def application_data(data_js):
    model = Model()
    try:
        model.connect() # this will connect to the "current" model
        array = []
        for app in model.applications:
            for unit in app.units:
                array.append(unit.data)
        source_data = json.dumps(array, indent=4)
        print("SOURCE - DATA", source_data)
    except JujuAppError:
        source_data = "Applications Errors"
    except JujuConnectionError:
        source_data = ("Connection Errors")
    finally:
        return source_data
#3

Thank you very much for the answer, the fact is that the workload status gives less information, so I take information from each unit in a cycle, and also now there is a problem with creating a controller, a timeout, the server 91.103.106.155 does not respond. 02:59:00 ERROR juju.cmd.juju.commands bootstrap.go:968 failed to load model: subprocess encountered error code 255 02:59:00 DEBUG juju.cmd.juju.commands bootstrap.go:969 (error information: [{github.com/juju/juju/cmd/juju/commands .(*bootstrapCommand).Run:1067: failed to load model} {github.com/juju/juju/environs/bootstrap .Bootstrap:736 : } {github.com/juju/juju/environs/bootstrap.bootstrapIAAS:667 : } {the subprocess encountered error code 255}]) if it turns out to fix this error, check your code, Thank you again

#4

Infrastructure problem. Don’t overthink. Resolved. OpenStack Network Node MTU on OpenvSwitch. @dev-turar , we are waiting you.

1 Like
#5

Good afternoon!

I wanted to inform you that the problem was solved, the whole problem was in the wsgi server, I moved the project to the asgi server and the delay disappeared, and about why I don’t use workload status, because there is more information in the units. And I also wanted to clarify when deploying a local charm, the deployment time is longer than with charmhab, the reason may be that I keep the file locally on the PC, not in the repository?

#6

@dev-turar Glad to hear the problem is resolved. :partying_face:

About that the local charm deploy taking a bit longer (than the repo charm), I believe you’re accurate. When deploying a local charm, it needs to be uploaded to the controller. So a bit of a delay there is plausible if there’re some infrastructure issues.