hi,
I'm going to be working on extending the admin.ci API. The intention is to add the following calls:
/Session/get?key=<api key>&alias=<some text> : this will create a new session for the api key specified, but will not allocate any nodes to this session. The alias param is optional, if specified the session can be referenced with that alias ( in addition to / rather than the ssid ).
/Session/done?key=<api key>&ssid=<ssid | alias for session > : this will tear down the session, including all Nodes allocated to the session. The ssid can be specified as either the UUID based ssid returned from the /Session/get call or the alias requested.
In addition to these two new calls, the /Node/get call will get an optional ssid= param; calling /Node/get with an ssid will add the requested nodes to the existing session, rather than create a new session. The ssid can be either the uuid based ssid allocated at /Session/get or an alias to an existing session.
The /Node/done call will also get an optional additional param in node= where you can specify the hostname of the machine to be dropped from an existing session, without terminating the entire session.
With these four changes going in, it would be possible to setup a session, add nodes to that session as they are needed, drop hosts as required, and then tear down the session when done. The alias option could be used for various things, including accounting by job name, job type etc.
Existing scripts that use the API will not need any changes, there will be no change to the existing calls.
Good to know !
Please note that I added a comment in the RFE for this feature saying it was no longer a priority for us as we worked around the limitation. If you are adding this for other purposes, do go ahead :)
David Moreau Simard Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
On Mon, Nov 23, 2015 at 7:00 PM, Karanbir Singh mail-lists@karan.org wrote:
hi,
I'm going to be working on extending the admin.ci API. The intention is to add the following calls:
/Session/get?key=<api key>&alias=<some text> : this will create a new session for the api key specified, but will not allocate any nodes to this session. The alias param is optional, if specified the session can be referenced with that alias ( in addition to / rather than the ssid ).
/Session/done?key=<api key>&ssid=<ssid | alias for session > : this will tear down the session, including all Nodes allocated to the session. The ssid can be specified as either the UUID based ssid returned from the /Session/get call or the alias requested.
In addition to these two new calls, the /Node/get call will get an optional ssid= param; calling /Node/get with an ssid will add the requested nodes to the existing session, rather than create a new session. The ssid can be either the uuid based ssid allocated at /Session/get or an alias to an existing session.
The /Node/done call will also get an optional additional param in node= where you can specify the hostname of the machine to be dropped from an existing session, without terminating the entire session.
With these four changes going in, it would be possible to setup a session, add nodes to that session as they are needed, drop hosts as required, and then tear down the session when done. The alias option could be used for various things, including accounting by job name, job type etc.
Existing scripts that use the API will not need any changes, there will be no change to the existing calls.
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
Hi,
On 24/11/15 00:47, David Moreau Simard wrote:
Good to know !
Please note that I added a comment in the RFE for this feature saying it was no longer a priority for us as we worked around the limitation. If you are adding this for other purposes, do go ahead :)
There are a couple of use cases that came up that could benefit from having sessions be disconnected from stack of nodes. eg. a storage cluster, can be built up, tested as such and nodes can be added opportunistically for scale out tests ( say, once a week etc ).
Secondly, we are likely going to need a cloud like setup in the near to mid term future, and we will likely not have reap/reclaim run on those nodes nearly as aggressively as we do on the bare metal.
Thirdly, there were a few requests were users want session to be tied into the job itself. In that case the session would never expire, just nodes would get added when needed, and discarded when done. We could work around this with just issuing api keys, but I want to try and use the keys to track projects, and sessions for tracking the jobs themselves.
Finally, when we start implementing the vlan isolation things on the bare metal nodes, we might need a session-setup and session-teardown that is disconnected from node-allocate and node-reclaim, so these calls would just be exposing code that needs to be done behind the scenes anyway ( but this isnt confirmed yet! ).
Regards,
David Moreau Simard Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
On Mon, Nov 23, 2015 at 7:00 PM, Karanbir Singh mail-lists@karan.org wrote:
hi,
I'm going to be working on extending the admin.ci API. The intention is to add the following calls:
/Session/get?key=<api key>&alias=<some text> : this will create a new session for the api key specified, but will not allocate any nodes to this session. The alias param is optional, if specified the session can be referenced with that alias ( in addition to / rather than the ssid ).
/Session/done?key=<api key>&ssid=<ssid | alias for session > : this will tear down the session, including all Nodes allocated to the session. The ssid can be specified as either the UUID based ssid returned from the /Session/get call or the alias requested.
In addition to these two new calls, the /Node/get call will get an optional ssid= param; calling /Node/get with an ssid will add the requested nodes to the existing session, rather than create a new session. The ssid can be either the uuid based ssid allocated at /Session/get or an alias to an existing session.
The /Node/done call will also get an optional additional param in node= where you can specify the hostname of the machine to be dropped from an existing session, without terminating the entire session.
With these four changes going in, it would be possible to setup a session, add nodes to that session as they are needed, drop hosts as required, and then tear down the session when done. The alias option could be used for various things, including accounting by job name, job type etc.
Existing scripts that use the API will not need any changes, there will be no change to the existing calls.
On Mon, Nov 23, 2015 at 7:00 PM, Karanbir Singh mail-lists@karan.org wrote:
Existing scripts that use the API will not need any changes, there will be no change to the existing calls.
Assuming this last part is true (and I have no doubt it is) I like the idea of separating the machine getting from the session creation. As is obvious by this API change, your script would be able to allocate as needed, instead of "in advance".
So +1, great idea!
Cheers, James