Criteria	Usage
Questions with keyword1 or keyword2	keyword1 keyword2
Questions with a mandatory word, e.g. keyword2	keyword1 +keyword2
Questions excluding a word, e.g. keyword2	keyword1 -keyword2
Questions with a specific tag and keyword(s)	+[tag1] keyword1
Questions with two or more specific tags and keyword(s)	+[tag1] +[tag2] keyword1
To search for all posts by a user or all posts with a specific tag, start typing and choose from the suggestion list.

Omri Avraham suggested an idea (#655) · Aug 25, 2016 at 03:26 PM · cloudshell scripts driver development cloudshell 9.2

Storing Reservation specific information for later use

On some cases, information is required to be stored for later use in a reservation, and having a place to store such information can save us from re doing the whole searching in the second command. i.e. Setup command find all switch in the reservation, and extract user\pass info, sshing to them for the workflow. Teardown at the end, need to restore all switches to default, for that the whole searching and extracting information is required again. if we had a reservation based variable that we could store such information, the Teardown would only have to access the variable, and as it's Reservation field that can be in the 'Context', it would come 'cost-free' to the Teardown function. *the variable shouldn't be visible to the end user, as it can be used to store clear-text passwords.

Chris Grabosky commented · Aug 26, 2016 at 01:17 PM

How would this be affected if the sandbox has changed since the variable has been stored? For example, a new resource was added post-setup? Then the variable would have stale data and the teardown may leave resources in a bad state.

Omri Avraham commented · Aug 28, 2016 at 09:05 AM

for that case, i wouldn't recommended using this attribute. as it should be used for information that user cannot interfere with. (like a VPN gateway access details for that user reservation, or core networking which the user cannot interact with).

Maya Ber commented · Sep 05, 2016 at 11:39 AM

Hi Omri, is there a reason not to store such data at the resource level?

Jim Pfleger commented · Oct 05, 2016 at 09:08 PM

I have another example. I'm calling out to another system during reservation setup and that system returns a unique ID specific to the reservation. I need to save that ID somewhere for use by the teardown script. Right now I'm saving it to a file named for the reservation ID, but that doesn't scale past a single execution server. A simple key-value store at the reservation level (stored centrally and shared across execution servers) would address this.

3 · Show 1

Chris Grabosky · Oct 10, 2016 at 12:36 PM 0

That makes sense, Jim. Thanks for the clarification.

Jacob Adams commented · Nov 06, 2017 at 07:48 PM

This is a great example. In our case, we are triggering a function which returns a UUID that is only show to us once. We need to use this UUID in teardown, so need an easy place to store it while teardown depending on which scripts/setup/teardown/commands need it. It's a simple way to connect info between separate scripts.

Dan Klingler commented · Nov 07, 2017 at 03:47 PM

This is a REALLY great idea. We've always had to go through unnatural acts to store data in odd places that needed to be passed from 'setup' to 'teardown'. Not having this capability now is truly a shortcoming of the product IMO. This would be a great capability/feature!

Kimo Saper commented · Jun 20, 2018 at 10:35 PM

Items/information created during setup that might be needed later in teardown would be solved for this - I would think that we could have a Blueprint Global Input, but Type==Hidden - it's there via API and can be managed as part of the Blueprint (or blueprint template), but wouldn't appear in the reservation window.

Natti Katz commented · Dec 09, 2018 at 03:24 PM

Great Idea. I recently just had to store a list of A records to be deleted from a DNS server created on setup. I ended up storing a comma separated list inside a TXT record on the DNS server itself - but it could just as easily have gone into some kind of global variable.

Alona Getzler commented · Dec 10, 2018 at 01:24 PM

Hi all,

I'm happy to update that this idea is planned for one of the coming releases. We started working on an initial design and this is what we currently have in mind:

Each sandbox will have a SandboxData object associated with it, not visible in the UI (or only to admins and domain-admins? is this required?)
The SandboxData object will be of type string and constructed as a JSON, input will be in "key:value" format
We will expose the following APIs
- UpdateSandboxData (inputs: reservationId,key,value; no output)
- GetSandboxData (inputs: reserationId; output: data)
- ClearSandboxData (inputs: reservationId; no output)
Optionally, the SandboxData will be available in the reservation context for scripts and drivers
The SandboxData content won't be encrypted

Any feedback and comments on the above design will be highly appreciated.

Thanks,
Alona.

5 · Show 1

Leeor Vardi · Jan 24, 2019 at 04:29 PM 0

I like everything you've listed here, except the APIs.

The API should not be for updating or retrieving the entire data at once, but allow for more granularity (if you need to add/update specific keys).

I would suggest the following:

UpdateSandboxData (resertaion_id, **updates): where updates is a python dictionary comprising of Strings only, and the server will update each value in the sandbox data that appears in the input, or add it as a new key if it did not previously exist (but not delete existing keys).
GetSandboxData (reservation_id, *keys_list): Should return the entire SandboxData as a python dictionary if keys_list is not specified or is an empty list, but should return a dictionary containing only values of the requested keys if a list of keys is sent in keys.
ClearSandboxData(reservation_id, *keys_list): clear the entire sandbox data if no keys passed, otherwise clear only the specified keys.

Also, the contents should be encrypted while in the DB, but not when returned.

Omri Avraham commented · Jan 16, 2019 at 10:43 PM

hi Alona,

it sounds great.

i would like to suggest allowing it to be viewed via the web ui for domain admin & admins. as the stored info might be required for debugging and not every cloudshell admin is also a python expert

for the general structure of the data, is there going to be any limit of how many characters we can store or how many keys, as well as if we can store any value? (e.g. nested JSONs)

2 · Show 1

Alona Getzler · Feb 12, 2019 at 08:57 AM 0

Hi, thank you for the comments!
We will consider exposing this data in the UI for admin. In regard to the data structure, it is going to be a key:value structure, and there won't be any limit on the amount of characters or number of keys. You'll be able to store nested JSONs or any other type of textual content.

Announcements >
CloudShell >	TestShell >
Developers >	BI (Business Inteligence) >

CloudShell's Dev Guide >	Configuration Management >
Getting started with Shells >	Extending CloudShell with Cloud Providers >
Getting started with Orchestration >	API Guide >

Announcements
CloudShell	TestShell
Developers	BI (Business Inteligence)

CloudShell's Dev Guide	Configuration Management
Getting started with Shells	Extending CloudShell with Cloud Providers
Getting started with Orchestration	API Guide

Welcome to Quali's Community Forums!

Quali's Idea Box!

Quali's Community Integrations

Storing Reservation specific information for later use

13 comments

Welcome to Quali's Community Forums!

Welcome to Quali's Idea Box!

Quali's Community Integrations

Your Opinion Counts

Follow This Idea

Related Ideas