Sticky state for containers (?) when switching back and forth between the default and virtual file systems

Description

Still working on a good description. Here's a bes command file that shows the error:

The response should be to show the fnoc1 DDS and then two copies of the CSV file's DDS, but instead the second request (of the three) returns fnoc1's DDS.

Questions:

  • Is this a fail with the container, the container storage or the definitions?

  • Is this a real problem - the OLFS never issues requests like this? It seems we see this sticky behavior in a real running server when using the web interface, but I'm not able to reproduce that now

Environment

None

Activity

Show:
James Gallagher
January 12, 2019, 12:26 AM
Edited

Regarding the previous comment:

Implemented a fix. I added a method to the BESContainerStorageList that searches all of the stores and deletes every instance of a container. This will work with the OLFS, but is not how the BES was really intended to work.

For some reason, the daemon does not work while besstandalone does.

This is a problem that appears to be present on OSX only, or may have to do with the libcurl version. OSX uses:

while Centos 7 (where this code works) uses:

Close this ticket and open a new report.

Done
Your pinned fields
Click on the next to a field label to start pinning.

Assignee

James Gallagher

Reporter

James Gallagher

Labels

Fix versions

Time remaining

0m

Story Points

3