[cip-dev][isar-cip-core] Integration of test and security dependencies with cip-core

[cip-dev][isar-cip-core] Integration of test and security dependencies with cip-core

[Daniel Sangorrin]

[-- Attachment #1: Type: text/plain, Size: 3946 bytes --]

Hello Dinesh, Chris, Jan:

# BACKGROUND

As I mentioned in our last technical steering commite meeting, our gitlab-ci scripts should be able to produce multiple OS images. For example, the testing team needs to have python and possibly other software including the tests themshelves; and the security team needs to have extra packages and probably lots of customizations.

# CURRENT STATUS

At the moment we have what I would call "target images", which contain:

* something close to what I would call the "CIP Core Generic profile": 
    * the ISAR core packages
        * I think these are basically debootstrap minbase (isar/meta/recipes-core/isar-bootstrap)
    * some extra customizations
        * https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tree/master/recipes-core/
* target-dependent packages (kernel, u-boot, firmware, etc)
    * these are added using KAS opt.yaml syntax, instead of using a meta-layer
* options
    * opt-rt: will use a kernel with PREEMPT-RT patch
    * opt-stretch: will use stretch as distro
    * opt-4.4: will use kernel v4.4 instead of the default 4.10
    * opt-targz-img: exports the image as a tarball for LAVA

On the branch, iec-evaluation there is an initial implementation of the security image:
    * https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tree/security/iec-evaluation
    * at first they added an opt-security.yaml file:
        * https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commit/a8216d4ca5eed4d73dff2e00601dea7c9d733f45
    * then they changed to use recipes-core/images/cip-core-image-security.bb that extends IMAGE_PREINSTALL
        * https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commit/3461a50297e370210d76d85d434fb625c8c4248c
    * see the original thread here:
        * https://lore.kernel.org/cip-dev/TYXPR01MB180817C883F874B321DBA264E1FD0@TYXPR01MB1808.jpnprd01.prod.outlook.com/T/#m752a116d8372222d727722f4fe18ca19d94838eb

# MY PROPOSAL

My proposal as the next task for the CIP Core work group is to add metadata for releasing these images:

* target images: isar debootstrap + customizations + kernel/u-boot/fw
    * [NEW] release them as bmap images for our reference hardware boards
    * [NEW] create a page (gitlab wiki) that will contain links to the latest images and how-to-install readmes for each reference board
    * [NEW] refer to that page from the CIP wiki page (https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/cipreferencehardware)
* [NEW] testing images: target images + test dependencies
    * release them using opt-targz-img so they can be used in LAVA
    * add the test dependencies
        * packages: python2.7, python3, ...
        * tests: LTP, ...
            * method 1: build them on a separate repo and include in the image
            * method 2: build them with ISAR (new recipes) and include in the image
            * method 3: the artifacts are downloaded by LAVA <-- My preference
        * How to implement this
            * method 1: using the opt yaml format <-- My preference if we only need to specify packages
            * method 2: creating a separate meta layer
            * method 3: using a new image (cip-core-image-testing.bb)
* [NEW] security: target + security packages + security tests and dependencies
    * release in two formats
        * using opt-targz-img so they can be used in LAVA
        * as images for our reference hardware boards
            * add to the gitlab wiki links to the latest images and how-to-install readmes too
    * How to implement this
        * method 1: using the opt yaml format
        * method 2: creating a separate meta layer <-- My preference if it gets complex
        * method 3: using a new image (cip-core-image-security.bb) <-- Current method

# FEEDBACK

Please check my initial proposal and send me feedback.

Thanks,
Daniel Sangorrin





[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4624): https://lists.cip-project.org/g/cip-dev/message/4624
Mute This Topic: https://lists.cip-project.org/mt/74286250/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [cip-dev][isar-cip-core] Integration of test and security dependencies with cip-core

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 5397 bytes --]

Hi all,

On 18.05.20 08:37, daniel.sangorrin@toshiba.co.jp wrote:
> Hello Dinesh, Chris, Jan:
> 
> # BACKGROUND
> 
> As I mentioned in our last technical steering commite meeting, our gitlab-ci scripts should be able to produce multiple OS images. For example, the testing team needs to have python and possibly other software including the tests themshelves; and the security team needs to have extra packages and probably lots of customizations.
> 
> # CURRENT STATUS
> 
> At the moment we have what I would call "target images", which contain:
> 
> * something close to what I would call the "CIP Core Generic profile":
>      * the ISAR core packages
>          * I think these are basically debootstrap minbase (isar/meta/recipes-core/isar-bootstrap)
>      * some extra customizations
>          * https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tree/master/recipes-core/
> * target-dependent packages (kernel, u-boot, firmware, etc)
>      * these are added using KAS opt.yaml syntax, instead of using a meta-layer
> * options
>      * opt-rt: will use a kernel with PREEMPT-RT patch
>      * opt-stretch: will use stretch as distro
>      * opt-4.4: will use kernel v4.4 instead of the default 4.10
>      * opt-targz-img: exports the image as a tarball for LAVA
> 
> On the branch, iec-evaluation there is an initial implementation of the security image:
>      * https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tree/security/iec-evaluation
>      * at first they added an opt-security.yaml file:
>          * https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commit/a8216d4ca5eed4d73dff2e00601dea7c9d733f45
>      * then they changed to use recipes-core/images/cip-core-image-security.bb that extends IMAGE_PREINSTALL
>          * https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commit/3461a50297e370210d76d85d434fb625c8c4248c
>      * see the original thread here:
>          * https://lore.kernel.org/cip-dev/TYXPR01MB180817C883F874B321DBA264E1FD0@TYXPR01MB1808.jpnprd01.prod.outlook.com/T/#m752a116d8372222d727722f4fe18ca19d94838eb
> 
> # MY PROPOSAL
> 
> My proposal as the next task for the CIP Core work group is to add metadata for releasing these images:
> 
> * target images: isar debootstrap + customizations + kernel/u-boot/fw
>      * [NEW] release them as bmap images for our reference hardware boards
>      * [NEW] create a page (gitlab wiki) that will contain links to the latest images and how-to-install readmes for each reference board
>      * [NEW] refer to that page from the CIP wiki page (https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/cipreferencehardware)
> * [NEW] testing images: target images + test dependencies
>      * release them using opt-targz-img so they can be used in LAVA
>      * add the test dependencies
>          * packages: python2.7, python3, ...
>          * tests: LTP, ...
>              * method 1: build them on a separate repo and include in the image
>              * method 2: build them with ISAR (new recipes) and include in the image
>              * method 3: the artifacts are downloaded by LAVA <-- My preference

1 or 2. We can start with 2 and factor out 1 when it becomes too large.

You do not want to create the tested image only in lava "on the fly", 
you want that locally as well.

>          * How to implement this
>              * method 1: using the opt yaml format <-- My preference if we only need to specify packages
>              * method 2: creating a separate meta layer
>              * method 3: using a new image (cip-core-image-testing.bb)

Define a test image, that is cleanest. It shall be derived from the base 
image and contain all packages needed for testing. We do this internally 
as well. That image is selected by a kas option: opt-targz-img could 
become opt-lava-img or so.

> * [NEW] security: target + security packages + security tests and dependencies
>      * release in two formats
>          * using opt-targz-img so they can be used in LAVA

opt-lava-img -> select test image (with extra packages), switch output 
format.

>          * as images for our reference hardware boards
>              * add to the gitlab wiki links to the latest images and how-to-install readmes too
>      * How to implement this
>          * method 1: using the opt yaml format
>          * method 2: creating a separate meta layer <-- My preference if it gets complex

Something for later. At this stage, it will only increase the CM effort.

>          * method 3: using a new image (cip-core-image-security.bb) <-- Current method
> 

A new image recipe together with a new top-level kas file to select the 
image - and likely more. I can imagine that a secure core image will 
eventually not only affect the image recipe but also configuration 
options of the build, filesystem, secure boot etc. So, something like

  - kas-cip-core.yml
  - kas-cip-secure.yml

could make sense as entry points.

> # FEEDBACK
> 
> Please check my initial proposal and send me feedback.
> 
> Thanks,
> Daniel Sangorrin
> 

All that said: Nothing needs to be set in stone upfront. We can adjust 
the modeling as the usage evolves and the variants threaten to increase. 
But specifically due to the last aspect, the matrix should remain as 
small as possible.

Jan

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

[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4625): https://lists.cip-project.org/g/cip-dev/message/4625
Mute This Topic: https://lists.cip-project.org/mt/74286250/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [cip-dev][isar-cip-core] Integration of test and security dependencies with cip-core

[Daniel Sangorrin]

[-- Attachment #1: Type: text/plain, Size: 4155 bytes --]

Hi Jan, thanks for your feedback. Some comments inline

> From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Jan Kiszka
> > * [NEW] testing images: target images + test dependencies
> >      * release them using opt-targz-img so they can be used in LAVA
> >      * add the test dependencies
> >          * packages: python2.7, python3, ...
> >          * tests: LTP, ...
> >              * method 1: build them on a separate repo and include in the image
> >              * method 2: build them with ISAR (new recipes) and include in the image
> >              * method 3: the artifacts are downloaded by LAVA <-- My preference
> 
> 1 or 2. We can start with 2 and factor out 1 when it becomes too large.
> 
> You do not want to create the tested image only in lava "on the fly",
> you want that locally as well.

OK, I was assuming that we only wanted to test in LAVA. In that case, we should also create a link to the latest testing images for people to download.

> >          * How to implement this
> >              * method 1: using the opt yaml format <-- My preference if we only need to specify packages
> >              * method 2: creating a separate meta layer
> >              * method 3: using a new image (cip-core-image-testing.bb)
> 
> Define a test image, that is cleanest. It shall be derived from the base
> image and contain all packages needed for testing. We do this internally
> as well. 

OK, that sounds like the method 3 which is the same as what we currently do in the security branch (cip-core-image-security.bb inherits the minimal image).

> That image is selected by a kas option: opt-targz-img could
> become opt-lava-img or so.

Something like this?
  $ ./kas-docker --isar build kas.yml:board-xxx.yml:opt-testing:opt-lava-img
Where I
   * changed added a new option called opt-testing.yml
   * renamed opt-targz-img.yaml to opt-lava-img.yml

Thwre is also this option I think:
$ ./kas-docker --isar build --target cip-core-image-testing kas.yml:board-xxx.yml:opt-lava-img
Where I
   * changed the target to cip-core-image-testing
   * renamed opt-targz-img.yaml to opt-lava-img.yml

> > * [NEW] security: target + security packages + security tests and dependencies
> >      * release in two formats
> >          * using opt-targz-img so they can be used in LAVA
> 
> opt-lava-img -> select test image (with extra packages), switch output
> format.

Mmm your comment is a bit cryptic for me. I was thinking about something like this:
$ ./kas-docker --isar build kas.yml:board-xxx.yml:opt-security
[Alt] $ ./kas-docker --isar build --target cip-core-image-security kas.yml:board-xxx.yml
$ ./kas-docker --isar build kas.yml:board-xxx.yml:opt-security:opt-lava-img
[Alt] $ ./kas-docker --isar build --target cip-core-image-security kas.yml:board-xxx.yml:opt-lava-img

> >          * as images for our reference hardware boards
> >              * add to the gitlab wiki links to the latest images and how-to-install readmes too
> >      * How to implement this
> >          * method 1: using the opt yaml format
> >          * method 2: creating a separate meta layer <-- My preference if it gets complex
> 
> Something for later. At this stage, it will only increase the CM effort.
> 
> >          * method 3: using a new image (cip-core-image-security.bb) <-- Current method
> >
> 
> A new image recipe together with a new top-level kas file to select the
> image - and likely more. I can imagine that a secure core image will
> eventually not only affect the image recipe but also configuration
> options of the build, filesystem, secure boot etc. So, something like
> 
>   - kas-cip-core.yml
>   - kas-cip-secure.yml

OK, I suppose that we can start with kas-cip-core.yml and when the need arises add a kas-cip-secure.yml.

> All that said: Nothing needs to be set in stone upfront. We can adjust
> the modeling as the usage evolves and the variants threaten to increase.
> But specifically due to the last aspect, the matrix should remain as
> small as possible.

OK, thanks for your feedback.

Daniel

[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4629): https://lists.cip-project.org/g/cip-dev/message/4629
Mute This Topic: https://lists.cip-project.org/mt/74286250/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [cip-dev][isar-cip-core] Integration of test and security dependencies with cip-core

[Chris Paterson]

[-- Attachment #1: Type: text/plain, Size: 4771 bytes --]

Hello,

> From: daniel.sangorrin@toshiba.co.jp <daniel.sangorrin@toshiba.co.jp>
> Sent: 18 May 2020 07:37
> 
> Hello Dinesh, Chris, Jan:
> 
> # BACKGROUND
> 
> As I mentioned in our last technical steering commite meeting, our gitlab-ci
> scripts should be able to produce multiple OS images. For example, the testing
> team needs to have python and possibly other software including the tests
> themshelves; and the security team needs to have extra packages and probably
> lots of customizations.

Thanks for starting the conversation.

> 
> # CURRENT STATUS
> 
> At the moment we have what I would call "target images", which contain:
> 
> * something close to what I would call the "CIP Core Generic profile":
>     * the ISAR core packages
>         * I think these are basically debootstrap minbase (isar/meta/recipes-
> core/isar-bootstrap)
>     * some extra customizations
>         * https://gitlab.com/cip-project/cip-core/isar-cip-core/-
> /tree/master/recipes-core/
> * target-dependent packages (kernel, u-boot, firmware, etc)
>     * these are added using KAS opt.yaml syntax, instead of using a meta-layer
> * options
>     * opt-rt: will use a kernel with PREEMPT-RT patch
>     * opt-stretch: will use stretch as distro
>     * opt-4.4: will use kernel v4.4 instead of the default 4.10
>     * opt-targz-img: exports the image as a tarball for LAVA
> 
> On the branch, iec-evaluation there is an initial implementation of the security
> image:
>     * https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tree/security/iec-
> evaluation
>     * at first they added an opt-security.yaml file:
>         * https://gitlab.com/cip-project/cip-core/isar-cip-core/-
> /commit/a8216d4ca5eed4d73dff2e00601dea7c9d733f45
>     * then they changed to use recipes-core/images/cip-core-image-security.bb
> that extends IMAGE_PREINSTALL
>         * https://gitlab.com/cip-project/cip-core/isar-cip-core/-
> /commit/3461a50297e370210d76d85d434fb625c8c4248c
>     * see the original thread here:
>         * https://lore.kernel.org/cip-
> dev/TYXPR01MB180817C883F874B321DBA264E1FD0@TYXPR01MB1808.jpnprd
> 01.prod.outlook.com/T/#m752a116d8372222d727722f4fe18ca19d94838eb
> 
> # MY PROPOSAL
> 
> My proposal as the next task for the CIP Core work group is to add metadata for
> releasing these images:
> 
> * target images: isar debootstrap + customizations + kernel/u-boot/fw
>     * [NEW] release them as bmap images for our reference hardware boards
>     * [NEW] create a page (gitlab wiki) that will contain links to the latest images
> and how-to-install readmes for each reference board
>     * [NEW] refer to that page from the CIP wiki page
> (https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/ciprefer
> encehardware)

All +1

> * [NEW] testing images: target images + test dependencies
>     * release them using opt-targz-img so they can be used in LAVA
>     * add the test dependencies
>         * packages: python2.7, python3, ...
>         * tests: LTP, ...
>             * method 1: build them on a separate repo and include in the image
>             * method 2: build them with ISAR (new recipes) and include in the image
>             * method 3: the artifacts are downloaded by LAVA <-- My preference

By "artifacts" do you meant the entire filesystem? Or just individual test packages etc.?

My preference would be for the whole filesystem including the test packages to be built by ISAR, then LAVA just downloads the 'latest' cip-core-test image when running tests.

>         * How to implement this
>             * method 1: using the opt yaml format <-- My preference if we only need
> to specify packages
>             * method 2: creating a separate meta layer
>             * method 3: using a new image (cip-core-image-testing.bb)

As long as the 'standard' cip-core is included/inherited rather than copied I don't mind the method.
This will reduce the maintenance burden.

Kind regards, Chris

> * [NEW] security: target + security packages + security tests and dependencies
>     * release in two formats
>         * using opt-targz-img so they can be used in LAVA
>         * as images for our reference hardware boards
>             * add to the gitlab wiki links to the latest images and how-to-install
> readmes too
>     * How to implement this
>         * method 1: using the opt yaml format
>         * method 2: creating a separate meta layer <-- My preference if it gets
> complex
>         * method 3: using a new image (cip-core-image-security.bb) <-- Current
> method
> 
> # FEEDBACK
> 
> Please check my initial proposal and send me feedback.
> 
> Thanks,
> Daniel Sangorrin
> 
> 
> 


[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4626): https://lists.cip-project.org/g/cip-dev/message/4626
Mute This Topic: https://lists.cip-project.org/mt/74286250/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [cip-dev][isar-cip-core] Integration of test and security dependencies with cip-core

[Quirin Gylstorff]

[-- Attachment #1: Type: text/plain, Size: 5002 bytes --]



On 5/18/20 10:10 AM, Chris Paterson wrote:
> Hello,
> 
>> From: daniel.sangorrin@toshiba.co.jp <daniel.sangorrin@toshiba.co.jp>
>> Sent: 18 May 2020 07:37
>>
>> Hello Dinesh, Chris, Jan:
>>
>> # BACKGROUND
>>
>> As I mentioned in our last technical steering commite meeting, our gitlab-ci
>> scripts should be able to produce multiple OS images. For example, the testing
>> team needs to have python and possibly other software including the tests
>> themshelves; and the security team needs to have extra packages and probably
>> lots of customizations.
> 
> Thanks for starting the conversation.
> 
>>
>> # CURRENT STATUS
>>
>> At the moment we have what I would call "target images", which contain:
>>
>> * something close to what I would call the "CIP Core Generic profile":
>>      * the ISAR core packages
>>          * I think these are basically debootstrap minbase (isar/meta/recipes-
>> core/isar-bootstrap)
>>      * some extra customizations
>>          * https://gitlab.com/cip-project/cip-core/isar-cip-core/-
>> /tree/master/recipes-core/
>> * target-dependent packages (kernel, u-boot, firmware, etc)
>>      * these are added using KAS opt.yaml syntax, instead of using a meta-layer
>> * options
>>      * opt-rt: will use a kernel with PREEMPT-RT patch
>>      * opt-stretch: will use stretch as distro
>>      * opt-4.4: will use kernel v4.4 instead of the default 4.10
>>      * opt-targz-img: exports the image as a tarball for LAVA
>>
>> On the branch, iec-evaluation there is an initial implementation of the security
>> image:
>>      * https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tree/security/iec-
>> evaluation
>>      * at first they added an opt-security.yaml file:
>>          * https://gitlab.com/cip-project/cip-core/isar-cip-core/-
>> /commit/a8216d4ca5eed4d73dff2e00601dea7c9d733f45
>>      * then they changed to use recipes-core/images/cip-core-image-security.bb
>> that extends IMAGE_PREINSTALL
>>          * https://gitlab.com/cip-project/cip-core/isar-cip-core/-
>> /commit/3461a50297e370210d76d85d434fb625c8c4248c
>>      * see the original thread here:
>>          * https://lore.kernel.org/cip-
>> dev/TYXPR01MB180817C883F874B321DBA264E1FD0@TYXPR01MB1808.jpnprd
>> 01.prod.outlook.com/T/#m752a116d8372222d727722f4fe18ca19d94838eb
>>
>> # MY PROPOSAL
>>
>> My proposal as the next task for the CIP Core work group is to add metadata for
>> releasing these images:
>>
>> * target images: isar debootstrap + customizations + kernel/u-boot/fw
>>      * [NEW] release them as bmap images for our reference hardware boards
>>      * [NEW] create a page (gitlab wiki) that will contain links to the latest images
>> and how-to-install readmes for each reference board
>>      * [NEW] refer to that page from the CIP wiki page
>> (https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/ciprefer
>> encehardware)
> 
> All +1
> 
>> * [NEW] testing images: target images + test dependencies
>>      * release them using opt-targz-img so they can be used in LAVA
>>      * add the test dependencies
>>          * packages: python2.7, python3, ...
>>          * tests: LTP, ...
>>              * method 1: build them on a separate repo and include in the image
>>              * method 2: build them with ISAR (new recipes) and include in the image
>>              * method 3: the artifacts are downloaded by LAVA <-- My preference

> 
> By "artifacts" do you meant the entire filesystem? Or just individual test packages etc.?
> 
> My preference would be for the whole filesystem including the test packages to be built by ISAR, then LAVA just downloads the 'latest' cip-core-test image when running tests.
> 

Only as info LTP is part of isar-cip-core in next since commit 
f84a815dc6969eb2b0b276e15c8fce2d52937114


>>          * How to implement this
>>              * method 1: using the opt yaml format <-- My preference if we only need
>> to specify packages
>>              * method 2: creating a separate meta layer
>>              * method 3: using a new image (cip-core-image-testing.bb)
> 
> As long as the 'standard' cip-core is included/inherited rather than copied I don't mind the method.
> This will reduce the maintenance burden.
> 
> Kind regards, Chris
> 
>> * [NEW] security: target + security packages + security tests and dependencies
>>      * release in two formats
>>          * using opt-targz-img so they can be used in LAVA
>>          * as images for our reference hardware boards
>>              * add to the gitlab wiki links to the latest images and how-to-install
>> readmes too
>>      * How to implement this
>>          * method 1: using the opt yaml format
>>          * method 2: creating a separate meta layer <-- My preference if it gets
>> complex
>>          * method 3: using a new image (cip-core-image-security.bb) <-- Current
>> method
>>
>> # FEEDBACK
>>
>> Please check my initial proposal and send me feedback.
>>
>> Thanks,
>> Daniel Sangorrin
>>
>>
>>
> 
> 
> 
> 
Best regards,

-- 
Quirin

[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4627): https://lists.cip-project.org/g/cip-dev/message/4627
Mute This Topic: https://lists.cip-project.org/mt/74286250/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [cip-dev][isar-cip-core] Integration of test and security dependencies with cip-core

[Daniel Sangorrin]

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

> From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Quirin Gylstorff
> > My preference would be for the whole filesystem including the test packages to be built by ISAR, then LAVA just
> downloads the 'latest' cip-core-test image when running tests.
> >
> 
> Only as info LTP is part of isar-cip-core in next since commit
> f84a815dc6969eb2b0b276e15c8fce2d52937114

Thanks for the info, Quirin.

[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4631): https://lists.cip-project.org/g/cip-dev/message/4631
Mute This Topic: https://lists.cip-project.org/mt/74286250/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [cip-dev][isar-cip-core] Integration of test and security dependencies with cip-core

[Daniel Sangorrin]

[-- Attachment #1: Type: text/plain, Size: 2269 bytes --]

Hello Chris, thanks for your feedback. See the comments inline.

> From: Chris Paterson <Chris.Paterson2@renesas.com>
> > * [NEW] testing images: target images + test dependencies
> >     * release them using opt-targz-img so they can be used in LAVA
> >     * add the test dependencies
> >         * packages: python2.7, python3, ...
> >         * tests: LTP, ...
> >             * method 1: build them on a separate repo and include in the image
> >             * method 2: build them with ISAR (new recipes) and include in the image
> >             * method 3: the artifacts are downloaded by LAVA <-- My preference
> 
> By "artifacts" do you meant the entire filesystem? Or just individual test packages etc.?

I meant the individual test binaries/packages. This is the way it's done in Linaro AFAIK.
    * upsides:
        * you only need to store it once, not for every image
        * you only need to download one of the test artifacts per test
            * higher download speeds compared to having to download all tests
            * less space required on the target device (in case of nfs it doesnt matter)
        * you can use simple build scripts on gitlab (no need to create debian recipes)
    * downsides
        * you need to specify the artifacts URL on the test definition or use test definition templates and fill that when you submit a job
        * you need to track more metadata
        * you need extra repositories for building the tests etc..

> My preference would be for the whole filesystem including the test packages to be built by ISAR, then LAVA just
> downloads the 'latest' cip-core-test image when running tests.

OK, thank you. Jan mentioned the need to test manually too, so I guess method 2 is the choice.

> >         * How to implement this
> >             * method 1: using the opt yaml format <-- My preference if we only need
> > to specify packages
> >             * method 2: creating a separate meta layer
> >             * method 3: using a new image (cip-core-image-testing.bb)
> 
> As long as the 'standard' cip-core is included/inherited rather than copied I don't mind the method.
> This will reduce the maintenance burden.

Yes, it is inherited.

Thanks,
Daniel




[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4630): https://lists.cip-project.org/g/cip-dev/message/4630
Mute This Topic: https://lists.cip-project.org/mt/74286250/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [cip-dev][isar-cip-core] Integration of test and security dependencies with cip-core

[Dinesh Kumar]

[-- Attachment #1: Type: text/plain, Size: 6117 bytes --]

Hello Daniel-san

Thanks for bringing this topic as this will help us in many ways such as creating images for various requirements as well as flexibility for customizations.
I have a question, while planning this activity can we define some version for CIP Core itself? As currently we have CIP Kernel versions and versions for individual application packages.
e.g. If we want to share CIP Kernel and CIP Core version for IEC assessment we lack CIP Core version.
May be we can discuss it in upcoming CIP Core meeting.

I have added my comments inline.

Thanks & Regards,
Dinesh Kumar

-----Original Message-----
From: daniel.sangorrin@toshiba.co.jp <daniel.sangorrin@toshiba.co.jp> 
Sent: 18 May 2020 12:07
To: Dinesh Kumar <Dinesh.Kumar@TOSHIBA-TSIP.COM>; jan.kiszka@siemens.com; Chris.Paterson2@renesas.com
Cc: cip-dev@lists.cip-project.org; cip-security@lists.cip-project.org
Subject: [cip-dev][isar-cip-core] Integration of test and security dependencies with cip-core

Hello Dinesh, Chris, Jan:

# BACKGROUND

As I mentioned in our last technical steering commite meeting, our gitlab-ci scripts should be able to produce multiple OS images. For example, the testing team needs to have python and possibly other software including the tests themshelves; and the security team needs to have extra packages and probably lots of customizations.

# CURRENT STATUS

At the moment we have what I would call "target images", which contain:

* something close to what I would call the "CIP Core Generic profile": 
    * the ISAR core packages
        * I think these are basically debootstrap minbase (isar/meta/recipes-core/isar-bootstrap)
    * some extra customizations
        * https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tree/master/recipes-core/
* target-dependent packages (kernel, u-boot, firmware, etc)
    * these are added using KAS opt.yaml syntax, instead of using a meta-layer
* options
    * opt-rt: will use a kernel with PREEMPT-RT patch
    * opt-stretch: will use stretch as distro
    * opt-4.4: will use kernel v4.4 instead of the default 4.10
    * opt-targz-img: exports the image as a tarball for LAVA

On the branch, iec-evaluation there is an initial implementation of the security image:
    * https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tree/security/iec-evaluation
    * at first they added an opt-security.yaml file:
        * https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commit/a8216d4ca5eed4d73dff2e00601dea7c9d733f45
    * then they changed to use recipes-core/images/cip-core-image-security.bb that extends IMAGE_PREINSTALL
        * https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commit/3461a50297e370210d76d85d434fb625c8c4248c
    * see the original thread here:
        * https://lore.kernel.org/cip-dev/TYXPR01MB180817C883F874B321DBA264E1FD0@TYXPR01MB1808.jpnprd01.prod.outlook.com/T/#m752a116d8372222d727722f4fe18ca19d94838eb

# MY PROPOSAL

My proposal as the next task for the CIP Core work group is to add metadata for releasing these images:

* target images: isar debootstrap + customizations + kernel/u-boot/fw
    * [NEW] release them as bmap images for our reference hardware boards
    * [NEW] create a page (gitlab wiki) that will contain links to the latest images and how-to-install readmes for each reference board
    * [NEW] refer to that page from the CIP wiki page (https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/cipreferencehardware)
* [NEW] testing images: target images + test dependencies
    * release them using opt-targz-img so they can be used in LAVA
    * add the test dependencies
        * packages: python2.7, python3, ...
        * tests: LTP, ...
            * method 1: build them on a separate repo and include in the image
            * method 2: build them with ISAR (new recipes) and include in the image
            * method 3: the artifacts are downloaded by LAVA <-- My preference
        * How to implement this
            * method 1: using the opt yaml format <-- My preference if we only need to specify packages
            * method 2: creating a separate meta layer
            * method 3: using a new image (cip-core-image-testing.bb)
* [NEW] security: target + security packages + security tests and dependencies
    * release in two formats
        * using opt-targz-img so they can be used in LAVA
        * as images for our reference hardware boards
            * add to the gitlab wiki links to the latest images and how-to-install readmes too
    * How to implement this
        * method 1: using the opt yaml format
        * method 2: creating a separate meta layer <-- My preference if it gets complex
        * method 3: using a new image (cip-core-image-security.bb) <-- Current method
Dinesh>>I am fine with your current proposal. However, as Jan mentioned in future based on need or shortcomings of above proposal we may have to make changes as required.

# FEEDBACK

Please check my initial proposal and send me feedback.

Thanks,
Daniel Sangorrin




The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.

[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4628): https://lists.cip-project.org/g/cip-dev/message/4628
Mute This Topic: https://lists.cip-project.org/mt/74286250/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-