[racktables-users] Re: expirations page, hardcoded values
- From: Matthew Castanien <mcastanien@xxxxxxxxx>
- To: "racktables-users@xxxxxxxxxxxxx" <racktables-users@xxxxxxxxxxxxx>
- Date: Tue, 15 Jul 2014 22:05:41 -0400
Another option is to have a field on the 'User Interface' page that says which
IDs to include on the expiration date report. We had a similar issue you had,
and I submitted a change that got included in a future release. I recommend you
test then submit changes to the code or submit a feature request to the
project. We all are aware of best practice and 'bad ideas', but the beauty is
that if you find something that can be improved you have the power to add
value. We all are busy...
Matthew Castanien
Sent from my phone
On Jul 15, 2014, at 7:51 PM, "Miller, RussellX J" <russellx.j.miller@xxxxxxxxx>
wrote:
> Here at Intel OTC we've been using racktables and are so far pretty happy
> with it. There are a lot of things I would like to see, but maybe I'll do
> some contributing if I get time. Here's the first problem I've encountered
> (I didn't want to file a bug because I'm not sure it's a bug, but more a
> design problem).
>
> I created a dictionary entry for our servers so that we can store the
> expiration date of our DRAC certificates. Naturally, I then moved over to
> the reports page, because I wanted to see if a report would be generated for
> the DRAC certificate field. There was no such entry. So I dug in to see
> what was required.
>
> What I found was this:
>
> $breakdown[21] = array
> (
> array ('from' => -365, 'to' => 0, 'class' => 'has_problems_',
> 'title' => 'has expired within last year'),
> array ('from' => 0, 'to' => 30, 'class' => 'row_', 'title' =>
> 'expires within 30 days'),
> array ('from' => 30, 'to' => 60, 'class' => 'row_', 'title' =>
> 'expires within 60 days'),
> array ('from' => 60, 'to' => 90, 'class' => 'row_', 'title' =>
> 'expires within 90 days'),
> );
> $breakdown[22] = $breakdown[21];
> $breakdown[24] = $breakdown[21];
>
> Digging in further, I found that 21, 22, and 24 are the attribute IDs of the
> three dictionary entries on install. Adding the new attribute ID (10003)
> magically added the appropriate date field to the page.
>
> I don't want to do it this way. Making changes to hardcoded values in code
> is a Bad Idea. In my opinion, hardcoding attribute types like this is also a
> bad idea, but baby steps, I suppose. That also creates (I believe) a 10,000
> entry array, and that has memory implications.
>
> In my opinion, there should be an attribute attribute of some kind - perhaps
> tied in to the [T] date attribute type, that says "include this on expiration
> reports". It may even be reasonable to just automatically include anything
> that has a [T]date type in that report. Should I file a bug report after
> all? Perhaps if I get time I'll submit a patch.
>
> --Russell
>
>
>
> Russell Miller
> Sysadmin - OTC
> russellx.j.miller@xxxxxxxxx
>
>
>
Other related posts:
