[Freeipa-devel] IPA Server upgrade 4.2 design

[Martin Basti]

On 03/03/15 16:10, Martin Kosek wrote:
> On 03/03/2015 04:04 PM, Rob Crittenden wrote:
>> Martin Basti wrote:
>>> On 03/03/15 15:33, Martin Kosek wrote:
>>>> On 03/03/2015 03:16 PM, Simo Sorce wrote:
>>>>> On Mon, 2015-03-02 at 18:54 +0100, Martin Basti wrote:
>>>>>> On 02/03/15 18:28, Martin Kosek wrote:
>>>>>>> On 03/02/2015 06:12 PM, Martin Basti wrote:
>>>>>>>> On 02/03/15 15:43, Rob Crittenden wrote:
>>>>>>>>> Martin Basti wrote:
>>>>>>> ...
>>>>>>>>> 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.
>>>>>>>> I don't know cases when LDAPI would failed, except the case LDAPI is
>>>>>>>> misconfigured by user, or disabled by user.
>>>>>>> Wasn't LDAPI needed for the DM password less upgrade so that
>>>>>>> upgrader could
>>>>>>> simply bind as root with EXTERNAL auth?
>>>>>> We can do upgrade in both way, using LDAPI or using DM password,
>>>>>> preferred is LDAPI.
>>>>>> Question is, what is the use case for using DM password instead of
>>>>>> LDAPI
>>>>>> during upgrade.
>>>>> There is no use case for using the DM password.
>>>> +1, so we will only use LDAPI and ditch DM password options and
>>>> querying that
>>>> we now have with ipa-ldap-updater?
>>>>
>>>>>>>> It is not big effort to keep both DM binding and LDAPI in code.  A
>>>>>>>> user can
>>>>>>>> always found som unexpected use case for LDAP update with DM
>>>>>>>> password.
>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>> So lets summarize this:
>>>>>>>> * DO upgrade if possible during RPM transaction
>>>>>>> Umm, I thought we want to get rid of running upgrade during RPM
>>>>>>> transaction. It
>>>>>>> is extremely difficult to debug upgrade stuck during RPM
>>>>>>> transaction, it also
>>>>>>> makes RPM upgrade run longer than needed. It also makes admins
>>>>>>> nervous when
>>>>>>> their rpm upgrade is suddenly waiting right before the end. I even
>>>>>>> see the
>>>>>>> fingers slowly reaching to CTRL+C combo... (You can see the
>>>>>>> consequences)
>>>>>> People are used to have IPA upgraded and ready after RPM upgrade.
>>>>>> They may be shocked if IPA services will be in shutdown state after RPM
>>>>>> transaction.
>>>>> This is true, stopping IPA and requiring manual intervention is not ok.
>>>> What is the plan then? Keep upgrades done during RPM transaction? Note
>>>> that RPM
>>>> transaction was already stuck several times because IPA, or rather DS,
>>>> deadlocked.
>>>>
>>>> We also need to address https://fedorahosted.org/freeipa/ticket/3849. The
>>>> original plan was to do the upgrade during ipactl start, this would
>>>> fix this
>>>> ticket. Alternatively, should we remove the upgrade from RPM scriptlet
>>>> and only
>>>> call asynchronous "systemctl restart ipa.service" that would trigger the
>>>> upgrade in separate process and log results in ipa.service?
>>>>
>>>> Martin
>>> The plan is do upgrade during RPM transaction if possible. If not then
>>> ipactl start, will show warning for user to do manual upgrade (Rob
>>> wanted it in this way, not doing auto upgrade by ipactl)
>> Only if there is a tty which means no asking during package update,
>> which I thought was the idea. I just think it is rather unexpected to
>> update a package during a restart.
>>
>>> So the fedup case is: RPM upgrade failed, ipactl start will detect
>>> version mismatch, show error and prompt user to run ipa-server-upgrade
>> I'm beginning to have my own doubts about version, recognizing that
>> there isn't exactly another obvious solution. Running the updates every
>> time ipactl is run isn't great. The updates are not fast by any stretch,
>> 29s on one VM, and we need to log whenever an update is done. My
>> ipaupgrade log is 48M from 20 updates. How many times does one run
>> ipactl restart when diagnosing a problem?
>>
>> My biggest concern with version is who keeps count and where? This is
>> particularly problematic in packaged servers where changes are made
>> without rebasing (Fedora and RHEL). Somewhere the version would need to
>> be bumped with each release? Or only when updates are added? Or only
>> when someone remembers? It just seems fragile and prone to human error
>> unless you have some automatic version incrementor that takes this into
>> consideration.
>>
>> If fallible version or slow updates are the only option then I'd have to
>> go with slow updates if only to avoid a lot of support issues. And I
>> really hate the idea of updates during service restart.
>>
>> rob
> Storing the version is something we just have to do, we need it for missing
> upgrade detection in FedUp case. We also need for container use case, to make
> sure that we can check whether we have the right version of bits (container
> image) and data (mounted volume in a container) - to avoid running woth old
> bits (and support issues).
>
> I see the version generated during RPM/DEB build, maybe even the version we
> already fill to VENDOR_VERSION? Then no manual version bump is needed when a
> new downstream patch is added.
Yes I plan to use VENDOR_VERSION.
Martin^2
>
> Martin


-- 
Martin Basti