Apologies - I was originally thinking that this would be a feature request,
but I see that it's been implemented.
- Iain.
On Wednesday, 3 May 2017 13:30:37 UTC+1, Dominic Cleal wrote:
>
> On 03/05/17 11:56, Iain Hallam wrote:
> > I've got a few hosts that are out of action for a few months, so
On 03/05/17 11:56, Iain Hallam wrote:
> I've got a few hosts that are out of action for a few months, so I'd
> expect them to be out of sync. That means they're cluttering up reports
> that would otherwise show where I need to find out what's happened. Is
> there a way to mark these hosts as
I've got a few hosts that are out of action for a few months, so I'd expect
them to be out of sync. That means they're cluttering up reports that would
otherwise show where I need to find out what's happened. Is there a way to
mark these hosts as "expected to be down" so that Foreman ignores
Ivan Necas writes:
The issues with validates_lengths_from_database should be over now.
If your tests are still failing, it's your problem now :)
-- Ivan
> Ivan Necas writes:
>
>> Tomer Brisker writes:
>>
>>> Not sure if it's related
I agree with Tomas, it's more cleaner to remove all the data right
away. Therefore I suggest that we check for these kind of objects
during initialization and if such an class is (not) found, then we can
throw an error like "Run foreman-rake plugin:clean" to delete orhpaned
records.
I am for (A)
Thanks for bringing this up. I think the right approach is to have plugin
uninstallation or rather clean up rake tasks. The clean up should IMHO delete
all data that would case problems after code removal. It shouldn't try to
revert the schema changes, but destroy all data that can cause
This issue is tightly coupled with plugin uninstallation and I think
we should solve the two problems together. At the moment there's no
standard plugin uninstallation procedure that would take care of
cleaning up the system. This is something each plugin should provide.
One thing (imho the less