@GeoffA and @Flox
Yes, I’ve noticed this myself but haven’t as yet gotten around to looking any further.
I think the current state of reporting the ‘now’ time is just not useful but it would be useful to have the pool creation time, at least from our our db point of view. In which case I vote for:
Although as stated we could run into some unexpected behaviour here. I would say that the current auto_now setting was a stop gap that never got re-addressed until now. And has only just come up. But yet, pool creation date (from btrfs) or as a simpler implementation and to keep the number of btrfs calls down the import data would at least be more usefully than our current meaningless now attribute.
Agreed. @GeoffA if you fancy creating a issue for this, given you are I believe the first to have noticed and reported this, that would server as the all important attribution element and hopefully we can make this a more useful element in the pool info. Or we remove it entirely which would be better than our current near meaningless info.
As @Flox points out, we save the pool all the time, we updating it with current system state to reflect that within the Web-UI. But I don’t see this metric being of interest to the end user. I suppose we could keep it as some kind of internal check on if we have recently updated the pool info but this would seem a little redundant as if we fail to save we get a Django error anyway.
So I personally would like to see this as set once during pool import and to represent the actual pool creation date. Not our pool model creation date. As long as we only set this during import it shouldn’t represent an additional presser on our already fairly heavy btrfs call count. The simpler model creation time seems like we would be cheaping out a little. All thoughts welcome. But the text could help to clarify this, i.e. “Poll creation date on import” or something like that. As there are potential situations where a pool is re-created under Rockstor by the same name and this way we cheap out just a little less. I’m just concerned that we are making a massive number of btrfs calls and don’t want to add load for something that has come up exactly once.
But I wholely agree that we should get this sorted because it is, as-is, a little shabby and just plain wrong.
@Flox Thanks for looking into this, much appreciated. I had just assumed myself it was a now placeholder and not looked any further. But now it’s come up it would be a nice one of the thankfully dwindling paper cuts we still have within the Web-UI.
@GeoffA Thanks for yet another keen observation and do please consider creating a GitHub issue for this as attribution is super important and it may well be with one extra grep equivalent we can grab this during a pool import and avoid future updates by carefull wording within the Web-UI.
As always all thoughts welcome. But I favour representing the actual pool creation date as otherwise we don’t fully fix this and miss the chance to represent what at least back when was considered a nice to have. And creation date would be nice to surface.
So my vote is for actual pool creation with the caveat that I’d rather not add a refresh on every pool refresh which as it goes is fairly often.