[Ci-users] Upcoming Feature: extendable sessions

Tue Nov 24 08:13:08 UTC 2015
Karanbir Singh <mail-lists at karan.org>

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 at 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