Re: Meeting Minutes : Amanda Open Source Community

[Stefan G. Weichinger]

Am 05.12.18 um 04:11 schrieb Uwe Menges:
> On 10/17/18 10:37 PM, Ashwin Krishna wrote:
>> The previous call was to understand the pain points of the community
>> in general for governance and contributions. Based on the feedback
>> from those who attended, we have come up with the action plan as
>> mentioned in the previous mail and we will drive it.
> 
> [BUMP]
> 
> I didn't see a very concrete action plan with responsibilities or dates
> in the previous e-mail.
> 
> I don't know anything about the situation at BETSOL, Zmanda, JLM with
> regards to staffing and funding for the amanda / Zmanda development (or
> in general). Or how the development process used to be, besides what can
> be seen on github.
> 
> So here's my 2ct.
> 
> As the meeting minutes state and others already pointed out we should
> probably use github with wiki. So someone with access rights should tick
> [x] Wikis on github's Settings page and/or enable Pages. AFAICS there
> are two people, martineau and NingZhangWisc according to
> .
> 
> ASAP you (or we?) should find someone to enable small PR merges so eg.
> Dustins fix PR#92 and others can get into a minor version bump later.
> 
> There probably needs to be a software architect that decides directions
> for heavier things like Chap's PR#78. Is there one? Are there (paid?)
> people working on github issues?
> 
> The suggestions from Dustin were also good and should find their way in
> some kind of roadmap (which could be a simple .md on github).
> 
> Some eg. monthly information for the community what's happening behind
> the scenes would be nice.

+2ct from me

Re: Meeting Minutes : Amanda Open Source Community

[Uwe Menges]

On 10/17/18 10:37 PM, Ashwin Krishna wrote:
> The previous call was to understand the pain points of the community
> in general for governance and contributions. Based on the feedback
> from those who attended, we have come up with the action plan as
> mentioned in the previous mail and we will drive it.

[BUMP]

I didn't see a very concrete action plan with responsibilities or dates
in the previous e-mail.

I don't know anything about the situation at BETSOL, Zmanda, JLM with
regards to staffing and funding for the amanda / Zmanda development (or
in general). Or how the development process used to be, besides what can
be seen on github.

So here's my 2ct.

As the meeting minutes state and others already pointed out we should
probably use github with wiki. So someone with access rights should tick
[x] Wikis on github's Settings page and/or enable Pages. AFAICS there
are two people, martineau and NingZhangWisc according to
.

ASAP you (or we?) should find someone to enable small PR merges so eg.
Dustins fix PR#92 and others can get into a minor version bump later.

There probably needs to be a software architect that decides directions
for heavier things like Chap's PR#78. Is there one? Are there (paid?)
people working on github issues?

The suggestions from Dustin were also good and should find their way in
some kind of roadmap (which could be a simple .md on github).

Some eg. monthly information for the community what's happening behind
the scenes would be nice.

Yours, Uwe

Re: amstatus lapsed time

[Chris Nighswonger]

On Tue, Dec 4, 2018 at 6:37 PM Uwe Menges  wrote:

> On 12/4/18 5:41 PM, Chris Nighswonger wrote:
> > So it appears that the
> > 11:29:10 part is nearly correct, but the 1+ part is clearly not.
>
> The last column is the current time for running dumps, or the last time
> it was dumping for DLEs that are already dumped (== finish time).
>
> There is special coding in place to put N+ in front of the current time
> if it was started on N day(s) before now, see
>
> https://github.com/zmanda/amanda/blob/b2fd140efb54e1ebca464f0a9ff407460d8c350b/perl/Amanda/Status.pm#L2301
>
>
The approach there is confusing at best for the unsuspecting. For example:
if the backup job were to start on one day at 23:59 and then finish up the
next at 0:59 the results would show it running for 1+ 0:59 which seems to
imply it has run for 24 hours plus 59 minutes. Reading the code (along with
your explanation) clears this up showing that what is being stated is that
the dump finished up at 12:59a on the day after it was started.

I notice that the man page for amstatus does not cover the output format. A
header line like that given in amreport might be helpful in avoiding such
confusion. Something like this:
https://github.com/zmanda/amanda/blob/b2fd140efb54e1ebca464f0a9ff407460d8c350b/perl/Amanda/Report/human.pm#L386

Kind regards,
Chris

Re: amstatus lapsed time

[Uwe Menges]

On 12/4/18 5:41 PM, Chris Nighswonger wrote:
> So when I run amstatus  I see stuff like this:
> 
> From Mon Dec  3 22:00:01 EST 2018
> 
> 
> 
> 1359952k dumping   533792k (148.30%) (1+11:29:10)
> 
> For reference:
> 
> backup@scriptor:~ date
> Tue Dec  4 11:37:07 EST 2018
> 
> I'm assuming that the last field is the time the dumper has been
> running. But that is impossible as this dump began at 2200 yesterday and
> amstatus was run at 1129 today (12:29 later). So it appears that the
> 11:29:10 part is nearly correct, but the 1+ part is clearly not.

The last column is the current time for running dumps, or the last time
it was dumping for DLEs that are already dumped (== finish time).

There is special coding in place to put N+ in front of the current time
if it was started on N day(s) before now, see
https://github.com/zmanda/amanda/blob/b2fd140efb54e1ebca464f0a9ff407460d8c350b/perl/Amanda/Status.pm#L2301

Yours, Uwe

Re: amstatus lapsed time

[Chris Nighswonger]

On Tue, Dec 4, 2018 at 1:51 PM Debra S Baddorf  wrote:

> > On Dec 4, 2018, at 12:49 PM, Chris Nighswonger <
> cnighswon...@foundations.edu> wrote:
> >
> > On Tue, Dec 4, 2018 at 1:44 PM Debra S Baddorf  wrote:
> > Well, for starters,  2200 to 1129  is 13:29  so that doesn’t match up
> either.
> >
> > Talk about bad math
> >
> > Not to loud... I'll loose my job teaching math. ;-)
>
> LOL!   Well,  I was your A++ pupil,  so don’t feel too bad.  I had already
> read the book,
> and so could pay attention to the derivations the prof was doing,  and
> correct his errors.
> They appreciated it,  so the end of the derivation would work right.


I wonder if it is only coincidental that I was grading Physics tests
today

Way too many numbers in any case. Better go back and check over the grades.

Chris

Re: amstatus lapsed time

[Debra S Baddorf]

> On Dec 4, 2018, at 12:49 PM, Chris Nighswonger  
> wrote:
> 
> On Tue, Dec 4, 2018 at 1:44 PM Debra S Baddorf  wrote:
> Well, for starters,  2200 to 1129  is 13:29  so that doesn’t match up either. 
> 
> Talk about bad math
> 
> Not to loud... I'll loose my job teaching math. ;-)


LOL!   Well,  I was your A++ pupil,  so don’t feel too bad.  I had already read 
the book,
and so could pay attention to the derivations the prof was doing,  and correct 
his errors.
They appreciated it,  so the end of the derivation would work right.

Deb Baddorf

Re: amstatus lapsed time

[Chris Nighswonger]

On Tue, Dec 4, 2018 at 1:44 PM Debra S Baddorf  wrote:

> Well, for starters,  2200 to 1129  is 13:29  so that doesn’t match up
> either.
>

Talk about bad math

Not to loud... I'll loose my job teaching math. ;-)

Re: amstatus lapsed time

[Debra S Baddorf]

Well, for starters,  2200 to 1129  is 13:29  so that doesn’t match up either.   
Somebody who know more?
Deb Baddorf

> On Dec 4, 2018, at 10:41 AM, Chris Nighswonger  
> wrote:
> 
> So when I run amstatus  I see stuff like this:
> 
> From Mon Dec  3 22:00:01 EST 2018
> 
> 
> 
> 1359952k dumping   533792k (148.30%) (1+11:29:10)
> 
> For reference:
> 
> backup@scriptor:~ date
> Tue Dec  4 11:37:07 EST 2018
> 
> I'm assuming that the last field is the time the dumper has been running. But 
> that is impossible as this dump began at 2200 yesterday and amstatus was run 
> at 1129 today (12:29 later). So it appears that the 11:29:10 part is nearly 
> correct, but the 1+ part is clearly not. I've noted in amreport  that 
> the time lapsed time estimates appear grossly incorrect as well. ie:
> 
>   Total   Full  Incr.   Level:#
>         
> Estimate Time (hrs:min) 0:07
> Run Time (hrs:min)  1:57
> Dump Time (hrs:min)28:13  26:27   1:46
> 
> Perhaps "Dump Time" is cumulative across all dumpers? That still does not 
> seem to explain the amstatus discrepancy.
> 
> What am I missing?
> 
> Kind regards,
> Chris

amstatus lapsed time

[Chris Nighswonger]

So when I run amstatus  I see stuff like this:

>From Mon Dec  3 22:00:01 EST 2018



1359952k dumping   533792k (148.30%) (1+11:29:10)

For reference:

backup@scriptor:~ date
Tue Dec  4 11:37:07 EST 2018

I'm assuming that the last field is the time the dumper has been running.
But that is impossible as this dump began at 2200 yesterday and amstatus
was run at 1129 today (12:29 later). So it appears that the 11:29:10 part
is nearly correct, but the 1+ part is clearly not. I've noted in amreport
 that the time lapsed time estimates appear grossly incorrect as
well. ie:

  Total   Full  Incr.   Level:#
        
Estimate Time (hrs:min) 0:07
Run Time (hrs:min)  1:57
Dump Time (hrs:min)28:13  26:27   1:46

Perhaps "Dump Time" is cumulative across all dumpers? That still does not
seem to explain the amstatus discrepancy.

What am I missing?

Kind regards,
Chris