[Freeipa-devel] IPA Server upgrade 4.2 design

[Rob Crittenden]

Martin Basti wrote:
> On 27/02/15 20:45, Rob Crittenden wrote:
>> Martin Basti wrote:
>>> On 26/02/15 10:45, Petr Spacek wrote:
>>>> On 25.2.2015 17:49, Martin Basti wrote:
>>>>> On 25/02/15 17:15, Petr Spacek wrote:
>>>>>> On 24.2.2015 19:10, Martin Basti wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> please read the design page, any objections/suggestions appreciated
>>>>>>> http://www.freeipa.org/page/V4/Server_Upgrade_Refactoring
>>>>>> Thank you for the design, I have only few nitpicks.
>>>>>>
>>>>>>> Increase update files numbers range
>>>>>>> Update files number will be extended into 4 digits values.
>>>>>> IMHO the dependency on particular number format should be removed
>>>>>> altogether.
>>>>>> It should be perfectly enough to say that updates are executed in
>>>>>> ASCII
>>>>>> lexicographic order and be done with it.
>>>>> 4.1.3-2 > 4.1.3-12 in lexicographic order, this will not fit.
>>>> Well, sure, but it allows you to use
>>>> 00-a
>>>> 01-b
>>>>
>>>> and renumber it to
>>>>
>>>> 001-a
>>>> 002-b
>>>>
>>>> at will without changes to code. (Lexicographic order is what 'ls'
>>>> uses by
>>>> default so you can see the real ordering at any time very easily.)
>>>>
>>>> Also, as you pointed out, it allows you to do things like
>>>> 12.345-a
>>>> 12.666-bbb
>>>> without changing code, again :-)
>>> Oh stupid me, I read it wrong, I replied with IPA version compare.
>>>
>>> sounds good to me, any objections anyone?
>> This makes sense as long as we don't abuse it. The numbers are there to
>> apply some amount of order but flexibility is good, and will avoid the
>> problem of having humongous update files.
> So it is not clear to me,  should we use 4 digit numbers, or just
> lexicographic order?

Use lexicographic order with number prefixes so things "look" the way
the always have but it will be more flexible going forward. I don't know
that IPA will ever actually run out of enough number prefixes for this
to be a serious problem but plan for the worst I guess.

I'd just update the current README that recommends certain levels with
information on the new sorting. The order within a given numeric
subgroup is only important in a minority of cases.


> 
>> I'm fine with allowing DM given that it allows running as non-root
>> (pretty much the only condition that ldapi wouldn't work), but I think a
>> full upgrade will fail w/o root given that you are combining the two
>> commands.
> I'm not sure, if I get it.
> 
> The ipa-server-upgrade has to be run under root user (ldapi, service
> upgrades).
> If LDAPI failed, user may use DM password to do LDAP update (this should
> fix LDAPI settings) but root user is still required to update services.
> So root user is always required to do this.

But you haven't explained any case why LDAPI would fail. If LDAPI fails
then you've got more serious problems that I'm not sure binding as DM is
going to solve.

The only case where DM would be handy IMHO is either some worst case
scenario upgrade where 389-ds is up but not binding to LDAPI or if you
want to allow running LDAP updates as non-root.

>>
>> On ipactl, would it be overkill if there is a tty to prompt the user to
>> upgrade? In a non-container world it might be surprising to have an
>> upgrade happen esp since upgrades take a while.
> In non-container enviroment, we can still use upgrade during RPM
> transaction.
> 
> So you suggest  not to do update automaticaly, just write Error the IPA
> upgrade is required?

People do all sorts of strange things. Installing the packages with
--no-script isn't in the range of impossible. A prompt, and I'm not
saying it's a great idea, is 2 lines of code.

I guess it just makes me nervous.

>>
>> With --skip-version-check what sorts of problems can we foresee? I
>> assume a big warning will be added to at least the man page, if not
>> the cli?
> For this big warning everywhere.
> The main problem is try to run older IPA with newer data. In containers
> the problem is to run different platform specific versions which differ
> in functionality/bugfixes etc..

Ok, pretty much the things I was thinking as well. A scary warning
definitely seems warranted.

>>
>> Where does platform come from? I'm wondering how Debian will handle this.
> platform is derived from ipaplatform file which is used with the
> particular build. Debian should have own platform file.

Ok, I'd add that detail to the design.

rob