Question about deployment and WAMPlets

#1

Hi all,

I’m starting to think about the final deployment of WAMP applications built with Crossbar + Autobahn|Python. I’ve also read the info I could find on WAMPlets.

In my case, the application will consist of ~10 components. During development, some of them are guests (simulators for various hardware devices), but in production I think it will be 100% native containers.

Some questions:

  1. In the votegame example README.md, it says “A WAMPlet can be thought of a reusable application component that can be deployed dynamically as needed.”. In what way are WAMPlets dynamically deployable? Must I not specify them statically in the Crossbar configuration? Also, the config.json presented in that example doesn’t seem to be valid if looking at the .
  2. What will running components as native containers currently give me, as opposed to running them as guests or even standalone scripts? Crossbar will start them for me, that’s a plus. Anything else? (Considering the management API is not finalized yet AFAIK). To me, I kind of like being able to start/stop individual components without having to bring down the entire node, which is why I’m asking.
  3. Just so I’m clear: If I am to go the WAMPlet route, then I would deploy my application as a regular Python distribution, and specify one autobahn.twisted.wamplet entry point for each component of my application? What benefit will deploying as WAMPlets give me? I guess the benefit right now is that I can install my application package using setuptools like as usual, instead of pointing the Crossbar configuration at some scripts that are just lying around?
    I’d love to hear from people who are also starting to think about deployment, or who already have a good system set up.

Best regards,

Elvis Stansvik

0 Likes

#2

Hi all,

I’m starting to think about the final deployment of WAMP applications built with Crossbar + Autobahn|Python. I’ve also read the info I could find on WAMPlets.

In my case, the application will consist of ~10 components. During development, some of them are guests (simulators for various hardware devices), but in production I think it will be 100% native containers.

Some questions:

  1. In the votegame example README.md, it says “A WAMPlet can be thought of a reusable application component that can be deployed dynamically as needed.”. In what way are WAMPlets dynamically deployable? Must I not specify them statically in the Crossbar configuration? Also, the config.json presented in that example doesn’t seem to be valid if looking at the .

Lost some words here. Was supposed to be “… if looking at the configuration documentation.”.

Elvis

···

On Tuesday, April 14, 2015 at 3:02:20 PM UTC+2, Elvis Stansvik wrote:

  1. What will running components as native containers currently give me, as opposed to running them as guests or even standalone scripts? Crossbar will start them for me, that’s a plus. Anything else? (Considering the management API is not finalized yet AFAIK). To me, I kind of like being able to start/stop individual components without having to bring down the entire node, which is why I’m asking.
  2. Just so I’m clear: If I am to go the WAMPlet route, then I would deploy my application as a regular Python distribution, and specify one autobahn.twisted.wamplet entry point for each component of my application? What benefit will deploying as WAMPlets give me? I guess the benefit right now is that I can install my application package using setuptools like as usual, instead of pointing the Crossbar configuration at some scripts that are just lying around?
    I’d love to hear from people who are also starting to think about deployment, or who already have a good system set up.

Best regards,

Elvis Stansvik

0 Likes

#3

Hi all,

I’m starting to think about the final deployment of WAMP applications built with Crossbar + Autobahn|Python. I’ve also read the info I could find on WAMPlets.

In my case, the application will consist of ~10 components. During development, some of them are guests (simulators for various hardware devices), but in production I think it will be 100% native containers.

Some questions:

  1. In the votegame example README.md, it says “A WAMPlet can be thought of a reusable application component that can be deployed dynamically as needed.”. In what way are WAMPlets dynamically deployable? Must I not specify them statically in the Crossbar configuration? Also, the config.json presented in that example doesn’t seem to be valid if looking at the .
  2. What will running components as native containers currently give me, as opposed to running them as guests or even standalone scripts? Crossbar will start them for me, that’s a plus. Anything else? (Considering the management API is not finalized yet AFAIK). To me, I kind of like being able to start/stop individual components without having to bring down the entire node, which is why I’m asking.
  3. Just so I’m clear: If I am to go the WAMPlet route, then I would deploy my application as a regular Python distribution, and specify one autobahn.twisted.wamplet entry point for each component of my application? What benefit will deploying as WAMPlets give me? I guess the benefit right now is that I can install my application package using setuptools like as usual, instead of pointing the Crossbar configuration at some scripts that are just lying around?
    I’d love to hear from people who are also starting to think about deployment, or who already have a good system set up.

A little followup question: So say I go with the WAMPlet approach and deploy my app regularly using setuptools. Would you also install the config.json (or config.yml in my case actually) somewhere as part of the python setup.py install? To me it would make sense to do so, as I’d like everything required by the application installed in the python setup.py install step. But perhaps that’s kind of unorthodox? And to where would I install it? Or would you simply not install it, and instead just provide some instructions like “please run crossbar start in this the bla bla directory to start the application”?

I’ve read that Crossbar should be thought of as an appliance, a “fire and forget” kind of thing. But to me it does not really seem like an appliance when its configuration (config.json) is so intimately tied to the application. Certainly you’re supposed to run one Crossbar node per application? It feels more like a tool than an appliance.

Elvis

···

On Tuesday, April 14, 2015 at 3:02:20 PM UTC+2, Elvis Stansvik wrote:

Best regards,

Elvis Stansvik

0 Likes

#4

Hi all,

I’m starting to think about the final deployment of WAMP applications built with Crossbar + Autobahn|Python. I’ve also read the info I could find on WAMPlets.

In my case, the application will consist of ~10 components. During development, some of them are guests (simulators for various hardware devices), but in production I think it will be 100% native containers.

Some questions:

  1. In the votegame example README.md, it says “A WAMPlet can be thought of a reusable application component that can be deployed dynamically as needed.”. In what way are WAMPlets dynamically deployable? Must I not specify them statically in the Crossbar configuration? Also, the config.json presented in that example doesn’t seem to be valid if looking at the .

Lost some words here. Was supposed to be “… if looking at the configuration documentation.”.

By the way, about that documentation, at http://crossbar.io/docs/Container-Configuration/ the documentation says:

"For the type wamplet, you need to set

package: The name of the installed Python package (required)

entrypoint: The name of the file within the package to execute (required)"

Surely the entrypoint should be the name of an entry point defined in the setup.py and not a file within the package? Also, with package here, do you mean a Python package, or the name of a Python distribution? Looking at the votegame example config.json, it seems this setting was previously called “dist”, which is why I’m asking.

Elvis

···

On Tuesday, April 14, 2015 at 3:03:45 PM UTC+2, Elvis Stansvik wrote:

On Tuesday, April 14, 2015 at 3:02:20 PM UTC+2, Elvis Stansvik wrote:

Elvis

  1. What will running components as native containers currently give me, as opposed to running them as guests or even standalone scripts? Crossbar will start them for me, that’s a plus. Anything else? (Considering the management API is not finalized yet AFAIK). To me, I kind of like being able to start/stop individual components without having to bring down the entire node, which is why I’m asking.
  2. Just so I’m clear: If I am to go the WAMPlet route, then I would deploy my application as a regular Python distribution, and specify one autobahn.twisted.wamplet entry point for each component of my application? What benefit will deploying as WAMPlets give me? I guess the benefit right now is that I can install my application package using setuptools like as usual, instead of pointing the Crossbar configuration at some scripts that are just lying around?
    I’d love to hear from people who are also starting to think about deployment, or who already have a good system set up.

Best regards,

Elvis Stansvik

0 Likes

#5

Hi all,

I’m starting to think about the final deployment of WAMP applications built with Crossbar + Autobahn|Python. I’ve also read the info I could find on WAMPlets.

In my case, the application will consist of ~10 components. During development, some of them are guests (simulators for various hardware devices), but in production I think it will be 100% native containers.

Some questions:

  1. In the votegame example README.md, it says “A WAMPlet can be thought of a reusable application component that can be deployed dynamically as needed.”. In what way are WAMPlets dynamically deployable? Must I not specify them statically in the Crossbar configuration? Also, the config.json presented in that example doesn’t seem to be valid if looking at the .

Another thing about that example: The make factory method in backend.py returns a description like {‘label’: ‘…’, ‘description’: ‘…’} if not given a configuration. Where is this format documented? Where is this description used? There’s nothing about it in the documentation of the make parameter of ApplicationRunner.run(…).

Elvis

···

On Tuesday, April 14, 2015 at 3:02:20 PM UTC+2, Elvis Stansvik wrote:

  1. What will running components as native containers currently give me, as opposed to running them as guests or even standalone scripts? Crossbar will start them for me, that’s a plus. Anything else? (Considering the management API is not finalized yet AFAIK). To me, I kind of like being able to start/stop individual components without having to bring down the entire node, which is why I’m asking.
  2. Just so I’m clear: If I am to go the WAMPlet route, then I would deploy my application as a regular Python distribution, and specify one autobahn.twisted.wamplet entry point for each component of my application? What benefit will deploying as WAMPlets give me? I guess the benefit right now is that I can install my application package using setuptools like as usual, instead of pointing the Crossbar configuration at some scripts that are just lying around?
    I’d love to hear from people who are also starting to think about deployment, or who already have a good system set up.

Best regards,

Elvis Stansvik

0 Likes