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-mir...) 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.
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 - 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:
[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.
[Neil] Aarch64 gitlab-runners
a. Initial config available, needs optimisation, especially concurrency per machine vs cores per runner
- optimisation to be done during 2019.03 cycle.
b. [Steve] Mustang machine not booting - investigating
- could be an issue with upgrade to buster.
[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
[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-mir...) 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?
- not urgent to migrate to buster now.
[Steve] location for documentation a. Needs an issue to track this.
- avoid the rabbit hole of optimising what is left.
b. certain elements need to go into the website from lava-server-doc
- Release docs
- Development process
- Design overview
- 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.
- there will be some conversion needed for items which are currently in Google Docs.
f. move design meeting doc to the wiki?
- no - interactive shared-editing feature is very useful
- we can simply copy text to the wiki after the fact
- Page per meeting in the wiki with index links
- 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.
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/
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:
[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.
[Neil] Aarch64 gitlab-runners
a. Initial config available, needs optimisation, especially concurrency per machine vs cores per runner
- optimisation to be done during 2019.03 cycle.
b. [Steve] Mustang machine not booting - investigating
- could be an issue with upgrade to buster.
[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
[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-mir...) 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?
- not urgent to migrate to buster now.
[Steve] location for documentation a. Needs an issue to track this.
- avoid the rabbit hole of optimising what is left.
b. certain elements need to go into the website from lava-server-doc
- Release docs
- Development process
- Design overview
- 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.
- there will be some conversion needed for items which are currently in Google Docs.
f. move design meeting doc to the wiki?
- no - interactive shared-editing feature is very useful
- we can simply copy text to the wiki after the fact
- Page per meeting in the wiki with index links
- 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
- [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?
- 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.
- 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
On Thu, 21 Feb 2019 at 17:21, Dan Rue dan.rue@linaro.org wrote:
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:
[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.
[Neil] Aarch64 gitlab-runners
a. Initial config available, needs optimisation, especially concurrency per machine vs cores per runner
- optimisation to be done during 2019.03 cycle.
b. [Steve] Mustang machine not booting - investigating
- could be an issue with upgrade to buster.
[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.
[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
[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-mir...) 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?
- not urgent to migrate to buster now.
[Steve] location for documentation a. Needs an issue to track this.
- avoid the rabbit hole of optimising what is left.
b. certain elements need to go into the website from lava-server-doc
- Release docs
- Development process
- Design overview
- 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.
- there will be some conversion needed for items which are currently in Google Docs.
f. move design meeting doc to the wiki?
- no - interactive shared-editing feature is very useful
- we can simply copy text to the wiki after the fact
- Page per meeting in the wiki with index links
- 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.
You could simply use the Google Search support to restrict to specific sites.
The recommended site would be master.lavasoftware.org which is updated nightly, alternatively staging.validation.linaro.org.
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.
robots.txt is already in use. Various bots ignore it. (We are building a list of DISALLOWED_USER_AGENTS for bots which ignore robots.txt as these bots also tend to cause high load by searching recursively based on the query strings).
However, we should not ban indexing of docs for other instances - there are various issues with accessing Google from firewalls etc.
- 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.
That location would be master.lavasoftware.org
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
That setting could be exposed but there's nothing to say that other instances won't enable it for themselves.
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/
This would not allow any indexing for any site anywhere. It needs to be configurable - which still allows other instances to choose to enable that setting.
-- 2.20.1
- [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?
- 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.
- 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
Hello Dan,
I created an issue to track the use of the canonicalization in the lava documentation. This will point back at https://docs.lavasoftware.org/lava/
The issue is: https://git.lavasoftware.org/lava/lava/issues/248
Cheers
Le jeu. 21 févr. 2019 à 18:21, Dan Rue dan.rue@linaro.org a écrit :
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:
- [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 problemb. 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.
[Neil] Aarch64 gitlab-runners
a. Initial config available, needs optimisation, especially concurrency per machine vs cores per runner
- optimisation to be done during 2019.03 cycle.
b. [Steve] Mustang machine not booting - investigating
- could be an issue with upgrade to buster.
[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.
[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
[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-mir... )
but examples of this given in 1.5 docs (oldest I've found) don't appear to work in 1.3d. I believe 1.7 is in Buster, so is it a case of moving to buster? 1. not urgent to migrate to buster now.
- [Steve] location for documentation a. Needs an issue to track this.
b. certain elements need to go into the website from lava-server-doc
- avoid the rabbit hole of optimising what is left.
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.
- Release docs
- Development process
- Design overview
- Keep development-intro and update links.
- 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
- [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 animage
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 standardimage 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
lava-devel@lists.lavasoftware.org
-
Dan Rue -
Neil Williams -
Remi Duraffort -
Steve McIntyre