IPK's and port usage

[gerth2]

I've gone ahead and installed a bunch of ipk's that I could find, and have been fiddling around with making my own. Looks pretty slick, I like what this opens up.

So far, most IPK's run some small amount of code onboard the SystemCore, but then also host a website at a specific port. So far, seems like all suppliers of IPK's have avoided each other's web ports.

Is there any longer-term plan to carve out ports per supplier (with one or two reserved for team use), to help ensure there's no conflicts? or maybe a strategy to detect conflicts (IPK's declare what ports they need and user is warned on install)?

[bhjelstrom]

The plan is to expand upon the X-Port control field, but this isn't fleshed out.

What I'm personally leaning towards is enforcing the presence of that field for installation. This would allow us to detect conflicts and warn users.

One way to 'solve' this might involve a centralized port allocator. Your service makes a request to the port allocator, you receive a port, and we know what port your service is on.

[jwbonner]

Your service makes a request to the port allocator, you receive a port, and we know what port your service is on.

I could see this working for some services, but it's probably not a good fit for those that the user might want to bookmark for easy access (e.g. dashboards). Any services that rely on cookies or local storage would also be negatively affected by the URL changing regularly.

[bhjelstrom]

Yep, great point.

[PeterJohnson]

How about having a standard way to specify (and edit via the web UI) launch configuration parameters for packages, with installed defaults and "types" (e.g. port numbers). With some frontend conflict checking to flag where there are conflicts on certain parameters (e.g. it could look across all package port number configuration values and detect conflicts)?

[bhjelstrom]

The path we are on now is I think pretty close to what you're describing: a port 'retrieval' api that will provide the soon to be modifiable x-port parameter. Does that seem to cover our needs?

• this ui could expose any non immutable x-* parameter as you're saying here

[Gold872]

What I think could be a useful alternative to these issues would be to allow packages to use a custom route. For instance, AdvantageScope could have X-Route: advantagescope and it would then become accessible through robot.local/advantagescope

Not sure how feasible this is (I have almost no experience in web development) but this could be very useful

[auscompgeek]

Agreed, this'd be particularly good for anything that just needs to serve static files, like AdvantageScope or Elastic, so they don't need to reserve a port in the first place. Should probably be namespaced though, like robot.local/apps/advantagescope/, to make it impossible to confuse routes between the system and packages.

[jwbonner]

I believe Elastic is just serving static files, but AdvantageScope Lite does require its own web server with more specific functionality. One way to implement that would be to have the system web server forward traffic to another port internally.

[auscompgeek]

Thinking about this some more, it'd probably make sense for static web apps to install themselves to a known location which can get picked up. Could always write the required metadata to a file rather than requiring it to be in the package control fields, to make prototyping easier (especially for teams).