Introducing chroot tasks

Introducing chroot tasks

[Ben Brenson]

[-- Attachment #1.1: Type: text/plain, Size: 964 bytes --]

Hi,

I want to submit some patches for defining and running chroot tasks within 
bitbake recipes.
The following short example should show what I mean:

Exampe recipe.bb:

do_foo() {
    # Do something within chroot
}
do_foo[chroot] = "1"
do_foo[id] = "${BUILDCHROOT_ID}"
addtask do_foo after ... before ... 


By setting the chroot flag the task automatically will be executed within 
the chroot specified by the id flag.
My isar (https://github.com/benbrenson/isar) fork already supports this 
feature, by using schroot.

This will give much more flexibility and modularity to Isar. You will be 
able to append/prepend things to those tasks
between layers easily.

I have already seen, that there is another and better approach than schroot 
-> proot.
I saw Alexander has already experimented with this feature, which seems to 
work.

So before posting some patches here, maybe changing this feature to proot 
first would a better first-step?


Regards,
Benedikt

[-- Attachment #1.2: Type: text/html, Size: 1091 bytes --]

Re: Introducing chroot tasks

[Claudius Heine]

Hi Ben,

On 10/19/2017 10:38 AM, 'Ben Brenson' via isar-users wrote:
> Hi,
> 
> I want to submit some patches for defining and running chroot tasks within
> bitbake recipes.
> The following short example should show what I mean:
> 
> Exampe recipe.bb:
> 
> do_foo() {
>      # Do something within chroot
> }
> do_foo[chroot] = "1"
> do_foo[id] = "${BUILDCHROOT_ID}"
> addtask do_foo after ... before ...
> 
> 
> By setting the chroot flag the task automatically will be executed within
> the chroot specified by the id flag.
> My isar (https://github.com/benbrenson/isar) fork already supports this
> feature, by using schroot.
> 
> This will give much more flexibility and modularity to Isar. You will be
> able to append/prepend things to those tasks
> between layers easily.
> 
> I have already seen, that there is another and better approach than schroot
> -> proot.
> I saw Alexander has already experimented with this feature, which seems to
> work.
> 
> So before posting some patches here, maybe changing this feature to proot
> first would a better first-step?

Yes. Since proot solves some more problems than schroot.

Your implementation requires patching the bitbake code, so maybe we 
should try to get those changes upstream to bitbake?

Isar has currently has no own changes to upstream bitbake and I am not 
in favor of forking bitbake.

Claudius

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

Re: Introducing chroot tasks

[Jan Kiszka]

On 2017-10-19 11:01, [ext] Claudius Heine wrote:
> Hi Ben,
> 
> On 10/19/2017 10:38 AM, 'Ben Brenson' via isar-users wrote:
>> Hi,
>>
>> I want to submit some patches for defining and running chroot tasks
>> within
>> bitbake recipes.
>> The following short example should show what I mean:
>>
>> Exampe recipe.bb:
>>
>> do_foo() {
>>      # Do something within chroot
>> }
>> do_foo[chroot] = "1"
>> do_foo[id] = "${BUILDCHROOT_ID}"
>> addtask do_foo after ... before ...
>>
>>
>> By setting the chroot flag the task automatically will be executed within
>> the chroot specified by the id flag.
>> My isar (https://github.com/benbrenson/isar) fork already supports this
>> feature, by using schroot.
>>
>> This will give much more flexibility and modularity to Isar. You will be
>> able to append/prepend things to those tasks
>> between layers easily.
>>
>> I have already seen, that there is another and better approach than
>> schroot
>> -> proot.
>> I saw Alexander has already experimented with this feature, which
>> seems to
>> work.
>>
>> So before posting some patches here, maybe changing this feature to proot
>> first would a better first-step?
> 
> Yes. Since proot solves some more problems than schroot.
> 
> Your implementation requires patching the bitbake code, so maybe we
> should try to get those changes upstream to bitbake?
> 
> Isar has currently has no own changes to upstream bitbake and I am not
> in favor of forking bitbake.

I think we should go for the most promising candidate of the chroot
solutions for upstream and, if that fails, fall back to VMs. Whenn all
our forces are joined on this topic now, we should be able to come to an
answer quickly.

Jan

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

Re: Introducing chroot tasks

[Henning Schild]

On Thu, 19 Oct 2017 11:01:28 +0200
"[ext] Claudius Heine" <claudius.heine.ext@siemens.com> wrote:

> Hi Ben,
> 
> On 10/19/2017 10:38 AM, 'Ben Brenson' via isar-users wrote:
> > Hi,
> > 
> > I want to submit some patches for defining and running chroot tasks
> > within bitbake recipes.
> > The following short example should show what I mean:
> > 
> > Exampe recipe.bb:
> > 
> > do_foo() {
> >      # Do something within chroot
> > }
> > do_foo[chroot] = "1"
> > do_foo[id] = "${BUILDCHROOT_ID}"
> > addtask do_foo after ... before ...
> > 
> > 
> > By setting the chroot flag the task automatically will be executed
> > within the chroot specified by the id flag.
> > My isar (https://github.com/benbrenson/isar) fork already supports
> > this feature, by using schroot.
> > 
> > This will give much more flexibility and modularity to Isar. You
> > will be able to append/prepend things to those tasks
> > between layers easily.
> > 
> > I have already seen, that there is another and better approach than
> > schroot -> proot.  
> > I saw Alexander has already experimented with this feature, which
> > seems to work.
> > 
> > So before posting some patches here, maybe changing this feature to
> > proot first would a better first-step?  
> 
> Yes. Since proot solves some more problems than schroot.
> 
> Your implementation requires patching the bitbake code, so maybe we 
> should try to get those changes upstream to bitbake?

IMHO, touching our copy of bitbake is an absolute NoGo! Such changes
need to go upstream first.

Henning

> Isar has currently has no own changes to upstream bitbake and I am
> not in favor of forking bitbake.
> 
> Claudius
> 

Re: Introducing chroot tasks

[Ben Brenson]

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

Yeah I know, but using chroot tasks was never a use case for bitbake and
maybe will never be, I think.
I've never thought about using chroot tasks when running Yocto builds, but
that has changed very fast when switching to Isar.
So maybe within Isar we have a more reasoned use case for chroot tasks, and
if this feature works in isar, may be I have more chances to get those
changes upstream to bitbake?

I can try to get those changes upstream first....

Regards,
Benedikt





2017-10-19 11:15 GMT+02:00 Henning Schild <henning.schild@siemens.com>:

> On Thu, 19 Oct 2017 11:01:28 +0200
> "[ext] Claudius Heine" <claudius.heine.ext@siemens.com> wrote:
>
> > Hi Ben,
> >
> > On 10/19/2017 10:38 AM, 'Ben Brenson' via isar-users wrote:
> > > Hi,
> > >
> > > I want to submit some patches for defining and running chroot tasks
> > > within bitbake recipes.
> > > The following short example should show what I mean:
> > >
> > > Exampe recipe.bb:
> > >
> > > do_foo() {
> > >      # Do something within chroot
> > > }
> > > do_foo[chroot] = "1"
> > > do_foo[id] = "${BUILDCHROOT_ID}"
> > > addtask do_foo after ... before ...
> > >
> > >
> > > By setting the chroot flag the task automatically will be executed
> > > within the chroot specified by the id flag.
> > > My isar (https://github.com/benbrenson/isar) fork already supports
> > > this feature, by using schroot.
> > >
> > > This will give much more flexibility and modularity to Isar. You
> > > will be able to append/prepend things to those tasks
> > > between layers easily.
> > >
> > > I have already seen, that there is another and better approach than
> > > schroot -> proot.
> > > I saw Alexander has already experimented with this feature, which
> > > seems to work.
> > >
> > > So before posting some patches here, maybe changing this feature to
> > > proot first would a better first-step?
> >
> > Yes. Since proot solves some more problems than schroot.
> >
> > Your implementation requires patching the bitbake code, so maybe we
> > should try to get those changes upstream to bitbake?
>
> IMHO, touching our copy of bitbake is an absolute NoGo! Such changes
> need to go upstream first.
>
> Henning
>
> > Isar has currently has no own changes to upstream bitbake and I am
> > not in favor of forking bitbake.
> >
> > Claudius
> >
>
>

[-- Attachment #2: Type: text/html, Size: 3769 bytes --]

Re: Introducing chroot tasks

[Claudius Heine]

Hi,

On 10/19/2017 12:24 PM, Ben Brenson wrote:
> 2017-10-19 11:15 GMT+02:00 Henning Schild <henning.schild@siemens.com>:
> 
>> On Thu, 19 Oct 2017 11:01:28 +0200
>> "[ext] Claudius Heine" <claudius.heine.ext@siemens.com> wrote:
>>
>>> Hi Ben,
>>>
>>> On 10/19/2017 10:38 AM, 'Ben Brenson' via isar-users wrote:
>>>> Hi,
>>>>
>>>> I want to submit some patches for defining and running chroot tasks
>>>> within bitbake recipes.
>>>> The following short example should show what I mean:
>>>>
>>>> Exampe recipe.bb:
>>>>
>>>> do_foo() {
>>>>       # Do something within chroot
>>>> }
>>>> do_foo[chroot] = "1"
>>>> do_foo[id] = "${BUILDCHROOT_ID}"
>>>> addtask do_foo after ... before ...
>>>>
>>>>
>>>> By setting the chroot flag the task automatically will be executed
>>>> within the chroot specified by the id flag.
>>>> My isar (https://github.com/benbrenson/isar) fork already supports
>>>> this feature, by using schroot.
>>>>
>>>> This will give much more flexibility and modularity to Isar. You
>>>> will be able to append/prepend things to those tasks
>>>> between layers easily.
>>>>
>>>> I have already seen, that there is another and better approach than
>>>> schroot -> proot.
>>>> I saw Alexander has already experimented with this feature, which
>>>> seems to work.
>>>>
>>>> So before posting some patches here, maybe changing this feature to
>>>> proot first would a better first-step?
>>>
>>> Yes. Since proot solves some more problems than schroot.
>>>
>>> Your implementation requires patching the bitbake code, so maybe we
>>> should try to get those changes upstream to bitbake?
>>
>> IMHO, touching our copy of bitbake is an absolute NoGo! Such changes
>> need to go upstream first.
 >>
> Yeah I know, but using chroot tasks was never a use case for bitbake and
> maybe will never be, I think.
> I've never thought about using chroot tasks when running Yocto builds, but
> that has changed very fast when switching to Isar.
> So maybe within Isar we have a more reasoned use case for chroot tasks, and
> if this feature works in isar, may be I have more chances to get those
> changes upstream to bitbake?
> 
> I can try to get those changes upstream first....

A version that is independent of the chroot implementation might be more 
useful upstream maybe. Call it a 'execution context' then you can 
specify if a specific task should be run in a chroot environment, in a 
ssh shell. Some repl or a programming language or the serial tty session 
might a bit to much though but maybe possible.

Cheers,
Claudius

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

Re: Introducing chroot tasks

[Ben Brenson]

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

In my opinion I think when introducing these feature, this may change
Isars' architecture and further development.
Maybe no scripts are copied into the chroot and executed inside it anymore.

Instead those taks (setupscript.sh, build.sh, setup.sh) will directly be
defined within the recipes.
That would gave us the possibility of reusing all parts of the core isar
layer and also overwrite them if needed.

I think, creating scripts copying them somewhere and then execute them, is
not for what bitbake was made for.
It's much more powerfull and we should make use of it.

So when it is possible to integrate this feature, we should think about of
integrating it know.

Maybe we can patch those 100 lines of code, a try to get it upstream
meanwhile.


Regards,
Benedikt



2017-10-19 14:00 GMT+02:00 Claudius Heine <claudius.heine.ext@siemens.com>:

> Hi,
>
>
> On 10/19/2017 12:24 PM, Ben Brenson wrote:
>
>> 2017-10-19 11:15 GMT+02:00 Henning Schild <henning.schild@siemens.com>:
>>
>> On Thu, 19 Oct 2017 11:01:28 +0200
>>> "[ext] Claudius Heine" <claudius.heine.ext@siemens.com> wrote:
>>>
>>> Hi Ben,
>>>>
>>>> On 10/19/2017 10:38 AM, 'Ben Brenson' via isar-users wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I want to submit some patches for defining and running chroot tasks
>>>>> within bitbake recipes.
>>>>> The following short example should show what I mean:
>>>>>
>>>>> Exampe recipe.bb:
>>>>>
>>>>> do_foo() {
>>>>>       # Do something within chroot
>>>>> }
>>>>> do_foo[chroot] = "1"
>>>>> do_foo[id] = "${BUILDCHROOT_ID}"
>>>>> addtask do_foo after ... before ...
>>>>>
>>>>>
>>>>> By setting the chroot flag the task automatically will be executed
>>>>> within the chroot specified by the id flag.
>>>>> My isar (https://github.com/benbrenson/isar) fork already supports
>>>>> this feature, by using schroot.
>>>>>
>>>>> This will give much more flexibility and modularity to Isar. You
>>>>> will be able to append/prepend things to those tasks
>>>>> between layers easily.
>>>>>
>>>>> I have already seen, that there is another and better approach than
>>>>> schroot -> proot.
>>>>> I saw Alexander has already experimented with this feature, which
>>>>> seems to work.
>>>>>
>>>>> So before posting some patches here, maybe changing this feature to
>>>>> proot first would a better first-step?
>>>>>
>>>>
>>>> Yes. Since proot solves some more problems than schroot.
>>>>
>>>> Your implementation requires patching the bitbake code, so maybe we
>>>> should try to get those changes upstream to bitbake?
>>>>
>>>
>>> IMHO, touching our copy of bitbake is an absolute NoGo! Such changes
>>> need to go upstream first.
>>>
>> >>
>
>> Yeah I know, but using chroot tasks was never a use case for bitbake and
>> maybe will never be, I think.
>> I've never thought about using chroot tasks when running Yocto builds, but
>> that has changed very fast when switching to Isar.
>> So maybe within Isar we have a more reasoned use case for chroot tasks,
>> and
>> if this feature works in isar, may be I have more chances to get those
>> changes upstream to bitbake?
>>
>> I can try to get those changes upstream first....
>>
>
> A version that is independent of the chroot implementation might be more
> useful upstream maybe. Call it a 'execution context' then you can specify
> if a specific task should be run in a chroot environment, in a ssh shell.
> Some repl or a programming language or the serial tty session might a bit
> to much though but maybe possible.
>
> Cheers,
>
> Claudius
>
> --
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de
>

[-- Attachment #2: Type: text/html, Size: 5509 bytes --]

Re: Introducing chroot tasks

[Henning Schild]

On Thu, 19 Oct 2017 01:38:48 -0700
'Ben Brenson' via isar-users <isar-users@googlegroups.com> wrote:

> Hi,
> 
> I want to submit some patches for defining and running chroot tasks
> within bitbake recipes.
> The following short example should show what I mean:
> 
> Exampe recipe.bb:
> 
> do_foo() {
>     # Do something within chroot
> }
> do_foo[chroot] = "1"
> do_foo[id] = "${BUILDCHROOT_ID}"

/id/chrootdir/ ?

> addtask do_foo after ... before ... 
> 
> 
> By setting the chroot flag the task automatically will be executed
> within the chroot specified by the id flag.
> My isar (https://github.com/benbrenson/isar) fork already supports
> this feature, by using schroot.
> 
> This will give much more flexibility and modularity to Isar. You will
> be able to append/prepend things to those tasks
> between layers easily.

One key feature i see here would be automatic cleanup if things go
wrong. At the moment we still have the case where umounts will not get
executed if tasks fail.

> I have already seen, that there is another and better approach than
> schroot -> proot.  
> I saw Alexander has already experimented with this feature, which
> seems to work.
>
> So before posting some patches here, maybe changing this feature to
> proot first would a better first-step?

You should talk to Alex before duplicating work. He is mostly
interested in getting rid of sudo, while your focus is a different one.
But you will have to touch the same code which suggests to serialize
the work.

Maybe you have other features in your fork that you can present before
the chroot-feature?

Henning

> 
> Regards,
> Benedikt
> 

Re: Introducing chroot tasks

[Henning Schild]

On Thu, 19 Oct 2017 01:38:48 -0700
'Ben Brenson' via isar-users <isar-users@googlegroups.com> wrote:

> Hi,
> 
> I want to submit some patches for defining and running chroot tasks
> within bitbake recipes.
> The following short example should show what I mean:
> 
> Exampe recipe.bb:
> 
> do_foo() {
>     # Do something within chroot
> }
> do_foo[chroot] = "1"
> do_foo[id] = "${BUILDCHROOT_ID}"

/id/chrootdir/ ?

> addtask do_foo after ... before ... 
> 
> 
> By setting the chroot flag the task automatically will be executed
> within the chroot specified by the id flag.
> My isar (https://github.com/benbrenson/isar) fork already supports
> this feature, by using schroot.
> 
> This will give much more flexibility and modularity to Isar. You will
> be able to append/prepend things to those tasks
> between layers easily.

One key feature i see here would be automatic cleanup if things go
wrong. At the moment we still have the case where umounts will not get
executed if tasks fail.

> I have already seen, that there is another and better approach than
> schroot -> proot.  
> I saw Alexander has already experimented with this feature, which
> seems to work.
>
> So before posting some patches here, maybe changing this feature to
> proot first would a better first-step?

You should talk to Alex before duplicating work. He is mostly
interested in getting rid of sudo, while your focus is a different one.
But you will have to touch the same code which suggests to serialize
the work.

Maybe you have other features in your fork that you can present before
the chroot-feature?

Henning

> 
> Regards,
> Benedikt
> 

Introducing chroot tasks

[Benedikt Niedermayr]

Hello,

i have now a running example with non-root chroot tasks as well as 
non-root multistrap build at https://github.com/benbrenson/isar.

The feature is implemented on the "proot" branch.

I have tested successfully a complete build! So it seems, proot is a 
serious solution.

So I will try to integrate that into upstream and send you some patches.


Regards,

Benedikt