I think the issue is solved. At home, I just shutdown one of the nodes I have without adjusting any configuration and the web interface stayed operational.

Moved back to Bugs. I wasn’t saying this wasn’t a bug, I just wanted to know what the bug was more cleanly.

The bug was the text being written to the database only showed updated for any deleted item. This was due to an ajax check. When we delete something, we are doing so via ajax. The checks were only allowing writing to the db if the item in use was not coming from ajax.

While this is still valid, the change to more appropriately write data based on the action should have been available through user based ajax calls. (You had to interact to login in order to delete an item).

Ok, so the interface name wasn’t showing because somehow it was wrong in the storage node’s settings.

I never changed that… so that’s probably something broken with the auto-registering auto-correcting stuff @Tom-Elliott

Fixed will be released for RC-21.

@Wayne-Workman I know where you’re headed, and I do understand. But I really think we’re “stuck” because it’s waiting for confirmation or input.

Programs typically don’t get stuck in that sense.

The storms have passed and all sites are back online. I’m not sure how I can verify that the image replicator doesn’t quit if a node is offline. I guess I could setup a test at home but it might not be the same. Because in the real-world OP, the primary group that had the image was MIA. I’m happy you made efforts to solve it but at this moment I cannot confirm or deny they work.

@Tom-Elliott Yes solved. We need to make an SQL statement though that will set all images that only have one storage group to make that group primary. Because we have a ton of images that have no primary group but also only have one group.

RC-19 should address this issue for you more appropriately.

That would be great, since here we hire new guys to work for us during the summer.

Having a test to run the new blood through would cut my downtime to train the newbies up by a good bit.

Tom says he has fixed this in RC-17, which is now released because this was a pretty major bug - in terms of hindering everyday I.T. operations.

I’m solving and moving though, this is not a bug. The snapin never completed, and all I care about is if the start time is within the “scope” you’re searching for.

@Wayne-Workman That’s fine, I just wanted to make it somewhat documented so others who may need to use it, or are seeing similar type things have something to actually look at and use going forward.

Fix is solved in the now released RC 16.

RC - 16 released addresses image membership issues.

I took a look at the code and I don’t remember why I added that. The same likely happens for “routeraddress” and “plainaddress” as well.

I’ve republished RC-15 to have the code changes in effect to correct the installer issues in regards to these four fields. I also re-tagged the RC-15 as RC.2 is just a tag, it’s not the “version” applied to the installation.

@michael_f @Wayne-Workman @Hanz a patch has been developed and verified for this issue. It will be released with 0.11.6 (along with a few other new features) once release candidate testing finishes for the client.

Fixed in latest, thanks for reporting. Had a dyslexic typo. Where it was grabbing was from ‘hosts’, but snapins were setting hsots accidentally.