I have a few common issues with how locations work in Cloudscape and fixing these would make the tool much easier to use Idea 1:  Option to exclude /32 subnets in location determination Issue addressed:  There are times when our clients don't want us to scan broadly and do true discovery, but they want Cloudscape data for their known servers.  There are also times when teams will rescan individual servers when initial login is unsuccessful.  Because those IPs have a specific subnet, the associated device gets the location information for the specific subnet.  That means it may be necessary for us to manually drag THOUSANDS of IPs to the appropriate location if we want it to appear correctly in Cloudscape. Solution detail:  In the location screen have a slider or check-box to determine whether or not /32 subnets are considered when mapping an IP to a location.  If inclusion of /32 is not checked/on, matching of subnets will use the smallest subnet that is NOT a /32.  This allows us to have a /24 subnet that has a label for Internal web servers without dragging each individual web server IP to the correct location name Idea 2: Bulk upload of locations Issue addressed: The user interface for matching IP subnets to location labels is very clunky.  It looks like it was designed/tested and demoed with a small number of subnets where the functionality seems intuitive.  THIS DOES NOT SCALE - especially if the number of subnets and labels is much larger than a page.  I have had clients with hundreds of subnets and it takes days to make all of the mappings even though we have a readily available table of subnets and names that could easily be bulk uploaded in minutes like we can do with tags and stack membership. Solution detail:  Allow a .csv file upload with subnet CIDR block in one column and subnet label in another. Idea 3: Allow location metadata for subnets that have not been scanned Issue addressed: When looking at communications details, we often have locations like rics-unknown-private.  Very frequently  these are things that are not in scope for Cloudscape discovery.  However, simply knowing it is an IP on the network is not good enough.  Solution: I would like to be able to have location labels (or an alternative set of labels specific to communications reporting) where I can add information.  For example, there may be an entire subnet of VDI clients.  I don't want to scan them (or the client doesn't want me to).  It would be much more useful to say 10.1.4.0/21 is a VDI subnet and label all comms to the subnet appropriately than to mix that in with other unknown traffic that requires research to identify.  Another use case would be  data center locations that are out of scope for scanning, but we may have information about the subnets.   ... View more

I want to be able to update cloudscape stack membership to reflect relationships from another inventory and only use "Build Stacks" for the leftovers (since doing this part is essentially "the hard way".     Problem:  While I can easily build an initial load, I can't very easily maintain my inventory if devices are removed from a stack or data in my source of truth gets updated to reflect different application mappings.  Neither the bulk upload template, nor the API provide a way to REMOVE a device from a stack.  Can you update the bulk upload template to have an action column similar to how tags work? ... View more