Development of Planning-as-a-service

[YIDING-CODER]

Hi @haz,

The existing solver API is actually a web interface. I think it supposes to be an API endpoint? I would like to confirm how this solver endpoint will be used in future.

My Current Progress:
I have updated the package endpoint to deal with the new manifest template. Currently, I am trying to bind the solver API to a selected planner using planutils.

[haz]

I think it supposes to be an API endpoint?

Not sure I follow the question...

[YIDING-CODER]

Similarly to the package API, I thought if a user sends a POST request to http://localhost:5001/solver, the API will return a task ID to the user, and then the user can pull the plan using the task ID. Currently, http://localhost:5001/solver is returning
a webpage.

[YIDING-CODER]

In the other words, what is the functionality of http://localhost:5001/solver endpoint?

[haz]

Aha! It is there only as a bridge from the old service to the new. So it should mirror what you see on solver.planning.domains

[haz]

It's not meant to be some special shortcut way for accessing things...it's just a URL endpoint that is being deprecated, and if we don't provide that bridge, there may be a lot of unhappy planning.domains customers :P

[YIDING-CODER]

Thank you! Make sense now.

I will finalize and deploy the first draft to the testing server, and prepare a short demonstration video soon.

[YIDING-CODER]

Hi @haz and @nirlipo,

I have developed the first demo of the planning-as-service, you can run the testing notebook here.

Section1: Changes applied to Planutils:

1. Add the manifest_compact.json for lama, lama-first, kstar,cerberus-sat,enhsp-2020 and forbiditerative-topk. The manifest_compact.json is manifest that uses a template.
2. Add service template planner.json to the Template folder
3. Add converter.py to convert the manifest_compact.json to manifest.json

Section2: Changes applied to planning-as-service:

1. Update the app.py and task.py to handle the new manifest(package API)

Some comments:

1. A few planners generate more than one plan, so I used the Unix style pathname pattern in the return section of the manifest. The package API will find and return all the output plans in the result.
2. The demo server IP address is 3.136.18.23. The celery dashboard link is http://3.136.18.23:5555/.

Can you please try the demo and provide feedback?

[YIDING-CODER]

@nirlipo, I deployed it on my personal AWS EC2 instance. I didn't choose the UoM cloud server for the demo, because I am afraid the port is not open and I don't have access to manage it.

[haz]

Absolutely fine to take the protocol, but the code is in JS. The strategy:

1. Store the IP + time code when a call is made (single variable in memory)
2. If no one asks for a plan during the solve, then nothing happens.
3. If someone does, they get a "sorry, we're busy" response, and the currently executing one is given a "cool-down"
4. Whenever a new call comes in, check their IP in the "cool-down" table -- if it's been less than 10s (or whatever it's set to), then tell them the server is busy (even if it isn't)

This way, if someone bombards it, they cause themselves to cool down. Also, it just looks like a busy server if you're a student waiting 10s for a cool down because of your last solve. All in all, it worked pretty well!

[nirlipo]

Hi @YIDING-CODER I sent you info on how to access. I can help you opening the ports, let me know the protocols and id... but let's do this through email. Let me know how you go with implementing the protocol that @haz mentioned, Maybe the queue manager has already similar functionality. We can do a quick meeting to review the deployment.

[YIDING-CODER]

Hi @haz and @nirlipo,

I am a little bit lost, can I know the scope of the first release?

Below are the things that I think I should complete before the deployment:
Planutils

• Write compact manifest for all the existing packages
• (Optional) Integrate the convert function to the planutils. Users can run planutils convert command to generate the full manifest.
• Make a pull request to planutils
• (Optional) Update the Planutils docker image. The planning-as-service is relying on this docker image, and currently I have to manually update the code in the docker image.

Planning-as-service

• Do I need to work on the solve endpoint? Currently, I only updated the package endpoint.
• Implement logic to handle DDOS attacks.
• Are you happy for me to make a pull request to the master branch?

[nirlipo]

Hi @YIDING-CODER

Yes, the outline (including the optional) tasks would be in scope. Teaching Semester just finished, so lets meet to discuss further any detail (please send me a cal invite in our usual time).

What's the difference btw the package and solve endpoint?

Please make pull requests, and if needed for planutils, set a pipeline to update the docker image when needed.