Tuesday, August 18, 2020

Getting started with Ansible

I wanted to get an summary of the values of different mailman parameters used on our different servers. We are now running five servers of our own, plus those of our self-hosting customers. Seems that it is time to start using a Configuration Management tool. But which one?

After some poking around I discovered Ansible.

Surf history:

At this point I was convinced that this is first tool we are going to dive into.

Installation was trivial:

$ pip install ansible

Miscellaneous

  • Fixed a deprecation warning lino/core/signals.py:112: RemovedInDjango40Warning: The providing_args argument is deprecated. As it is purely documentational, it has no replacement. If you rely on this argument as documentation, you can move the text to a code comment or docstring.

  • Lino was saying (e.g.) “This is Lino …, Appy (not installed).” despite the fact that appy was installed. Didn’t investigate how to know the version in appy-py3 so atm it just says “unknown”.

  • Our The Lino framework server had again very slow response times. At least between 16:45 and 17:05 EEST. Even ssh didn’t work:

    Connection closed by 167.114.229.225 port 22

Exclude some plugins from SiteSearch

I had a funny doctest failure:

File "docs/specs/search.rst", line 38, in search.rst
Failed example:
    rt.show('about.SiteSearch', quick_search="foo")
Expected:
    No data to display
Got:
    ============================================== =========================================================================================================================================================================================================================================================
     Description                                    Matches
    ---------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
     *e9sb44ffop0im20ihv9rmx41666rca4o* (session)   session_data:.eJxVjDsOwjAQBe_iGlnr9Sc2JUeIRG1t7LUcAYkUJxXi7iRSCmjfzLy3iLStNW6NlzhmcRVKXH63gdKDpwM8x2mWaV5YHlSeoMmeX_PK912-ne7fQaVW9xrAKkeFlQ9dKkjFO0sDo9FoLCYKENBqxA44O6cYrHaQTYAcrPPGi88Xx2A2kw:1k7vq3:cvTCJlm-gn**fOo**mHdSLTZX7Z7lkJvKQmps5SMZGNayHw
    ============================================== =========================================================================================================================================================================================================================================================
    <BLANKLINE>

I added a new class attribute SiteSearch.private_apps which at the moment is simply hard coded as follows:

private_apps = frozenset(['sessions', 'contenttypes', 'users'])

Extracting help texts and Multi-Table Inheritance

I slightly changed behaviour around help texts and updated the relevant documentation page Help texts.

What happens when your Sphinx docs define help texts for both Partner.name and Person.name? Help texts are stored on the field descriptor object, and in case of MTI children it was possible that the help text of a child field overwrites that of the parent field. For example the name field is defined in the Partner model, but if we write also a prosa description for that field on the Person model, the help_text for name on the partner became that of the person. That was wrong. Seems that this wrong behaviour became visible only now because lino.sphinxcontrib.help_texts_extractor was inactive for some time.

The guilty was lino.core.fields.VirtualField.lino_resolve_type(), which is called after having set the help texts of the field. It unconditionally overwrote the help_text of virtual FK fields by the help_text of the FK they were using. I used the following code when exploring the problem. This is now also in Clients in Lino Avanti.

>>> import lino
>>> lino.startup('lino_book.projects.avanti1.settings')
>>> from lino.api.doctest import *
>>> 'municipality' in [f.name for f in avanti.Client._meta.get_fields()]
True

Compare (a) the specs (i.e. the target of the links) and (b) the help texts of the following fields:

>>> print(avanti.Client._meta.get_field('municipality').help_text)
The municipality where this client lives. This is basically
equal to city, except when city is a village
and has a parent which is a municipality (which causes that
place to be returned).

>>> print(contacts.Person._meta.get_field('municipality').help_text)
The municipality, i.e. either the city or a parent of it.

>>> print(contacts.Person._meta.get_field('city').help_text)
The locality, i.e. usually a village, city or town.

>>> print(contacts.Person._meta.get_field('city').help_text)
The locality, i.e. usually a village, city or town.

Zulip instead of Mailman?

Mari convinced me that it’s utopic to hope that volunteer members of laudate.ee will start to use mailing lists for collaborating.

She suggests to open a workspace on Slack. I was ready to stop my reluctance to use a proprietary platform.

But before creating a workspace on Slack, I read this

And I remembered that we almost started to use Zulip instead of Noi some time ago: #2878 (Install a Zulip instance on SR).

I reopened that ticket and started to read https://zulip.readthedocs.io/en/stable/production/install.html

But the easier solution is to just open a free project on the zulipchat.com server. Voilà, here it is: https://eestitaizes6brad.zulipchat.com/#

When we approach the 10,000 messages limit, we will need to decide: contribute or forget?

First problem : Zulip doesn’t offer Estonian language. Hm. We will see whether this is a show stopper.