Mailing List Archive

On Jun 4, 2010, at 9:51 AM, Matthew Rolf wrote:

> I recognize the following situation is somewhat unique, but bear with me.
>
> Between 1.11.x and v 2.0, the SFTP variables in bricolage.conf changed. Initially, I didn't notice it, but in debugging my SSH issues (which you can see on the user list), I found that I needed to replace the old config variables with the new. All the other files had all updated properly.

Did you not submit that patch yourself. ;-)

> It got me wondering if this is an issue other users might run into when upgrading. It seems like 99% of the time, not touching the config file during an upgrade is the proper thing to happen. Given, though, that we keep dumping switches into the config file, I wonder if that's really how it should go. I say this not having done an upgrade from 1.10 to 2 for a *long* time, so I don't know how that gets handled.
>
> If this is something only bleeding edge developers like myself (haha) run into, then I'm willing to accept some pain. But my worry is that something similar will happen for normal upgrades, in which case we might want to do change how it's being done.

Probably not that unusual. I think that this is the first time that bricolage.conf directives were *changed*, rather than added or removed. So it may or may not come up again.

The way I do major upgrades, FWIW, is to always diff bricolage.conf to bricolage.conf.def. The latter is put in place with the latest version of the file, so I can see anything that needs to be changed in my configuration. Given how rarely such upgrades are, I find this a reasonable trade-off. Maybe it should be better documented.

If you disagree as to the tradeoff, I guess you'd have to come up with some way to automate updating a bricolage.conf file. Maybe add something to the upgrade scripts?

Best,

David

On Jun 04, 2010, at 04:13 PM, "David E. Wheeler" <david@kineticode.com> wrote:

> Did you not submit that patch yourself. ;-)

Actually, no. I ignored the fact that the bug had been assigned to me until Greg patched it. Now I just complain on the user list and file bug reports. I'm going for the highest ratio of mailing list posts/bug reports to actual code committed of anyone on the devel list. (I'd smiley face if it wasn't so true).

> Probably not that unusual. I think that this is the first time that bricolage.conf directives were *changed*, rather than added or removed. So it may or may not come up again.

Hm, that is interesting. The httpd.confs are different if you're running Apache 2, but since they're generated at install time, that's not going to present the same issue.

> The way I do major upgrades, FWIW, is to always diff bricolage.conf to bricolage.conf.def. The latter is put in place with the latest version of the file, so I can see anything that needs to be changed in my configuration. Given how rarely such upgrades are, I find this a reasonable trade-off. Maybe it should be better documented.
>
> If you disagree as to the tradeoff, I guess you'd have to come up with some way to automate updating a bricolage.conf file. Maybe add something to the upgrade scripts?


I don't think the tradeoff is that unreasonable, but I do agree that we should better document the procedure. An upgrade script could work, but I assume the reason we don't do it now is that people heavily customize the conf file, and it would be a pain to make sure it didn't slaughter what people put into the conf file.

Perhaps the release announcements/upgrade documentation could include bricolage.conf changes or point people where to find it where appropriate. I realize that this is done to some extent in Changes.pod, but in the instances where it's needed maybe it could be made more explicit.

-Matt

On Jun 4, 2010, at 9:27 PM, mattrolf wrote:

> Actually, no. I ignored the fact that the bug had been assigned to me until Greg patched it. Now I just complain on the user list and file bug reports. I'm going for the highest ratio of mailing list posts/bug reports to actual code committed of anyone on the devel list. (I'd smiley face if it wasn't so true).

I'm happy for the participation.

>> Probably not that unusual. I think that this is the first time that bricolage.conf directives were *changed*, rather than added or removed. So it may or may not come up again.
>
> Hm, that is interesting. The httpd.confs are different if you're running Apache 2, but since they're generated at install time, that's not going to present the same issue.

Yes, that's true, I guess. When I've switched installs from Apache 1 to Apache 2, I've upgraded to 2.0 on Apache 1, then installed Apache 2 and tweaked the configuration manually. Wasn't too bad.

> I don't think the tradeoff is that unreasonable, but I do agree that we should better document the procedure. An upgrade script could work, but I assume the reason we don't do it now is that people heavily customize the conf file, and it would be a pain to make sure it didn't slaughter what people put into the conf file.

Right.

> Perhaps the release announcements/upgrade documentation could include bricolage.conf changes or point people where to find it where appropriate. I realize that this is done to some extent in Changes.pod, but in the instances where it's needed maybe it could be made more explicit.

Yes. Perhaps a wiki page? Linked to from the docs and Bric::Admin?

David