On Thu, Feb 21, 2019 at 11:16:44AM -0600, Dan Rue wrote:
> Steve - thank you for these really great minutes. I have one comment
> below.
>
> On Thu, Feb 21, 2019 at 04:44:28PM +0000, Steve McIntyre wrote:
> > Hi folks,
> >
> > We held our regular weekly design meeting yesterday via
> > Hangout. Summary of discussion:
> >
> > 1. [Neil] Job action timeouts
> > a. Downgrade current change to not reject XMLRPC API job submission [Rémi]
> > 1. lots of jobs on LKFT need changes, likely to be indicative
> > of a wider problem
> > b. Implement the XMLRPC check and get lava-schema.py out to
> > people in 2019.02 [Rémi]
> > c. Announce the new schema
> > d. Leave fatal exceptions until a future release
> > e. Confirmed. the schema validation itself is not yet part of lava_scheduler_app submit.
> >
> > 2. [Neil] Aarch64 gitlab-runners
> >
> > a. Initial config available, needs optimisation, especially
> > concurrency per machine vs cores per runner
> > 1. optimisation to be done during 2019.03 cycle.
> > b. [Steve] Mustang machine not booting - investigating
> > 1. could be an issue with upgrade to buster.
> >
> > 3. [Neil] wisdom of running unit tests inside docker builds in the
> > ci-images project?
> > a. guarantees that the new image won't break lava.git master.
> > b. another item to be added to the docs of how our CI
> > operates. [Neil] needs an issue.
> >
> > 4. [Neil] Remi to authenticate the GnuPG fingerprint for
> > 4E9995EC67B6560E0A9B97A9597DCC10C0D1B33D to enable lavasoftware.org
> > ansible password_store
> > a. Now fixed via keys.gnupg.net and pgp.earth.li
> >
> > 5. [Dean] Feasibility of upgrading django-ldap-auth to version 1.7?
> > a. https://tracker.debian.org/pkg/django-auth-ldap
> > b. To sync LDAP groups into Django auth.
> > c. We want to be able to mirror LDAP groups as groups in LAVA
> > (details of this:
> > https://django-auth-ldap.readthedocs.io/en/latest/permissions.html#group-mirroring)
> > but examples of this given in 1.5 docs (oldest I've found) don't
> > appear to work in 1.3
> > d. I believe 1.7 is in Buster, so is it a case of moving to buster?
> > 1. not urgent to migrate to buster now.
> >
> > 6. [Steve] location for documentation
> > a. Needs an issue to track this.
> > 1. avoid the rabbit hole of optimising what is left.
> > b. certain elements need to go into the website from lava-server-doc
> > 1. Release docs
> > 2. Development process
> > 3. Design overview
> > 4. Keep development-intro and update links.
> > c. update all the links in lava-server-doc.
> > d. website will move to Sphinx instead of Pelican.
> > e. a lot of docs are using Sphinx RST.
> > 1. there will be some conversion needed for items which are currently in Google Docs.
> > f. move design meeting doc to the wiki?
> > 1. no - interactive shared-editing feature is very useful
> > 2. we can simply copy text to the wiki after the fact
> > 3. Page per meeting in the wiki with index links
> > 4. Consider the new document as public by the end of the meeting.
>
> Regarding documentation, currently I think LAVA suffers from an SEO
> problem. I'll explain. When google-ing a LAVA question (as I've done
> about 10,000 times), links are served from a somewhat random set of lava
> installations that are public on the internet.
>
> For example, I just now googled something I randomly thought of "lava
> how to configure uboot" and the top 3 links are to:
> - https://validation.linaro.org/static/docs/v2/integrate-uboot.html
> - https://staging.validation.linaro.org/static/docs/v2/genindex.html
> - https://lava.coreboot.org/static/docs/v2/actions-boot.html
>
> Each of these is running a different version of lava. coreboot's is on
> 2018.5.post1. This is a typical experience. At least validation.l.o is
> first, and that's often the case, but it's still wrong, as v.l.o is
> still just an installation of lava. Given my current role, I'm able to
> navigate this, but it's not something I would expect people outside the
> project to figure out.
>
> For users, this is a confusing state, and I think for the project it
> makes it hard to effectively provide high quality documentation and
> answers (LAVA project fixes documentation but users end up reading old
> documentation).
>
> My suggestions:
> - Immediately stop the bleeding; add a robots.txt rule to lava so that
> google stops indexing random LAVA installations' included
> documentation.
> - Once a more canonical and permanent documentation location exists
> (which is what I think this topic is about), link to it from all
> installations by default, to increase its SEO score.
>
> Maybe there needs to be an additional step there, and maybe there are
> more sophisticated ways to relay to the web crawlers where canonical
> resources live. In any case, I think the above steps are a good starting
> suggestion.
Maybe this is the answer instead?
https://moz.com/learn/seo/canonicalization
>
> Dan
>
> From e92f1430d625945ad4cc6ae4aef03e46704253fb Mon Sep 17 00:00:00 2001
> From: Dan Rue <dan.rue@linaro.org>
> Date: Thu, 21 Feb 2019 11:13:30 -0600
> Subject: [PATCH] Disallow indexing of LAVA documentation
>
> Signed-off-by: Dan Rue <dan.rue@linaro.org>
> ---
> lava_server/templates/robots.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lava_server/templates/robots.txt b/lava_server/templates/robots.txt
> index 1c9b80f08..0e74749ce 100644
> --- a/lava_server/templates/robots.txt
> +++ b/lava_server/templates/robots.txt
> @@ -2,3 +2,4 @@ User-agent: *
> Disallow: /scheduler/
> Disallow: /results/
> Disallow: /api/
> +Disallow: /static/docs/
> --
> 2.20.1
>
>
> >
> > 7. [Remi] MuxPi rPi zero. build raw images.
> > a. Guestfish based on GuestFS
> > b. inside docker? need /boot and /lib/modules volumes. Easy scriptable
> > way to do things.
> > c. Should we publish our images and a way to rebuild them?
> > 1. Let's not do this as an automated public build
> > a. Neil to close https://git.lavasoftware.org/lava/functional-tests/issues/7 (Use
> > GitLab CI to auto-build functional test image files for
> > files.lavasoftware.org) on the basis that we are not an image
> > building service.
> > 2. Must document how our images are built
> > a. files.lavasoftware.org already includes copies of the
> > scripts which were used to create the Debian standard image files.
> >
> >
> > The LAVA design meeting is held weekly, every Wednesday at 13:00 to
> > 14:00 UTC using Google Hangouts Meet: https://meet.google.com/qre-rgen-zwc
> > Feel free to comment here or join us directly in the meeting.
> >
> > Cheers,
> > --
> > Steve McIntyre steve.mcintyre@linaro.org
> > <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
> >
> >
> > _______________________________________________
> > Lava-devel mailing list
> > Lava-devel@lists.lavasoftware.org
> > https://lists.lavasoftware.org/mailman/listinfo/lava-devel
>
> --
> Linaro - Kernel Validation
--
Linaro - Kernel Validation
_______________________________________________
Lava-devel mailing list
Lava-devel@lists.lavasoftware.org
https://lists.lavasoftware.org/mailman/listinfo/lava-devel