search

slub / ocrd_manager

frontend for ocrd_controller and adapter towards ocrd_kitodo
MIT License
11 stars 3 forks source link

Monitor jobs and logs #27

Closed bertsky closed 2 years ago

markusweigelt commented 2 years ago

I added a env with default to docker compose and rename the port envs to more contextual scheme.

Do you think it is good to rename dozzle envs to DOZZLE instead of MONITOR? Atm the prefix of our remaining envs is service specific.

bertsky commented 2 years ago

I added a env with default to docker compose and rename the port envs to more contextual scheme.

Do you think it is good to rename dozzle envs to DOZZLE instead of MONITOR? Atm the prefix of our remaining envs is service specific.

Wait.

Why introduce an additional env var which the user likely will not comprehend when simply using double-slash would suffice on both host systems?

Also, I liked the port mnemonics just fine (it's your CONTROLLER_SSH_PORT which first deviated from the scheme).

markusweigelt commented 2 years ago

Why introduce an additional env var which the user likely will not comprehend when simply using double-slash would suffice on both host systems?

I didn't know if double-slash variant works on linux too. So if it works then no env is needed. Sorry but i can not check this so i introduced that env. Does it work for you with double slash?

Also, I liked the port mnemonics just fine (it's your CONTROLLER_SSH_PORT which first deviated from the scheme).

Ok earlier I had the impression that you had suggested it initially or it was rather your preference too. I like if it get stepwise becomes more detailed e.g. SERVICE_APPLICATION_PORT but can understand the other direction. We should just make it the same everywhere.

bertsky commented 2 years ago

I didn't know if double-slash variant works on linux too. So if it works then no env is needed. Sorry but i can not check this so i introduced that env. Does it work for you with double slash?

Yes, that works on Linux, too. (Double-slash is but a special case of non-normal path names like foo/../bar.)

I like if it get stepwise becomes more detailed e.g. SERVICE_APPLICATION_PORT but can understand the other direction.

Agreed in general, but in our case it would be SERVICE_PORT_PURPOSE for that very reason (becoming more detailled) IMO.

We should just make it the same everywhere.

Agreed.