Opened 9 years ago

Closed 9 years ago

#759 closed enhancement (complete)

Conversion of cfgmgr to use the new logging interface

Reported by: stephen Owned by: jelte
Priority: medium Milestone: Sprint-20110712
Component: logging Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 2.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

This is dependent on ticket #756, and involves converting the files in src/bin/cfgmgr to use the new logging interface.

Subtickets

Change History (12)

comment:1 Changed 9 years ago by stephen

  • Defect Severity set to N/A
  • Milestone changed from Year 3 Task Backlog to Sprint-20110628
  • Sub-Project set to DNS

comment:2 Changed 9 years ago by stephen

  • Estimated Difficulty changed from 0.0 to 2

comment:3 Changed 9 years ago by jelte

  • Owner set to jelte
  • Status changed from new to assigned

comment:4 Changed 9 years ago by jelte

  • Owner changed from jelte to UnAssigned
  • Status changed from assigned to reviewing

since cfgmgr is not a 'normal' module (in the sense that it doesn't use ModuleCCSession), handling of log config is slightly different than normal. OTOH, there were not that many messages printed, so the messages file is comparatively short.

comment:5 Changed 9 years ago by vorner

  • Owner changed from UnAssigned to vorner

comment:6 follow-up: Changed 9 years ago by vorner

  • Owner changed from vorner to jelte

Hello

I tried to write the logging API so it shouldn't be needed to call str on every parameter. You tried it and it didn't work (therefore it's bug in the API) or you just put them there automatically?

Why is cfgmgr_messages.py both in python_PYTHON and python_SCRIPTS? Is it really needed to be executable? Isn't some kind of EXTRA_DIST on the message file needed?

I believe CFGMGR_DATA_READ_ERROR should be fatal, not error, as the manager can't continue after that.

comment:7 Changed 9 years ago by vorner

Hmm, and it fails in check, „Didn't find a call to isc.util.process.rename in src/src/lib/python/isc/config/cfgmgr_messages.py“, which is probably related to the SCRIPTS thing.

comment:8 in reply to: ↑ 6 ; follow-up: Changed 9 years ago by jelte

  • Owner changed from jelte to vorner

Replying to vorner:

Hello

I tried to write the logging API so it shouldn't be needed to call str on every parameter. You tried it and it didn't work (therefore it's bug in the API) or you just put them there automatically?

Oh, no that's just an effect from trying to do the call conversion as automatic as possible, removed them

Why is cfgmgr_messages.py both in python_PYTHON and python_SCRIPTS? Is it really needed to be executable? Isn't some kind of EXTRA_DIST on the message file needed?

Hmm, and it fails in check, „Didn't find a call to isc.util.process.rename in src/src/lib/python/isc/config/cfgmgr_messages.py“, which is probably related to the SCRIPTS thing.

It was to get it both regenerated automatically and installed in the right place. But I've removed the _SCRIPTS and added the generation target to all-local, and the source file to EXTRA_DIST, so it should work now

I believe CFGMGR_DATA_READ_ERROR should be fatal, not error, as the manager can't continue after that.

ok (CFGMGR_CC_SESSION_ERROR too then, btw)

comment:9 in reply to: ↑ 8 ; follow-up: Changed 9 years ago by vorner

  • Owner changed from vorner to jelte

Hello

Replying to jelte:

It was to get it both regenerated automatically and installed in the right place. But I've removed the _SCRIPTS and added the generation target to all-local, and the source file to EXTRA_DIST, so it should work now

This failed with distcheck on clean source tree, because it tried to distribute the generated file as well. I pushed fix for that, but now it fails because distcheck builds out of source tree, therefore the file is not found during build (as it finds the supermodule in the source directory, this one is in the build directory).

I don't have an idea how to solve this right now. Would you have one?

It looks OK otherwise. Why the biggest problem is the build system always?

Thanks

comment:10 in reply to: ↑ 9 Changed 9 years ago by jelte

  • Owner changed from jelte to vorner

Replying to vorner:

This failed with distcheck on clean source tree, because it tried to distribute the generated file as well. I pushed fix for that, but now it fails because distcheck builds out of source tree, therefore the file is not found during build (as it finds the supermodule in the source directory, this one is in the build directory).

I don't have an idea how to solve this right now. Would you have one?

took a bit (been trying out several clean builds in several scenario's), but i think i have a solution for now (as discussed on jabber); make it pyexec_DATA, like the messages files for xfrout and xfrin, and add the config path to the correct test makefile paths. Could you please see if it works for you too?

comment:11 Changed 9 years ago by vorner

  • Owner changed from vorner to jelte

Yes, this works. It is not nice, but we probably don't have anything better now, so please merge.

comment:12 Changed 9 years ago by jelte

  • Resolution set to complete
  • Status changed from reviewing to closed

Thanks, merged, closing ticket.

Note: See TracTickets for help on using tickets.