Date   

Update 2017wk14

Agustin Benito Bethencourt <agustin.benito@...>
 

Dear CIP friends,

here is the report of those tasks related with Testing and kernel maintenance that Don, Ben, Robert, Lachlan and myself has been working on the past two weeks (12 and 13):

++ Board At Desk - Single Dev

The B.A.D.-S.D. team were facing the last few tasks before the release when upstream updated kernelci. Some of the changes impacted us. I decided to include the updates in this coming release despite having past Beta milestone in order to match upstream, which will delay our release, scheduled for mid April. In any case, we expect to be testing the kernel on regular basis by the time we reach Open Source Summit Japan. That has not changed.

This is always a challenging situation for any downstream project, when you get an important update from upstream in the middle of the release process, as we currently are.

The reason I took this decision is that we, as CIP project, will heavily depend on upstream to provide support on LAVA and KernelCI to our consumers, due to the complexity of the tooling. We will not be able to become the default support channel. It is far from being our goal either. I believe it is better for CIP to participate in the existing support channel upstream has.

Being up to date with them is the only reasonable way to get that support for our future users. Since there is no release from our side yet, doing this right will help us in our credibility as project from the very beginning.

After taken the decision, the following question is, what will we do if this situation happens again in the future? And it will.

It would be very unfortunate if this happens again before our release, based on our conversations with upstream. In any case, we will provide an stable VM, now that have a "download service", as soon as the issues related with the recent update are fixed (we are currently fixing what we believe it is the last one, #65).

In general, the VM images will work as stable releases while the "development VM" will be provided through Vagrant. This way those interested in the development of the tooling itself will be able to get the latest commits as they are merged, while those only interested in using Board At Desk - Single Dev as consumers will always have an "stable image" working, independently of what upstream or our team does.

We will inform through this mailing list as soon as the VM gets to the state prior to the upstream update. We will re-focus then on the release.

I apologise for the inconveniences. I understand some of you are looking forward to use the VM to test the CIP kernel. It was a tough decision to make, with a high impact in the short term, but a higher risk for the project in the mid term, in my modest opinion.

Issues closed:
* #49 USB passthrough config needs correcting
* #60 Kernel build failure
* #61 Error on running install_frontend.sh
* #57 Missing error checks in provisioning scripts
* #55 fix behaviour of vm with ifup failures
* #64 The KernelCI Backend fails on missing Ansible variable error_email
* #63 the kernelci webserver will no longer display builds that have been performed. This is fact is the same issue that #65

Other issues
* #58 ser2net integration script may generate incorrect configuration was reopened.

++ Kernel maintenance

Main tasks:
* Kernel security tracker: Ben H. wrote a template and implemented importers
* Kernel feature support: Ben H. collected and began reviewing members' configurations
* Ben Hutchings participated in the last TSC bi-weekly call. He answered questions at members' phone meeting. Please check the minutes for further details: https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr032017
* Ben H. reviewed changes for Linux 4.4.60

Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Re: Update 2017wk14

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

On 10/04/17 11:28, Agustin Benito Bethencourt wrote:
Dear CIP friends,

here is the report of those tasks related with Testing and kernel
maintenance that Don, Ben, Robert, Lachlan and myself has been working
on the past two weeks (12 and 13):

++ Board At Desk - Single Dev

The B.A.D.-S.D. team were facing the last few tasks before the release
when upstream updated kernelci. Some of the changes impacted us. I
decided to include the updates in this coming release despite having
past Beta milestone in order to match upstream, which will delay our
release, scheduled for mid April. In any case, we expect to be testing
the kernel on regular basis by the time we reach Open Source Summit
Japan. That has not changed.

This is always a challenging situation for any downstream project, when
you get an important update from upstream in the middle of the release
process, as we currently are.

The reason I took this decision is that we, as CIP project, will heavily
depend on upstream to provide support on LAVA and KernelCI to our
consumers, due to the complexity of the tooling. We will not be able to
become the default support channel. It is far from being our goal
either. I believe it is better for CIP to participate in the existing
support channel upstream has.

Being up to date with them is the only reasonable way to get that
support for our future users. Since there is no release from our side
yet, doing this right will help us in our credibility as project from
the very beginning.

After taken the decision, the following question is, what will we do if
this situation happens again in the future? And it will.

It would be very unfortunate if this happens again before our release,
based on our conversations with upstream. In any case, we will provide
an stable VM, now that have a "download service", as soon as the issues
related with the recent update are fixed (we are currently fixing what
we believe it is the last one, #65).

In general, the VM images will work as stable releases while the
"development VM" will be provided through Vagrant. This way those
interested in the development of the tooling itself will be able to get
the latest commits as they are merged, while those only interested in
using Board At Desk - Single Dev as consumers will always have an
"stable image" working, independently of what upstream or our team does.

We will inform through this mailing list as soon as the VM gets to the
state prior to the upstream update. We will re-focus then on the release.

I apologise for the inconveniences. I understand some of you are looking
forward to use the VM to test the CIP kernel. It was a tough decision to
make, with a high impact in the short term, but a higher risk for the
project in the mid term, in my modest opinion.

Issues closed:
* #49 USB passthrough config needs correcting
* #60 Kernel build failure
* #61 Error on running install_frontend.sh
* #57 Missing error checks in provisioning scripts
* #55 fix behaviour of vm with ifup failures
* #64 The KernelCI Backend fails on missing Ansible variable error_email
* #63 the kernelci webserver will no longer display builds that have
been performed. This is fact is the same issue that #65

Other issues
* #58 ser2net integration script may generate incorrect configuration
was reopened.
Link to all the issues: https://gitlab.com/cip-project/testing/boards


++ Kernel maintenance

Main tasks:
* Kernel security tracker: Ben H. wrote a template and implemented
importers
* Kernel feature support: Ben H. collected and began reviewing members'
configurations
* Ben Hutchings participated in the last TSC bi-weekly call. He answered
questions at members' phone meeting. Please check the minutes for
further details:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr032017

* Ben H. reviewed changes for Linux 4.4.60

Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Re: u-boot policy for CIP

Chris Paterson
 

Hello all,

I'd like to reach some conclusion on the discussion/policy about u-boot. We briefly spoke about it in the last TSC, and agreed to continue the discussion here.

As highlighted by Ben and Wolfgang, a policy should be driven by the use-case requirements from the member companies. Until more feedback comes in from the member companies, would it be an idea for me to draft an outline policy we can use to focus discussions? Sometimes it is easier to have a starting point to amend, rather than waffle aimlessly.

On a side note, I won't be able to attend the next TSC (Easter holidays), but please continue the discussion without me.


Kind regards, Chris

From: Ben Hutchings [mailto:ben.hutchings@codethink.co.uk]
Sent: 24 March 2017 17:53

On Thu, 2017-03-16 at 12:07 +0000, Chris Paterson wrote:

I’m bringing a discussion I’ve started in other places here as it will
benefit from wider participation.
Thank you. I have limited knowledge of u-boot, but I did work on it recently
to add support for a new board.

[...]
Ideally CIP should choose a version of u-boot and use it when
testing/verifying the CIP Kernel on the reference hardware.
We should certainly pick one version for each reference board.

How we actively maintain that version (bug fixes/security
patches/features?) is another question. Given that most devices in the
field won’t have a way to update u-boot in the field (security
issues/practicalities), I think ‘SLTS’ support for u-boot may not be
required. Perhaps we just tag a version of u-boot at the launch of a
new CIP Kernel and stick with it?
If u-boot is configured to use network boot, or to require authentication of
its environment or boot images, or authentication to interrupt boot
(CONFIG_AUTOBOOT_KEYED=y), then it is sometimes handling untrusted
input and might need security updates. Otherwise it probably does not.

It seems possible that some fixes might be needed to improve reliability, e.g.
if boot timing changes as hardware gets older.

How do we decide what u-boot version to support? Currently it looks
like the BBB platform are shipped with 2014.04
I have a new BBB that came with 2015.10 installed. So we cannot be certain
that a particular model of board will always be shipped with the same
version!

and the Renesas platform is shipped with 2013.01. That said, it looks
like there is upstream support for BBB [1], but how the feature set
compares to the version shipped with the platform I don’t know. There
is also support for some Renesas platforms [2], but not for the exact
board CIP will be using.

Do we want to push Ti/Renesas to ensure there is full support for
their boards upstream? When this is done do we pick the first version
that includes this support to work with? Or do we just stick with the
vendor provided forks?
I don't have an opinion on whether CIP should provide support for u-boot,
beyond the testing it will get through booting each kernel to be tested. If we
do, I would prefer not to include vendor forks as this could greatly increase
the maintenance effort.

Is there a particular feature set that CIP requires?
[...]

For testing purposes we will need at least an unauthenticated command
prompt (CONFIG_AUTOBOOT_KEYED=n), networking and TFTP support.
That probably isn't a complete list.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: u-boot policy for CIP

Mauerer, Wolfgang
 

Hi Chris,

On 12.04.2017 10:34, Chris Paterson wrote:
Hello all,

I'd like to reach some conclusion on the discussion/policy about
u-boot. We briefly spoke about it in the last TSC, and agreed to
continue the discussion here.

As highlighted by Ben and Wolfgang, a policy should be driven by the
use-case requirements from the member companies. Until more feedback
comes in from the member companies, would it be an idea for me to
draft an outline policy we can use to focus discussions? Sometimes it
is easier to have a starting point to amend, rather than waffle
aimlessly.
that's a good idea, thanks for pushing this forward. Discussions
are usually easier when there's some starting point. I'll try
to get some in-company requirements via our internal channels.

Thanks, Wolfgang

On a side note, I won't be able to attend the next TSC (Easter
holidays), but please continue the discussion without me.


Kind regards, Chris


From: Ben Hutchings [mailto:ben.hutchings@codethink.co.uk] Sent: 24
March 2017 17:53

On Thu, 2017-03-16 at 12:07 +0000, Chris Paterson wrote:

I’m bringing a discussion I’ve started in other places here as it
will benefit from wider participation.
Thank you. I have limited knowledge of u-boot, but I did work on
it recently to add support for a new board.

[...]
Ideally CIP should choose a version of u-boot and use it when
testing/verifying the CIP Kernel on the reference hardware.
We should certainly pick one version for each reference board.

How we actively maintain that version (bug fixes/security
patches/features?) is another question. Given that most devices
in the field won’t have a way to update u-boot in the field
(security issues/practicalities), I think ‘SLTS’ support for
u-boot may not be required. Perhaps we just tag a version of
u-boot at the launch of a new CIP Kernel and stick with it?
If u-boot is configured to use network boot, or to require
authentication of its environment or boot images, or authentication
to interrupt boot (CONFIG_AUTOBOOT_KEYED=y), then it is sometimes
handling untrusted input and might need security updates.
Otherwise it probably does not.

It seems possible that some fixes might be needed to improve
reliability, e.g. if boot timing changes as hardware gets older.

How do we decide what u-boot version to support? Currently it
looks like the BBB platform are shipped with 2014.04
I have a new BBB that came with 2015.10 installed. So we cannot be
certain that a particular model of board will always be shipped
with the same version!

and the Renesas platform is shipped with 2013.01. That said, it
looks like there is upstream support for BBB [1], but how the
feature set compares to the version shipped with the platform I
don’t know. There is also support for some Renesas platforms [2],
but not for the exact board CIP will be using.

Do we want to push Ti/Renesas to ensure there is full support
for their boards upstream? When this is done do we pick the first
version that includes this support to work with? Or do we just
stick with the vendor provided forks?
I don't have an opinion on whether CIP should provide support for
u-boot, beyond the testing it will get through booting each kernel
to be tested. If we do, I would prefer not to include vendor forks
as this could greatly increase the maintenance effort.

Is there a particular feature set that CIP requires?
[...]

For testing purposes we will need at least an unauthenticated
command prompt (CONFIG_AUTOBOOT_KEYED=n), networking and TFTP
support. That probably isn't a complete list.

Ben.

-- Ben Hutchings Software Developer, Codethink Ltd.
_______________________________________________ cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Kernel feature support

Jan Kiszka
 

On 2017-03-09 15:33, Ben Hutchings wrote:
We've previously agreed that not all kernel features (drivers,
filesystems, network protocols, etc.) can be supported in an SLTS
branch. I'd like to start working out what the supported features
should be for the 4.4 branch.

Are members able to share their kernel .config files, showing which
features are enabled? Or would you prefer to specify your needs at a
slightly higher level?
Some more configs from our side. Some are just stripped-down defconfigs,
some are 4.1-based (to become 4.4 eventually), but I hope they are
useful. Any out-of-tree switch is to be ignored, of course.

I hope there will be more configs in the future. E.g., some projects on
4.4 are still running an expanded development feature set.

Thanks,
Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux


Re: Kernel feature support

minmin@plathome.co.jp
 

Dear Ben;

I apologize for the very late submission. Here is the config of our product.

Thanks in advance.

--
Masato Minda <minmin@...>
Plat'Home Co., Ltd.


Test mail from TSDV

Tuan Le Minh <tuan.leminh@...>
 

Test

 

Tuan | IS team


Re: CIP TSC meeting minutes (3 April 2017)

tuyen.hoangvan@...
 

Dear Takuo Koguchi,

Thank you so much for your guide about building kernel for BBB.

I created a patch file to build minimal OS for BBB by using boot-loader
(u-boot) and

kernel (linux-base) based on meta-debian.

I would like to share you the patch at the attachment.

The patch is created for project-x, master branch.

Best regards,

Tuyen

Hi Yoshi,

Regarding to my project-x action item, recipes-kernel for BBB and CycloneV
is already posted.

If you copy recipes-kernel to your usual poky build (i.e. DISTRO = poky
without meta-debian,)
you will be able to bitbake virtual/kernel.

But it you want to use this recipe with meta-debian, there are some
issues.
1) you have to add meta-PROJECTX/conf/local.conf.sample and
bblayer.conf.sample manually.
This is my fault. I forgot to include these files. You can copy these
files from deby-qemux86-64/meta-PROJECTX/conf

If you do the above, you can bitbake virtual/kernel if the followings are
in conf/local.conf
MACHINE="beaglebone"
LINUX_DEFCONFIG="omap2plus_defconfig"

But this is still not what I meant for.
In the above mentioned build my "linux-cip" recipe is not used even if
PREFERRED_PROVIDER_virtual/kernel = "linux-cip"
is defined in local.conf because PREFERRED_PROVIDER _virtual/kernel is
overwritten
by meta-debian/conf\/distro/include/debian-preferred-provider.inc:2
to "linux-base"

I hope you can change
PREFERRED_PROVIDER_virtual/kernel = "linux-base"
for
PREFERRED_PROVIDER_virtual/kernel ?= "linux-base"

Unfortunately there are still some issue to build kernel with meta-debian.
I am working on it.


Best Regard,

Takuo Koguchi

-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org
[mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of KOBAYASHI
Yoshitake
Sent: Thursday, April 06, 2017 2:07 PM
To: cip-dev@lists.cip-project.org
Subject: [!][cip-dev] CIP TSC meeting minutes (3 April 2017)

Hi everyone,

I uploaded the meeting minutes for CIP Technical Steering Committee
meeting held 3
April, 2017 at the following link.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr03201
7

Past TSC meeting minutes can be find at the following link.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings.

Best regards,
Yoshi


_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev

--
This mail was scanned by BitDefender
For more information please visit http://www.bitdefender.com

--
This mail was scanned by BitDefender
For more information please visit http://www.bitdefender.com


telnet connection and bbb testing

Robert Marshall <robert.marshall@...>
 

Don

Our bbb_debian_ramdisk_test2.yaml has a auto_login section defining a
login prompt username and password - was this approach tried and abandoned before
starting to use keeping a telnet session active on the beaglebone-black
tests?

Robert


CIP TSC meeting minutes (17 April 2017)

Yoshitake Kobayashi
 

Hi all,

I have uploaded meeting minutes for yesterday's CIP TSC conference call.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr172017

If you have any comments, please let us know.

Best regards,
Yoshi


Re: CIP TSC meeting minutes (17 April 2017)

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

On 18/04/17 15:42, KOBAYASHI Yoshitake wrote:
Hi all,

I have uploaded meeting minutes for yesterday's CIP TSC conference call.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr172017

If you have any comments, please let us know.
Thank you very much for formatting and publishing the minutes. I see this as a small but relevant improvement towards transparency.

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


CIP workshop on 30th May at the OSSJ venue

Agustin Benito Bethencourt <agustin.benito@...>
 

Dear CIP friends,

as you can read in the meeting minutes of yesterday's TSC meeting[1], the day before the Open Source Summit Japan starts, May 30th, we will organise some specific sessions related with CIP in the same venue.

We are in the process of defining what we will do from 11:00 to 17:00. Feel free to:
* Let us know if you are interested in attending.
* Provide input on the topics you would like to work on, discuss or receive information.

Maybe creating a wiki page to coordinate the activities would be wise, right?

Best Regards


[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr172017

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Re: cip-dev Digest, Vol 11, Issue 8

Don Brown <don.f.brown@...>
 

Hi Robert,

You will notice that there is no login or password.

When I had problems getting the test to properly log in to the BBB, I copied and modified the script into 'bbb_debian_ramdisk_test2.yaml' to include the username and password. It didn't work at the time, but that was some time ago when I knew less about LAVA.

For everyone's benefit:
The requirement of needing to log into the Beaglebone-Black (BBB) as root prior to running a test is a small, but very annoying and persistent problem that Christos and I ran into when we first started to test live on the BBB. If you watch the log file of the health check as it is being executed, you'll see that the script makes the connection to the BBB, but then it gets hung up. It needs to send a carriage return to the BBB prior to applying the username and password since that is what we have to do when we are trying to telnet into the BBB manually.

I'm trying to solve this by writing an 'expect' script that will: 
1.) Make the connection to the BBB
2.) Wait for something like "'^]'" to be displayed and then wait a second or two
3.) Send the '\r' to the BBB so it advances to the "login:" prompt
4.) Return control back to the Test Script where it *should* issue the username and password.

If this approach works, I *think* we can call the expect script in place of the 'telnet localhost 8020' - and we can update the Device Dictionary so LAVA runs the new command too.

I hope that helps!





Sincerely,

Don Brown. PMP
don.f.brown@...
Mobile: (317) 560-0513
Here's to Life, Linux and the Pursuit of Happiness

On Wed, Apr 19, 2017 at 8:00 AM, <cip-dev-request@...> wrote:
Send cip-dev mailing list submissions to
        cip-dev@...

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.cip-project.org/mailman/listinfo/cip-dev
or, via email, send a message with subject or body 'help' to
        cip-dev-request@...project.org

You can reach the person managing the list at
        cip-dev-owner@...project.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cip-dev digest..."


Today's Topics:

   1. telnet connection and bbb testing (Robert Marshall)
   2. CIP TSC meeting minutes (17 April 2017) (KOBAYASHI Yoshitake)
   3. Re: CIP TSC meeting minutes (17 April 2017)
      (Agustin Benito Bethencourt)
   4. CIP workshop on 30th May at the OSSJ venue
      (Agustin Benito Bethencourt)


----------------------------------------------------------------------

Message: 1
Date: Tue, 18 Apr 2017 15:00:35 +0100
From: Robert Marshall <robert.marshall@....uk>
To: cip-dev@...
Subject: [cip-dev] telnet connection and bbb testing
Message-ID: <87inm1izng.fsf@ctlt579.codethink.co.uk>
Content-Type: text/plain

Don

Our bbb_debian_ramdisk_test2.yaml has a auto_login section defining a
login prompt username and password - was this approach tried and abandoned before
starting to use keeping a telnet session active on the beaglebone-black
tests?

Robert


------------------------------

Message: 2
Date: Tue, 18 Apr 2017 23:42:51 +0900
From: KOBAYASHI Yoshitake <yoshitake.kobayashi@toshiba.co.jp>
To: cip-dev@...
Subject: [cip-dev] CIP TSC meeting minutes (17 April 2017)
Message-ID: <268e138b-7f80-e674-6772-97806b659711@...>
Content-Type: text/plain; charset=utf-8

Hi all,

I have uploaded meeting minutes for yesterday's CIP TSC conference call.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr172017

If you have any comments, please let us know.

Best regards,
Yoshi



------------------------------

Message: 3
Date: Tue, 18 Apr 2017 17:06:34 +0100
From: Agustin Benito Bethencourt <agustin.benito@....uk>
To: KOBAYASHI Yoshitake <yoshitake.kobayashi@toshiba.co.jp>
Cc: cip-dev@...
Subject: Re: [cip-dev] CIP TSC meeting minutes (17 April 2017)
Message-ID: <58F6398A.2080601@codethink.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

On 18/04/17 15:42, KOBAYASHI Yoshitake wrote:
> Hi all,
>
> I have uploaded meeting minutes for yesterday's CIP TSC conference call.
> https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr172017
>
> If you have any comments, please let us know.

Thank you very much for formatting and publishing the minutes. I see
this as a small but relevant improvement towards transparency.

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


------------------------------

Message: 4
Date: Tue, 18 Apr 2017 17:13:37 +0100
From: Agustin Benito Bethencourt <agustin.benito@....uk>
To: "cip-dev@..." <cip-dev@...>
Subject: [cip-dev] CIP workshop on 30th May at the OSSJ venue
Message-ID: <58F63B31.8040102@codethink.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed

Dear CIP friends,

as you can read in the meeting minutes of yesterday's TSC meeting[1],
the day before the Open Source Summit Japan starts, May 30th, we will
organise some specific sessions related with CIP in the same venue.

We are in the process of defining what we will do from 11:00 to 17:00.
Feel free to:
* Let us know if you are interested in attending.
* Provide input on the topics you would like to work on, discuss or
receive information.

Maybe creating a wiki page to coordinate the activities would be wise,
right?

Best Regards


[1]
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr172017

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


------------------------------

_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


End of cip-dev Digest, Vol 11, Issue 8
**************************************


Re: telnet connection and bbb testing

Robert Marshall <robert.marshall@...>
 

Don Brown <don.f.brown@comcast.net> writes:
(reformatted Don's response)

Robert Marshall <robert.marshall@codethink.co.uk> wrote:

Don

Our bbb_debian_ramdisk_test2.yaml has a auto_login section defining a
login prompt username and password - was this approach tried and abandoned before
starting to use keeping a telnet session active on the beaglebone-black
tests?
Hi Robert,

Yes. I started with the test tutorial here: https://validation.linaro.org/static/docs/v2/standard-armmp-ramdisk-bbb.html
You will notice that there is no login or password.

When I had problems getting the test to properly log in to the BBB, I copied and modified the script into
'bbb_debian_ramdisk_test2.yaml' to include the username and password. It didn't work at the time, but that was some
time ago when I knew less about LAVA.

For everyone's benefit:
The requirement of needing to log into the Beaglebone-Black (BBB) as root prior to running a test is a small, but very
annoying and persistent problem that Christos and I ran into when we first started to test live on the BBB. If you watch
the log file of the health check as it is being executed, you'll see that the script makes the connection to the BBB, but then
it gets hung up. It needs to send a carriage return to the BBB prior to applying the username and password since that is
what we have to do when we are trying to telnet into the BBB manually.

I'm trying to solve this by writing an 'expect' script that will:
1.) Make the connection to the BBB
2.) Wait for something like "'^]'" to be displayed and then wait a second or two
3.) Send the '\r' to the BBB so it advances to the "login:" prompt
4.) Return control back to the Test Script where it *should* issue the username and password.

If this approach works, I *think* we can call the expect script in place of the 'telnet localhost 8020' - and we can update
the Device Dictionary so LAVA runs the new command too.

I hope that helps!
I'm now using this script - using expect - a wrapper around the telnet
connection_command and getting fairly consistent health check successes
without any manual intervention with the Beaglebone black

Robert


Re: [Fuego] Discussion about Fuego unified results format

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Kevin,

-----Original Message-----
From: fuego-bounces@lists.linuxfoundation.org [mailto:fuego-bounces@lists.linuxfoundation.org] On Behalf Of Kevin Hilman
Has anyone looked at the JSON schema we designed for kernelci.org[1]? I
Thanks, I checked it a few months ago but not in depth yet. At the time I came
to the conclusion that there was a separate schema for each type of test (build,
boot,..). Has that changed or is it a misunderstanding from my side?.
Ref: https://api.kernelci.org/schema.html
Ref: https://api.kernelci.org/schema-boot.html
Ref: https://api.kernelci.org/schema-build.html

[Note] I think we would rather have a single generic format for all tests.

wasn't involved in the meetings or call, but from what I can see, one
important thing missing from your current proposal is how to group
related tests together. In the schema we did for kCI, you can have test
cases grouped into test sets, which in turn can be grouped into a test
suite. IMO, this is crucial since most tests come as part of a larger
suite.
Actually, the current JSON output goes as follows:

testsuite (e.g.: Functional.LTP)
--board (e.g. Beaglebone black)
----kernel version (e.g.: CIP kernel 4.4.55 ...)
------spec (e.g.: default or quick)
--------build number (like KernelCI build id)
----------groupname <-- we do have groups! (e.g.: 2048b_sector_size)
------------test1 (e.g.: reads)
-------------- measurement
-------------- reference value (e.g. a threshold of Mb/s)
------------test2 (e.g. writes)
------------test3 (e.g.: re-writes)

[Note] We also have the concept of testplans where you can group testsuites
and their specs for a specific board. This is quite useful.

Apart from this information we also store timestamps, the test raw output,
fuego variables (this needs improvements but it will be useful for "replaying" tests),
and a developers log (including syslog errors, cat /proc/cpuinfo, ps output etc..).

Rather than the format, for now I want to check that we are not missing
important data. If we keep the data, then we can easily convert it to other
formats.

I am checking Kernel CI's output schema(s) from the link you sent:

1) parameters: seems to be the equivalent to our specs
2) minimum, maximum, number of samples, samples_sum, samples_swr_sum: we don't store
information that can be inferred from the data at the moment, just calculate it when making a report.
3) status: at the moment the JSON output is only working for Benchmarks but I am fixing this. Probably
I will do as Kernel CI and specify PASS, FAIL, SKIP, ERROR (in LTP, I use BROKEN)
4) vcs_commit: until now all tests were in tarballs, but I already added one test (kernel_build) that uses
git, so I want to store the commit ids too.
5) kvm_guest: this would be just another board name in Fuego, so we don't include such specific parameter.
6) definition_uri: the URI is inferred from the data in our case right now. In other words, the folder where the
data is stored is a combination of the board's name, testname, spec, build number etc..
7) time: this is stored by jenkins, but not in the json output. We will probably have to analyze the
Jenkins build output XML, extract such information and add it to the JSON output. I think this work is already
done by Cai Song, so I want to merge that.
8) attachments: we have something similar (success_links and fail_links in the spec) that are used to present a link on
the jenkins interface. This way the user can download the results (e.g.: excel file, a tar.gz file, a log file, a png..).
9) metadata: we don't have this at the moment, but I think it's covered by the testlog, devlog, and links.
10) kernel: we have this as fwver (we use the word firmware since it doesn't need to be the linux kernel)
11) defconfig: we do not store this at the moment. In the kernel_build test the spec has a "config" parameter that
has similar functionality though.
12) arch: this is stored as part of the board parameters (the board files contain other variables
such as the toolchain used, path used for tests, etc..)
13) created_on: this information is probably stored inside jenkins.
14) lab_name: this seems similar to the information that Tim wants to add for sharing tests.
15) test_set: this looks similar to fuego's groupnames.
16) test_case: we have test cases (called test in Fuego, although there is a naming inconsistency
issue in Fuego at the moment) support. However I want to add the ability to define or "undefine"
which test cases need to be run. For example, in LTP we can select
which groups we want to run (syscalls, fs, SEM, etc..), but we run all of the subtests at the moment.
I would like to be able to skip some of the tests, or define which ones to execute.
[Note] If possible we want tests to automatically detect whether they are compatible with the board or not.

My conclusion is that we are quite close to the kernel CI schemas in terms of information stored.
We need to add a bit more information, and consolidate it. Probably this will take several prototyping
cycles, until all use cases are covered.

The kernelci.org project has prototyped this for several testsuites
(kselftest, hackbench, lmbench, LTP, etc.) and were pushing JSON results
using this /test API to our backend for awhile. But nobody got around
to writing the parsing, reporting stuff yet.
The reporting part in Fuego needs to be improved as well, I will be working on this soon.
I think that reports should be based on templates, so that the user can prepare his/her
own template (e.g.: in Japanese) and Fuego will create the document filling the gaps
with data.

All of that to say the kCI JSON schema has been through through quite a
bit already, and acually used for several test suites, so I think it
would be a good idea to start with that and extend it, so combined
efforts on this JSON test schema could benefit Fuego as well as other
projects.
At the moment I am thinking about the architecture and how all these efforts
can combine in a win-win manner. So far this is what I'm thinking:

- Local machines
+ Standard server/desktop distributions (redhat, debian..): use avocado (or openqa for example)
-> output formats: http://avocado-framework.readthedocs.io/en/48.0/ResultFormats.html
+ Embedded cross-compiled custom distributions (e.g.: yocto-based or buildroot based): use Fuego
-> output formats: custom format that should include all the information necessary.
For this format we can use KernelCI schema as a reference, but I'd rather be loosely coupled,
so that we can add our own quirks and have some flexibility.

- Remote boards / board farms / labs
+ Use Fuego combined with LAVA. Jan-Simon added some initial support, but
we want to improve it.

- Centralized servers for sharing the results of multiple Fuego "stations"
+ Option 1: Use a custom web app
-> Fuego supports (needs fixing) packaging the results of a test run (ftc package-run)
and uploading them to a server (ftc put-run). Tim showed us a demo during ELC
where he developed a prototype web app that displayed the shared results.
+ Option 2: Use the KernelCI web app
-> KernelCI web app is a strong option but we may need to extend
some parts. In that case, I would like to work with you and the KernelCI
maintainers because it is too complex to maintain a fork.
Fuego could have a command like "ftc push -f kernelci -s 172.34.5.2" where the
internal custom format would be converted to KernelCI schema and POST'ed
-> The web app must be portable and easy to deploy. We don't want only one
single server on the whole Internet. This work at the CIP project is very
valuable in this sense: https://github.com/cip-project/cip-kernelci
+ Option 3: Use Fuego itself
-> Fuego is based on Jenkins which is already a server and has many features
including a REST API and user accounts.
-> Fuego already supports parsing results into plots, links each build number,
trend graphs with PASS/FAIL results, etc.

Personally I want to concentrate on Option 3 at first because it requires the least effort
and is useful both for local Fuego stations and centralized servers.

But I would be really happy to help on Option 2 as well as on the LAVA support. If possible
I'd rather do this in collaboration with Baylibre , the automotive-grade linux project
and the CIP project.

We could start with a small prototype that runs Fuego tests on a Baylibre's LAVA-scheduled board (e.g. Renesas board),
and then "ftc push" the results into a Baylibre's KernelCI server (I'd probably need some account for that?).
And next, make sure that it also runs on the CIP LAVA-KernelCI stack.
What do you think?

# It would be great to discuss this during the next Open Source Summit Japan
# Tim: are there any news regarding to Option 1?

Best regards,
Daniel


Problems installing "Board at desk"

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi,

I am trying the "board-at-desk-single-dev" project (sorry to do it so late).
I managed to build the CIP kernel and see the job results using KernelCI.
However, I am having problems with LAVA health checks (see at the end).

First, I would like to report on a few problems I had to solve to get the kernel built:

*************************************************
1) Although now I know that the current development occurs at
https://gitlab.com/cip-project/board-at-desk-single-dev.git
googling "CIP kernelci" gives also the following outdated (?) sites which can
be confusing:
https://github.com/cip-project/cip-kernelci.git
https://gitlab.com/cip-project/kernelci-debian.git

Q: are they necessary? or is it some misunderstanding from my side?

2) Problems behind a proxy

a) I did the following to setup proxy settings for vagrant on Ubuntu 16.04 Xenial:

$ sudo apt-get remove vagrant <-- gives errors when installing vagrant-proxyconf
$ dpkg -i vagrant_1.9.4_x86_64.deb
$ vagrant plugin install vagrant-proxyconf
$ vi Vagrantfile
+ if Vagrant.has_plugin?("vagrant-proxyconf")
+ config.proxy.http = "http://xxx:yyyy/"
+ config.proxy.https = "https://xxx:yyy/"
+ config.proxy.no_proxy = "127.0.0.1,localhost,xxxx."
+ end

Q: maybe it would be good to add this to the tutorial

b) I got an error during vagrant up

==> default: fatal: [kernel-ci-backend]: FAILED! => {"changed": false, "cmd": "/usr/bin/apt-key adv --keyserver hkp://keyserver.ubuntu.com --recv EA312927", "failed": true,
- Solved it by adding port 80 for apt-key
$ vagrant ssh
guest$ vi kernelci-backend/roles/install-deps/tasks/install-mongodb.yml
- hkp://keyserver.ubuntu.com
+hkp://keyserver.ubuntu.com:80
[Alt] sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv EA312927

Q: if that works without proxies, maybe it should be set to 80 by default?

c) I got a lot of warnings like these ones

- Warning 1 (ignore)
GetPassWarning: Can not control echo on the terminal.” or “Warning: Password input may be echoed.” - These do not affect the operation of the KernelCI VM.
- Warning 2 (ignore)
==> default: lava_scheduler_app.Notification.job_status_trigger: (fields.W901) CommaSeparatedIntegerField has been deprecated. Support for it (except in historical migrations) will be removed in Django 2.0.
==> default: HINT: Use CharField(validators=[validate_comma_separated_integer_list]) instead.

Q: The tutorial mentions Warning 1, but not Warning 2. Maybe adding that would be a good idea.

3) Modifying the 8080 port (very commonly used port, e.g. Fuego ;_+)

I solved this by
$ vi Vagrantfile
+ config.vm.network :forwarded_port, guest: 8081, host: 8081
$ sudo vi /etc/apache2/ports.conf
-> change to 8081
$ sudo vi /etc/apache2/sites-enabled/lava-server.conf
-> change to 8081
$ sudo service apache2 restart
$ sudo /etc/init.d/lava-server restart

Q: maybe this could be automated (?)
*************************************************

Second, regarding to LAVA health checks I think this is again a problem with being behind a
proxy but I'm not sure how to debug it. These are the error messages that I get
with QEMU's health check (/vagrant/tests/qemu-health-check.yaml)

- log:
Root tmp directory created at /var/lib/lava/dispatcher/tmp/7
start: 0 validate
Validating that https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz exists
no device environment specified
Invalid job definition
Invalid job data: ["HTTPSConnectionPool(host='images.validation.linaro.org', port=443): Max retries exceeded with url: /kvm/standard/stretch-2.img.gz (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7f430c9b9c50>: Failed to establish a new connection: [Errno -5] No address associated with hostname',))"]
validate duration: 0.02
Cleanup: removing /var/lib/lava/dispatcher/tmp/7
- traceback
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/lava/dispatcher/commands.py", line 88, in run_pipeline_job
job.validate(simulate=validate_only)
File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/job.py", line 173, in validate
self.pipeline.validate_actions()
File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line 205, in validate_actions
raise JobError("Invalid job data: %s\n" % self.errors)
JobError: Invalid job data: ["HTTPSConnectionPool(host='images.validation.linaro.org', port=443): Max retries exceeded with url: /kvm/standard/stretch-2.img.gz (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7f430c9b9c50>: Failed to establish a new connection: [Errno -5] No address associated with hostname',))"]

If someone has a clue about this please let me know.
# http_proxy-like variables are all defined in the VM (/etc/environment), and I can use wget and download
stretch-2.img.gz without problems.

Best regards,
Daniel


Re: Problems installing "Board at desk"

Mauerer, Wolfgang
 

Hi Daniel,

On 26.04.2017 10:27, Daniel Sangorrin wrote:
Hi,

I am trying the "board-at-desk-single-dev" project (sorry to do it so late).
I managed to build the CIP kernel and see the job results using KernelCI.
However, I am having problems with LAVA health checks (see at the end).

First, I would like to report on a few problems I had to solve to get the kernel built:

*************************************************
1) Although now I know that the current development occurs at
https://gitlab.com/cip-project/board-at-desk-single-dev.git
googling "CIP kernelci" gives also the following outdated (?) sites which can
be confusing:
https://github.com/cip-project/cip-kernelci.git
the github ressource is here for historic reasons. Unless anyone
disagrees, I'm going to remove it.

Thanks, Wolfgang

https://gitlab.com/cip-project/kernelci-debian.git

Q: are they necessary? or is it some misunderstanding from my side?

2) Problems behind a proxy

a) I did the following to setup proxy settings for vagrant on Ubuntu 16.04 Xenial:

$ sudo apt-get remove vagrant <-- gives errors when installing vagrant-proxyconf
$ dpkg -i vagrant_1.9.4_x86_64.deb
$ vagrant plugin install vagrant-proxyconf
$ vi Vagrantfile
+ if Vagrant.has_plugin?("vagrant-proxyconf")
+ config.proxy.http = "http://xxx:yyyy/"
+ config.proxy.https = "https://xxx:yyy/"
+ config.proxy.no_proxy = "127.0.0.1,localhost,xxxx."
+ end

Q: maybe it would be good to add this to the tutorial

b) I got an error during vagrant up

==> default: fatal: [kernel-ci-backend]: FAILED! => {"changed": false, "cmd": "/usr/bin/apt-key adv --keyserver hkp://keyserver.ubuntu.com --recv EA312927", "failed": true,
- Solved it by adding port 80 for apt-key
$ vagrant ssh
guest$ vi kernelci-backend/roles/install-deps/tasks/install-mongodb.yml
- hkp://keyserver.ubuntu.com
+hkp://keyserver.ubuntu.com:80
[Alt] sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv EA312927

Q: if that works without proxies, maybe it should be set to 80 by default?

c) I got a lot of warnings like these ones

- Warning 1 (ignore)
GetPassWarning: Can not control echo on the terminal.” or “Warning: Password input may be echoed.” - These do not affect the operation of the KernelCI VM.
- Warning 2 (ignore)
==> default: lava_scheduler_app.Notification.job_status_trigger: (fields.W901) CommaSeparatedIntegerField has been deprecated. Support for it (except in historical migrations) will be removed in Django 2.0.
==> default: HINT: Use CharField(validators=[validate_comma_separated_integer_list]) instead.

Q: The tutorial mentions Warning 1, but not Warning 2. Maybe adding that would be a good idea.

3) Modifying the 8080 port (very commonly used port, e.g. Fuego ;_+)

I solved this by
$ vi Vagrantfile
+ config.vm.network :forwarded_port, guest: 8081, host: 8081
$ sudo vi /etc/apache2/ports.conf
-> change to 8081
$ sudo vi /etc/apache2/sites-enabled/lava-server.conf
-> change to 8081
$ sudo service apache2 restart
$ sudo /etc/init.d/lava-server restart

Q: maybe this could be automated (?)
*************************************************

Second, regarding to LAVA health checks I think this is again a problem with being behind a
proxy but I'm not sure how to debug it. These are the error messages that I get
with QEMU's health check (/vagrant/tests/qemu-health-check.yaml)

- log:
Root tmp directory created at /var/lib/lava/dispatcher/tmp/7
start: 0 validate
Validating that https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz exists
no device environment specified
Invalid job definition
Invalid job data: ["HTTPSConnectionPool(host='images.validation.linaro.org', port=443): Max retries exceeded with url: /kvm/standard/stretch-2.img.gz (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7f430c9b9c50>: Failed to establish a new connection: [Errno -5] No address associated with hostname',))"]
validate duration: 0.02
Cleanup: removing /var/lib/lava/dispatcher/tmp/7
- traceback
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/lava/dispatcher/commands.py", line 88, in run_pipeline_job
job.validate(simulate=validate_only)
File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/job.py", line 173, in validate
self.pipeline.validate_actions()
File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line 205, in validate_actions
raise JobError("Invalid job data: %s\n" % self.errors)
JobError: Invalid job data: ["HTTPSConnectionPool(host='images.validation.linaro.org', port=443): Max retries exceeded with url: /kvm/standard/stretch-2.img.gz (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7f430c9b9c50>: Failed to establish a new connection: [Errno -5] No address associated with hostname',))"]

If someone has a clue about this please let me know.
# http_proxy-like variables are all defined in the VM (/etc/environment), and I can use wget and download
stretch-2.img.gz without problems.

Best regards,
Daniel



_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Problems installing "Board at desk"

Yoshitake Kobayashi
 

Hi Daniel and Wolfgang,

Daniel>
As Wolfgang mentioned, please use Gitlab repositories.

I kept cip-project on Github to create a mirror from Gitlab, because of network bandwidth reason.
Currently, only linux-cip repository is automatically synchronized with CIP official repository on Gitlab.
If others are OK, I will work to create exactly same repository set from Gitlab.

Best regards,
Yoshi

2017年4月26日(水) 17:36 Wolfgang Mauerer <wolfgang.mauerer@...>:

Hi Daniel,

On 26.04.2017 10:27, Daniel Sangorrin wrote:
> Hi,
>
> I am trying the "board-at-desk-single-dev" project (sorry to do it so late).
> I managed to build the CIP kernel and see the job results using KernelCI.
> However, I am having problems with LAVA health checks (see at the end).
>
> First, I would like to report on a few problems I had to solve to get the kernel built:
>
> *************************************************
> 1) Although now I know that the current development occurs at
> https://gitlab.com/cip-project/board-at-desk-single-dev.git
> googling "CIP kernelci" gives also the following outdated (?) sites which can
> be confusing:
> https://github.com/cip-project/cip-kernelci.git
the github ressource is here for historic reasons. Unless anyone
disagrees, I'm going to remove it.

Thanks, Wolfgang

> https://gitlab.com/cip-project/kernelci-debian.git
>
> Q: are they necessary? or is it some misunderstanding from my side?
>
> 2) Problems behind a proxy
>
> a) I did the following to setup proxy settings for vagrant on Ubuntu 16.04 Xenial:
>
>    $ sudo apt-get remove vagrant <-- gives errors when installing vagrant-proxyconf
>    $ dpkg -i vagrant_1.9.4_x86_64.deb
>    $ vagrant plugin install vagrant-proxyconf
>    $ vi Vagrantfile
> + if Vagrant.has_plugin?("vagrant-proxyconf")
> +   config.proxy.http     = "http://xxx:yyyy/"
> +   config.proxy.https    = "https://xxx:yyy/"
> +   config.proxy.no_proxy = "127.0.0.1,localhost,xxxx."
> + end
>
> Q: maybe it would be good to add this to the tutorial
>
> b) I got an error during vagrant up
>
> ==> default: fatal: [kernel-ci-backend]: FAILED! => {"changed": false, "cmd": "/usr/bin/apt-key adv --keyserver hkp://keyserver.ubuntu.com --recv EA312927", "failed": true,
> - Solved it by adding port 80 for apt-key
>    $ vagrant ssh
>     guest$ vi kernelci-backend/roles/install-deps/tasks/install-mongodb.yml
>                 - hkp://keyserver.ubuntu.com
>       +hkp://keyserver.ubuntu.com:80
>      [Alt]  sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv EA312927
>
> Q: if that works without proxies, maybe it should be set to 80 by default?
>
> c) I got a lot of warnings like these ones
>
> - Warning 1 (ignore)
>     GetPassWarning: Can not control echo on the terminal.” or “Warning: Password input may be echoed.” - These do not affect the operation of the KernelCI VM.
> - Warning 2 (ignore)
>     ==> default: lava_scheduler_app.Notification.job_status_trigger: (fields.W901) CommaSeparatedIntegerField has been deprecated. Support for it (except in historical migrations) will be removed in Django 2.0.
>     ==> default:      HINT: Use CharField(validators=[validate_comma_separated_integer_list]) instead.
>
> Q: The tutorial mentions Warning 1, but not Warning 2. Maybe adding that would be a good idea.
>
> 3) Modifying the 8080 port (very commonly used port, e.g. Fuego ;_+)
>
> I solved this by
>    $   vi Vagrantfile
>        +  config.vm.network :forwarded_port, guest: 8081, host: 8081
>     $ sudo vi /etc/apache2/ports.conf
>         -> change to 8081
>     $ sudo vi /etc/apache2/sites-enabled/lava-server.conf
>         -> change to 8081
>     $ sudo service apache2 restart
>     $ sudo /etc/init.d/lava-server restart
>
> Q: maybe this could be automated (?)
> *************************************************
>
> Second, regarding to LAVA health checks I think this is again a problem with being behind a
> proxy but I'm not sure how to debug it. These are the error messages that I get
> with QEMU's health check (/vagrant/tests/qemu-health-check.yaml)
>
>     - log:
>         Root tmp directory created at /var/lib/lava/dispatcher/tmp/7
>         start: 0 validate
>         Validating that https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz exists
>         no device environment specified
>         Invalid job definition
>         Invalid job data: ["HTTPSConnectionPool(host='images.validation.linaro.org', port=443): Max retries exceeded with url: /kvm/standard/stretch-2.img.gz (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7f430c9b9c50>: Failed to establish a new connection: [Errno -5] No address associated with hostname',))"]
>         validate duration: 0.02
>         Cleanup: removing /var/lib/lava/dispatcher/tmp/7
>     - traceback
>         Traceback (most recent call last):
>           File "/usr/lib/python2.7/dist-packages/lava/dispatcher/commands.py", line 88, in run_pipeline_job
>             job.validate(simulate=validate_only)
>           File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/job.py", line 173, in validate
>             self.pipeline.validate_actions()
>           File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line 205, in validate_actions
>             raise JobError("Invalid job data: %s\n" % self.errors)
>         JobError: Invalid job data: ["HTTPSConnectionPool(host='images.validation.linaro.org', port=443): Max retries exceeded with url: /kvm/standard/stretch-2.img.gz (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7f430c9b9c50>: Failed to establish a new connection: [Errno -5] No address associated with hostname',))"]
>
> If someone has a clue about this please let me know.
> # http_proxy-like variables are all defined in the VM (/etc/environment), and I can use wget and download
> stretch-2.img.gz without problems.
>
> Best regards,
> Daniel
>
>
>
> _______________________________________________
> cip-dev mailing list
> cip-dev@...
> https://lists.cip-project.org/mailman/listinfo/cip-dev
>
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Problems installing "Board at desk"

Mauerer, Wolfgang
 

Hi Yoshi,

On 26.04.2017 11:00, Yoshitake Kobayashi wrote:
Hi Daniel and Wolfgang,

Daniel>
As Wolfgang mentioned, please use Gitlab repositories.

I kept cip-project on Github to create a mirror from Gitlab, because of
network bandwidth reason.
Currently, only linux-cip repository is automatically synchronized with
CIP official repository on Gitlab.
If others are OK, I will work to create exactly same repository set from
Gitlab.
that's of course also fine for me.

Thanks, Wolfgang

Best regards,
Yoshi

2017年4月26日(水) 17:36 Wolfgang Mauerer <wolfgang.mauerer@siemens.com
<mailto:wolfgang.mauerer@siemens.com>>:

Hi Daniel,

On 26.04.2017 10:27, Daniel Sangorrin wrote:
> Hi,
>
> I am trying the "board-at-desk-single-dev" project (sorry to do it
so late).
> I managed to build the CIP kernel and see the job results using
KernelCI.
> However, I am having problems with LAVA health checks (see at the
end).
>
> First, I would like to report on a few problems I had to solve to
get the kernel built:
>
> *************************************************
> 1) Although now I know that the current development occurs at
> https://gitlab.com/cip-project/board-at-desk-single-dev.git
> googling "CIP kernelci" gives also the following outdated (?)
sites which can
> be confusing:
> https://github.com/cip-project/cip-kernelci.git
the github ressource is here for historic reasons. Unless anyone
disagrees, I'm going to remove it.

Thanks, Wolfgang

> https://gitlab.com/cip-project/kernelci-debian.git
>
> Q: are they necessary? or is it some misunderstanding from my side?
>
> 2) Problems behind a proxy
>
> a) I did the following to setup proxy settings for vagrant on
Ubuntu 16.04 Xenial:
>
> $ sudo apt-get remove vagrant <-- gives errors when installing
vagrant-proxyconf
> $ dpkg -i vagrant_1.9.4_x86_64.deb
> $ vagrant plugin install vagrant-proxyconf
> $ vi Vagrantfile
> + if Vagrant.has_plugin?("vagrant-proxyconf")
> + config.proxy.http = "http://xxx:yyyy/"
> + config.proxy.https = "https://xxx:yyy/"
> + config.proxy.no_proxy = "127.0.0.1,localhost,xxxx."
> + end
>
> Q: maybe it would be good to add this to the tutorial
>
> b) I got an error during vagrant up
>
> ==> default: fatal: [kernel-ci-backend]: FAILED! => {"changed":
false, "cmd": "/usr/bin/apt-key adv --keyserver
hkp://keyserver.ubuntu.com <http://keyserver.ubuntu.com> --recv
EA312927", "failed": true,
> - Solved it by adding port 80 for apt-key
> $ vagrant ssh
> guest$ vi
kernelci-backend/roles/install-deps/tasks/install-mongodb.yml
> - hkp://keyserver.ubuntu.com
<http://keyserver.ubuntu.com>
> +hkp://keyserver.ubuntu.com:80 <http://keyserver.ubuntu.com:80>
> [Alt] sudo apt-key adv --keyserver
hkp://keyserver.ubuntu.com:80 <http://keyserver.ubuntu.com:80>
--recv EA312927
>
> Q: if that works without proxies, maybe it should be set to 80 by
default?
>
> c) I got a lot of warnings like these ones
>
> - Warning 1 (ignore)
> GetPassWarning: Can not control echo on the terminal.” or
“Warning: Password input may be echoed.” - These do not affect the
operation of the KernelCI VM.
> - Warning 2 (ignore)
> ==> default:
lava_scheduler_app.Notification.job_status_trigger: (fields.W901)
CommaSeparatedIntegerField has been deprecated. Support for it
(except in historical migrations) will be removed in Django 2.0.
> ==> default: HINT: Use
CharField(validators=[validate_comma_separated_integer_list]) instead.
>
> Q: The tutorial mentions Warning 1, but not Warning 2. Maybe
adding that would be a good idea.
>
> 3) Modifying the 8080 port (very commonly used port, e.g. Fuego ;_+)
>
> I solved this by
> $ vi Vagrantfile
> + config.vm.network :forwarded_port, guest: 8081, host: 8081
> $ sudo vi /etc/apache2/ports.conf
> -> change to 8081
> $ sudo vi /etc/apache2/sites-enabled/lava-server.conf
> -> change to 8081
> $ sudo service apache2 restart
> $ sudo /etc/init.d/lava-server restart
>
> Q: maybe this could be automated (?)
> *************************************************
>
> Second, regarding to LAVA health checks I think this is again a
problem with being behind a
> proxy but I'm not sure how to debug it. These are the error
messages that I get
> with QEMU's health check (/vagrant/tests/qemu-health-check.yaml)
>
> - log:
> Root tmp directory created at /var/lib/lava/dispatcher/tmp/7
> start: 0 validate
> Validating that
https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz
exists
> no device environment specified
> Invalid job definition
> Invalid job data:
["HTTPSConnectionPool(host='images.validation.linaro.org
<http://images.validation.linaro.org>', port=443): Max retries
exceeded with url: /kvm/standard/stretch-2.img.gz (Caused by
NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection
object at 0x7f430c9b9c50>: Failed to establish a new connection:
[Errno -5] No address associated with hostname',))"]
> validate duration: 0.02
> Cleanup: removing /var/lib/lava/dispatcher/tmp/7
> - traceback
> Traceback (most recent call last):
> File
"/usr/lib/python2.7/dist-packages/lava/dispatcher/commands.py", line
88, in run_pipeline_job
> job.validate(simulate=validate_only)
> File
"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/job.py",
line 173, in validate
> self.pipeline.validate_actions()
> File
"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py",
line 205, in validate_actions
> raise JobError("Invalid job data: %s\n" % self.errors)
> JobError: Invalid job data:
["HTTPSConnectionPool(host='images.validation.linaro.org
<http://images.validation.linaro.org>', port=443): Max retries
exceeded with url: /kvm/standard/stretch-2.img.gz (Caused by
NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection
object at 0x7f430c9b9c50>: Failed to establish a new connection:
[Errno -5] No address associated with hostname',))"]
>
> If someone has a clue about this please let me know.
> # http_proxy-like variables are all defined in the VM
(/etc/environment), and I can use wget and download
> stretch-2.img.gz without problems.
>
> Best regards,
> Daniel
>
>
>
> _______________________________________________
> cip-dev mailing list
> cip-dev@lists.cip-project.org <mailto:cip-dev@lists.cip-project.org>
> https://lists.cip-project.org/mailman/listinfo/cip-dev
>
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org <mailto:cip-dev@lists.cip-project.org>
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Problems installing "Board at desk"

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi Daniel,

On 26/04/17 10:04, Wolfgang Mauerer wrote:
Hi Yoshi,

On 26.04.2017 11:00, Yoshitake Kobayashi wrote:
Hi Daniel and Wolfgang,

Daniel>
As Wolfgang mentioned, please use Gitlab repositories.

I kept cip-project on Github to create a mirror from Gitlab, because of
network bandwidth reason.
Currently, only linux-cip repository is automatically synchronized with
CIP official repository on Gitlab.
If others are OK, I will work to create exactly same repository set from
Gitlab.
that's of course also fine for me.
Check this wiki page: https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting

There is a link to this repo in gitlab.com: https://gitlab.com/cip-project/board-at-desk-single-dev/tree/master

Download page: https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipdownload

Feature page: https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingboardatdesksingledevfeaturepage

Hopefully tomorrow I will send the report of the previous couple of weeks, including the link to the first VM for testing.


Thanks, Wolfgang

Best regards,
Yoshi

2017年4月26日(水) 17:36 Wolfgang Mauerer <wolfgang.mauerer@siemens.com
<mailto:wolfgang.mauerer@siemens.com>>:

Hi Daniel,

On 26.04.2017 10:27, Daniel Sangorrin wrote:
> Hi,
>
> I am trying the "board-at-desk-single-dev" project (sorry to do it
so late).
> I managed to build the CIP kernel and see the job results using
KernelCI.
> However, I am having problems with LAVA health checks (see at the
end).
>
> First, I would like to report on a few problems I had to solve to
get the kernel built:
>
> *************************************************
> 1) Although now I know that the current development occurs at
> https://gitlab.com/cip-project/board-at-desk-single-dev.git
> googling "CIP kernelci" gives also the following outdated (?)
sites which can
> be confusing:
> https://github.com/cip-project/cip-kernelci.git
the github ressource is here for historic reasons. Unless anyone
disagrees, I'm going to remove it.

Thanks, Wolfgang

> https://gitlab.com/cip-project/kernelci-debian.git
>
> Q: are they necessary? or is it some misunderstanding from my side?
>
> 2) Problems behind a proxy
>
> a) I did the following to setup proxy settings for vagrant on
Ubuntu 16.04 Xenial:
>
> $ sudo apt-get remove vagrant <-- gives errors when installing
vagrant-proxyconf
> $ dpkg -i vagrant_1.9.4_x86_64.deb
> $ vagrant plugin install vagrant-proxyconf
> $ vi Vagrantfile
> + if Vagrant.has_plugin?("vagrant-proxyconf")
> + config.proxy.http = "http://xxx:yyyy/"
> + config.proxy.https = "https://xxx:yyy/"
> + config.proxy.no_proxy = "127.0.0.1,localhost,xxxx."
> + end
>
> Q: maybe it would be good to add this to the tutorial
>
> b) I got an error during vagrant up
>
> ==> default: fatal: [kernel-ci-backend]: FAILED! => {"changed":
false, "cmd": "/usr/bin/apt-key adv --keyserver
hkp://keyserver.ubuntu.com <http://keyserver.ubuntu.com> --recv
EA312927", "failed": true,
> - Solved it by adding port 80 for apt-key
> $ vagrant ssh
> guest$ vi
kernelci-backend/roles/install-deps/tasks/install-mongodb.yml
> - hkp://keyserver.ubuntu.com
<http://keyserver.ubuntu.com>
> +hkp://keyserver.ubuntu.com:80
<http://keyserver.ubuntu.com:80>
> [Alt] sudo apt-key adv --keyserver
hkp://keyserver.ubuntu.com:80 <http://keyserver.ubuntu.com:80>
--recv EA312927
>
> Q: if that works without proxies, maybe it should be set to 80 by
default?
>
> c) I got a lot of warnings like these ones
>
> - Warning 1 (ignore)
> GetPassWarning: Can not control echo on the terminal.” or
“Warning: Password input may be echoed.” - These do not affect the
operation of the KernelCI VM.
> - Warning 2 (ignore)
> ==> default:
lava_scheduler_app.Notification.job_status_trigger: (fields.W901)
CommaSeparatedIntegerField has been deprecated. Support for it
(except in historical migrations) will be removed in Django 2.0.
> ==> default: HINT: Use
CharField(validators=[validate_comma_separated_integer_list])
instead.
>
> Q: The tutorial mentions Warning 1, but not Warning 2. Maybe
adding that would be a good idea.
>
> 3) Modifying the 8080 port (very commonly used port, e.g. Fuego
;_+)
>
> I solved this by
> $ vi Vagrantfile
> + config.vm.network :forwarded_port, guest: 8081, host:
8081
> $ sudo vi /etc/apache2/ports.conf
> -> change to 8081
> $ sudo vi /etc/apache2/sites-enabled/lava-server.conf
> -> change to 8081
> $ sudo service apache2 restart
> $ sudo /etc/init.d/lava-server restart
>
> Q: maybe this could be automated (?)
> *************************************************
>
> Second, regarding to LAVA health checks I think this is again a
problem with being behind a
> proxy but I'm not sure how to debug it. These are the error
messages that I get
> with QEMU's health check (/vagrant/tests/qemu-health-check.yaml)
>
> - log:
> Root tmp directory created at
/var/lib/lava/dispatcher/tmp/7
> start: 0 validate
> Validating that
https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz
exists
> no device environment specified
> Invalid job definition
> Invalid job data:
["HTTPSConnectionPool(host='images.validation.linaro.org
<http://images.validation.linaro.org>', port=443): Max retries
exceeded with url: /kvm/standard/stretch-2.img.gz (Caused by

NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection

object at 0x7f430c9b9c50>: Failed to establish a new connection:
[Errno -5] No address associated with hostname',))"]
> validate duration: 0.02
> Cleanup: removing /var/lib/lava/dispatcher/tmp/7
> - traceback
> Traceback (most recent call last):
> File
"/usr/lib/python2.7/dist-packages/lava/dispatcher/commands.py", line
88, in run_pipeline_job
> job.validate(simulate=validate_only)
> File
"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/job.py",
line 173, in validate
> self.pipeline.validate_actions()
> File

"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py",
line 205, in validate_actions
> raise JobError("Invalid job data: %s\n" % self.errors)
> JobError: Invalid job data:
["HTTPSConnectionPool(host='images.validation.linaro.org
<http://images.validation.linaro.org>', port=443): Max retries
exceeded with url: /kvm/standard/stretch-2.img.gz (Caused by

NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection

object at 0x7f430c9b9c50>: Failed to establish a new connection:
[Errno -5] No address associated with hostname',))"]
>
> If someone has a clue about this please let me know.
> # http_proxy-like variables are all defined in the VM
(/etc/environment), and I can use wget and download
> stretch-2.img.gz without problems.
>
> Best regards,
> Daniel
>
>
>
> _______________________________________________
> cip-dev mailing list
> cip-dev@lists.cip-project.org
<mailto:cip-dev@lists.cip-project.org>
> https://lists.cip-project.org/mailman/listinfo/cip-dev
>
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org <mailto:cip-dev@lists.cip-project.org>
https://lists.cip-project.org/mailman/listinfo/cip-dev
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk

201 - 220 of 8412