For those of you not on IRC... the new certmaster will have some
different file paths (all the docs will be updated), though we're
planning a way to migrate all of the existing configs. When the new
release comes out, if folks upgrade certmaster/func at around the same
time, things should not require any changes to keep things working, even
with the path changes. Comments welcome. I'm not sure how widely we
are deployed though we certaintly want to not break folks on upgrade
when we can help it...
(And of course everyone really should join #func on freenode too...)
<alikins> with the func/certmaster split, we've move some config files
and paths around
<alikins> we were thinking about the easiest update path might be a
script thats installed that mv's the config files, and certs. the script
could be ran manually or from the rpm post
<mpdehaan> so like /usr/bin/func-upgrade that you'd run on both ends?
<alikins> yeah, something like that
<mpdehaan> how does it check the version?
<mpdehaan> or the span in versions, per se
<mpdehaan> I know we can detect this variance
<mpdehaan> because certmaster would be installed
<mpdehaan> maybe we do it based on what's there in terms of /things/,
not what version is there.
<alikins> i think for this change, we dont need to check versions. we
can look to see if the stuff is in the old place but not the new place,
if so, mv/cp it
<alikins> otherwise, bail
<mpdehaan> that's probably better as we have no idea if they are
upgrading from ANCIENT to NEW or just SORTA-OLD to NEW
<mpdehaan> so does func try to call this automagically?
<mpdehaan> like the init scripts and stuff?
<mpdehaan> that would unbreak people after they restarted svcs
<alikins> not sure
<alikins> leaning more towards package install time (will hit most cases)
<alikins> other apps have done that kind of thing at init script time as
well though
<mpdehaan> that would be better, yeah
<mpdehaan> %post
<mpdehaan> otherwise you get somebody who restarts 1/2 the system and it
doesn't work
<mpdehaan> however in either case you must update both sides to match I
/think/
<mpdehaan> maybe not
<mpdehaan> anyhow, that failure scenario can be unsupported :)
<alikins> you'd just do it in the func post
<alikins> since it requires certmaster, it will get installed, then
func, then the migrations
<alikins> though certmaster might get started with bogus configs that way
<mpdehaan> the upgrade would take care of that, though, right?
<mpdehaan> what do you mean by bogus configs?
<alikins> certmaster would get restarted when it's package gets
installed, then func would get installed, then upgrade scripts ran
<alikins> I think in theory you could work around that with rpm
%triggers, but *shudder*
<mpdehaan> seems like there isn't a config issue then
<mpdehaan> even in %post
<alikins> but then, we dont actually restart there, so not really an issue
<mpdehaan> we could perhaps upgrade files and then conditionally restart
<mpdehaan> rpms aren't supposed to enable services that aren't running
and all, so that may be ok
<mpdehaan> anything else that might be missing from this? Probably
should share this with the list...
<mpdehaan> ok, I'll post :)
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
