LXD anyone?

LXD anyone?

[Massimiliano Malisan]

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

Hi all,

is anyone currently working on creating a recipe for LXD?

I have been working on one in the last days but I still have some issues to
have it run properly; being quite new to Yocto I am not sure if they depend
on something in my recipe or some other missing dependency or
configuration, so any other voice is more than welcome.

Cheers,
    Max

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

Re: LXD anyone?

[Bruce Ashfield]

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

On Thu, Apr 20, 2017 at 10:00 AM, Massimiliano Malisan <
max.malisan.uk@gmail.com> wrote:

> Hi all,
>
> is anyone currently working on creating a recipe for LXD?
>

We started creating one about a year ago (and it was discussed, but I can't
find a reference now) .. but that effort never did make it into the tree
and has bit rotted now.

So if you have something underway, and are looking for input, feel free to
post RFC patches and we can see what's working (or not!).

Cheers,

Bruce


>
> I have been working on one in the last days but I still have some issues
> to have it run properly; being quite new to Yocto I am not sure if they
> depend on something in my recipe or some other missing dependency or
> configuration, so any other voice is more than welcome.
>
> Cheers,
>     Max
>
> --
> _______________________________________________
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization
>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

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

Re: LXD anyone?

[Massimiliano Malisan]

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

Hi,

well, it's a bit complicated: being a newbie of both Yocto and go-lang when
I started all this I wasn't aware of the introduction of go in the
openembedded-core meta master (I am using morty). As I couldn't sort out
quickly how to set up the recipe with the meta-virtualization go compiler I
switched all the meta to use meta-golang (quite an easy task), which seemed
to me much more easy to use and directly produced a building tree structure
similar to the one I got from "go get" of LXD source (which I used as a
reference to understand all the package's dependencies and go building
structure).

Besides this:
* I created a bunch of go recipes for all the dependencies (following the
example of docker's recipe dependencies)
* I added and/or updated few other recipes (some are added+updated from
meta-cube)
* I added/changed some system configuration files
* I added some kernel modules - but without a real knowledge of which are
strictly needed: I just checked those needed by docker (using the checking
script from coreos docker's repo -- https://github.com/coreos/d
ocker/blob/master/contrib/check-config.sh) and created corresponding kernel
scc and cfg files (I also updated the docker's ones but this is a
collateral and I don't know if it's needed).

Now I got a bit more insight on the overall process I may try to update the
recipes to use the new go compiler structure (but for the moment I still
need to keep it working for morty.. and I wouldn't like to keep two
different versions of the recipes).

By the way, now LXD seems to be working on my test image; there are still
few thing I have to do manually after the installation (which should be
automatized within the building process and I haven't been able to, yet)
and few "side" things missing:
* I could not build criu (as per previous message to the list) which is
indicated as a tool to be used together with LXD on the build instructions
* I have not been able to use it with apparmor (I didn't manage to build it
from the meta-security)
* In his blog, LXD main developer suggests to use ZFS as ideal container fs
but it's currently missing from Yocto...

If all this seems reasonable (and if you give me some links where to read
how to upload or send the recipes and patches I did) I will be happy to
contribute..

Cheers,
    Max


On 20 April 2017 at 16:10, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:

>
>
> On Thu, Apr 20, 2017 at 10:00 AM, Massimiliano Malisan <
> max.malisan.uk@gmail.com> wrote:
>
>> Hi all,
>>
>> is anyone currently working on creating a recipe for LXD?
>>
>
> We started creating one about a year ago (and it was discussed, but I
> can't find a reference now) .. but that effort never did make it into the
> tree and has bit rotted now.
>
> So if you have something underway, and are looking for input, feel free to
> post RFC patches and we can see what's working (or not!).
>
> Cheers,
>
> Bruce
>
>
>>
>> I have been working on one in the last days but I still have some issues
>> to have it run properly; being quite new to Yocto I am not sure if they
>> depend on something in my recipe or some other missing dependency or
>> configuration, so any other voice is more than welcome.
>>
>> Cheers,
>>     Max
>>
>> --
>> _______________________________________________
>> meta-virtualization mailing list
>> meta-virtualization@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>>
>>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end"
>

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

Re: LXD anyone?

[Bruce Ashfield]

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

On Fri, Apr 21, 2017 at 12:32 PM, Massimiliano Malisan <
max.malisan.uk@gmail.com> wrote:

> Hi,
>
> well, it's a bit complicated: being a newbie of both Yocto and go-lang
> when I started all this I wasn't aware of the introduction of go in the
> openembedded-core meta master (I am using morty). As I couldn't sort out
> quickly how to set up the recipe with the meta-virtualization go compiler I
> switched all the meta to use meta-golang (quite an easy task), which seemed
> to me much more easy to use and directly produced a building tree structure
> similar to the one I got from "go get" of LXD source (which I used as a
> reference to understand all the package's dependencies and go building
> structure).
>

I'm not so concerned about the variant of the go compiler used to build, as
long
as you found something that worked, it is something that we can merge.

But yes, anything we merge now should work with oe-core's go variant, since
that
is what we are standardizing on.


>
> Besides this:
> * I created a bunch of go recipes for all the dependencies (following the
> example of docker's recipe dependencies)
>

These can be submitted to meta-virt, but packaging too many support packages
isn't necessarily the right thing, since they can conflict with other go
packages that
need a similar dependency, but on another version.

The technique that I've been using to deal with this lately is to put
multiple upstream
repos on the SRC_URI and allow the fetcher to pull them into the SRC
directory, and
have them available to the build.

i.e. look at what I did for libnetwork in docker, you can do something
similar per-dependency
and use destsuffix= to get them in the right place (i.e. destsuffix=git/src/
github.com/openSUSE/umoci)


> * I added and/or updated few other recipes (some are added+updated from
> meta-cube)
>

These can be sent here, or sent as a pull request on the OverC github
pages, if you send
them here, make sure to have [meta-cube] in the subject. Or go right for
the github pull
request.


> * I added/changed some system configuration files
>

We'd have to look at those closely, system level config is something that
either needs to
be controlled by packageconfigs, or is a distro policy. So they may not be
something
that you need to send at all.


> * I added some kernel modules - but without a real knowledge of which are
> strictly needed: I just checked those needed by docker (using the checking
> script from coreos docker's repo -- https://github.com/coreos/d
> ocker/blob/master/contrib/check-config.sh) and created corresponding
> kernel scc and cfg files (I also updated the docker's ones but this is a
> collateral and I don't know if it's needed).
>

That would be fine, following what we do for docker makes sense.


>
> Now I got a bit more insight on the overall process I may try to update
> the recipes to use the new go compiler structure (but for the moment I
> still need to keep it working for morty.. and I wouldn't like to keep two
> different versions of the recipes).
>
> By the way, now LXD seems to be working on my test image; there are still
> few thing I have to do manually after the installation (which should be
> automatized within the building process and I haven't been able to, yet)
> and few "side" things missing:
> * I could not build criu (as per previous message to the list) which is
> indicated as a tool to be used together with LXD on the build instructions
>

unless you are doing container migration or snapshots, you can ignore it,
and even make
it an optional dependency.


> * I have not been able to use it with apparmor (I didn't manage to build
> it from the meta-security)
>

this would be optional anyway, apparmor is a distro type config, and
building it in, or out, of
LXD would be a packageconfig or distro feature.


> * In his blog, LXD main developer suggests to use ZFS as ideal container
> fs but it's currently missing from Yocto...
>

I wouldn't worry about this either, we can't dictate the FS that people
use, so the recipes need
to be generic and that's up to the distro or image assembler.


>
> If all this seems reasonable (and if you give me some links where to read
> how to upload or send the recipes and patches I did) I will be happy to
> contribute..
>
>
See above. You can send them via git send-email, or github pull requests.
Instructions on how to
send the patches should be in the README of meta-virt.

Cheers,

Bruce


> Cheers,
>     Max
>
>
> On 20 April 2017 at 16:10, Bruce Ashfield <bruce.ashfield@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Apr 20, 2017 at 10:00 AM, Massimiliano Malisan <
>> max.malisan.uk@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> is anyone currently working on creating a recipe for LXD?
>>>
>>
>> We started creating one about a year ago (and it was discussed, but I
>> can't find a reference now) .. but that effort never did make it into the
>> tree and has bit rotted now.
>>
>> So if you have something underway, and are looking for input, feel free
>> to post RFC patches and we can see what's working (or not!).
>>
>> Cheers,
>>
>> Bruce
>>
>>
>>>
>>> I have been working on one in the last days but I still have some issues
>>> to have it run properly; being quite new to Yocto I am not sure if they
>>> depend on something in my recipe or some other missing dependency or
>>> configuration, so any other voice is more than welcome.
>>>
>>> Cheers,
>>>     Max
>>>
>>> --
>>> _______________________________________________
>>> meta-virtualization mailing list
>>> meta-virtualization@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>>>
>>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee
>> at its end"
>>
>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

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

Re: LXD anyone?

[Massimiliano Malisan]

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

On 21 April 2017 at 19:03, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:

>
>
> On Fri, Apr 21, 2017 at 12:32 PM, Massimiliano Malisan <
> max.malisan.uk@gmail.com> wrote:
>
>> Hi,
>>
>> well, it's a bit complicated: being a newbie of both Yocto and go-lang
>> when I started all this I wasn't aware of the introduction of go in the
>> openembedded-core meta master (I am using morty). As I couldn't sort out
>> quickly how to set up the recipe with the meta-virtualization go compiler I
>> switched all the meta to use meta-golang (quite an easy task), which seemed
>> to me much more easy to use and directly produced a building tree structure
>> similar to the one I got from "go get" of LXD source (which I used as a
>> reference to understand all the package's dependencies and go building
>> structure).
>>
>
> I'm not so concerned about the variant of the go compiler used to build,
> as long
> as you found something that worked, it is something that we can merge.
>
> But yes, anything we merge now should work with oe-core's go variant,
> since that
> is what we are standardizing on.
>

Is the current/future standard the version in openembedded-core/meta or the
one addressed in meta-virtualization README (git://
github.com/errordeveloper/oe-meta-go.git -- maybe superseded by
github.com/mem/oe-meta-go)?

As I see some work to be done here (I have to switch all my repos to the
master branch to do everything in a coherent environment), would it be fine
if submit now the morty version and in the next future the master-compliant
one?


>
>> Besides this:
>> * I created a bunch of go recipes for all the dependencies (following the
>> example of docker's recipe dependencies)
>>
>
> These can be submitted to meta-virt, but packaging too many support
> packages
> isn't necessarily the right thing, since they can conflict with other go
> packages that
> need a similar dependency, but on another version.
>
> The technique that I've been using to deal with this lately is to put
> multiple upstream
> repos on the SRC_URI and allow the fetcher to pull them into the SRC
> directory, and
> have them available to the build.
>
> i.e. look at what I did for libnetwork in docker, you can do something
> similar per-dependency
> and use destsuffix= to get them in the right place (i.e.
> destsuffix=git/src/github.com/openSUSE/umoci)
>

I see the point here, as I had started from morty versions I missed this
approach; I just have to check if everything runs with this approach as
some dependencies are taken from gopkg.in which is a kind of versioned git
repository.. (but then, maybe, those can be kept as standalone recipes)



> * I added and/or updated few other recipes (some are added+updated from
>> meta-cube)
>>
>
> These can be sent here, or sent as a pull request on the OverC github
> pages, if you send
> them here, make sure to have [meta-cube] in the subject. Or go right for
> the github pull
> request.
>

I think they are more appropriate here; just not to drag in another (almost
unrelated) layer.


> * I added/changed some system configuration files
>>
>
> We'd have to look at those closely, system level config is something that
> either needs to
> be controlled by packageconfigs, or is a distro policy. So they may not be
> something
> that you need to send at all.
>

Some are the various init config files (I tested the systemd one and
quickly the sysvinit one) and most important one is the dnsmasq.conf, which
locally (due to a meta-virt append) conflicts with a LXD dnsmasq setting
taken from (again) the Ubuntu install package


>
> * I added some kernel modules - but without a real knowledge of which are
>> strictly needed: I just checked those needed by docker (using the checking
>> script from coreos docker's repo -- https://github.com/coreos/d
>> ocker/blob/master/contrib/check-config.sh) and created corresponding
>> kernel scc and cfg files (I also updated the docker's ones but this is a
>> collateral and I don't know if it's needed).
>>
>
> That would be fine, following what we do for docker makes sense.
>

My only concert is that I may have added some unnecessary kernel
configurations here


>
>> Now I got a bit more insight on the overall process I may try to update
>> the recipes to use the new go compiler structure (but for the moment I
>> still need to keep it working for morty.. and I wouldn't like to keep two
>> different versions of the recipes).
>>
>> By the way, now LXD seems to be working on my test image; there are still
>> few thing I have to do manually after the installation (which should be
>> automatized within the building process and I haven't been able to, yet)
>> and few "side" things missing:
>> * I could not build criu (as per previous message to the list) which is
>> indicated as a tool to be used together with LXD on the build instructions
>>
>
> unless you are doing container migration or snapshots, you can ignore it,
> and even make
> it an optional dependency.
>
>
>> * I have not been able to use it with apparmor (I didn't manage to build
>> it from the meta-security)
>>
>
> this would be optional anyway, apparmor is a distro type config, and
> building it in, or out, of
> LXD would be a packageconfig or distro feature.
>
>
>> * In his blog, LXD main developer suggests to use ZFS as ideal container
>> fs but it's currently missing from Yocto...
>>
>
> I wouldn't worry about this either, we can't dictate the FS that people
> use, so the recipes need
> to be generic and that's up to the distro or image assembler.
>

Yes, I named the above as "side" missing parts as I know they are not
strictly necessary but it was to clarify that atm this package is not as
complete as an Ubuntu user may expect it to be.

If is ok that I start with the morty packages, I will submit the pull
requests in the next few days and then look after the master recipes after
that.

Cheers,
    Max

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

Re: LXD anyone?

[Bruce Ashfield]

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

On Tue, Apr 25, 2017 at 3:56 AM, Massimiliano Malisan <
max.malisan.uk@gmail.com> wrote:

>
>
> On 21 April 2017 at 19:03, Bruce Ashfield <bruce.ashfield@gmail.com>
> wrote:
>
>>
>>
>> On Fri, Apr 21, 2017 at 12:32 PM, Massimiliano Malisan <
>> max.malisan.uk@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> well, it's a bit complicated: being a newbie of both Yocto and go-lang
>>> when I started all this I wasn't aware of the introduction of go in the
>>> openembedded-core meta master (I am using morty). As I couldn't sort out
>>> quickly how to set up the recipe with the meta-virtualization go compiler I
>>> switched all the meta to use meta-golang (quite an easy task), which seemed
>>> to me much more easy to use and directly produced a building tree structure
>>> similar to the one I got from "go get" of LXD source (which I used as a
>>> reference to understand all the package's dependencies and go building
>>> structure).
>>>
>>
>> I'm not so concerned about the variant of the go compiler used to build,
>> as long
>> as you found something that worked, it is something that we can merge.
>>
>> But yes, anything we merge now should work with oe-core's go variant,
>> since that
>> is what we are standardizing on.
>>
>
> Is the current/future standard the version in openembedded-core/meta or
> the one addressed in meta-virtualization README (git://github.com/error
> developer/oe-meta-go.git -- maybe superseded by github.com/mem/oe-meta-go
> )?
>

oe-core/meta is where standardization is happening.


>
> As I see some work to be done here (I have to switch all my repos to the
> master branch to do everything in a coherent environment), would it be fine
> if submit now the morty version and in the next future the master-compliant
> one?
>
>
>>
>>> Besides this:
>>> * I created a bunch of go recipes for all the dependencies (following
>>> the example of docker's recipe dependencies)
>>>
>>
>> These can be submitted to meta-virt, but packaging too many support
>> packages
>> isn't necessarily the right thing, since they can conflict with other go
>> packages that
>> need a similar dependency, but on another version.
>>
>> The technique that I've been using to deal with this lately is to put
>> multiple upstream
>> repos on the SRC_URI and allow the fetcher to pull them into the SRC
>> directory, and
>> have them available to the build.
>>
>> i.e. look at what I did for libnetwork in docker, you can do something
>> similar per-dependency
>> and use destsuffix= to get them in the right place (i.e.
>> destsuffix=git/src/github.com/openSUSE/umoci)
>>
>
> I see the point here, as I had started from morty versions I missed this
> approach; I just have to check if everything runs with this approach as
> some dependencies are taken from gopkg.in which is a kind of versioned
> git repository.. (but then, maybe, those can be kept as standalone recipes)
>

Some runtime dependencies and other support applications do make sense as
separate
packages, but when something is being pulled in to simply process command
line args, it
really doesn't make sense as a separate package. It just needs to be around
for the build
and then it is removed.


>
>
>
>> * I added and/or updated few other recipes (some are added+updated from
>>> meta-cube)
>>>
>>
>> These can be sent here, or sent as a pull request on the OverC github
>> pages, if you send
>> them here, make sure to have [meta-cube] in the subject. Or go right for
>> the github pull
>> request.
>>
>
> I think they are more appropriate here; just not to drag in another
> (almost unrelated) layer.
>

Sounds good. We can take them on a case by case basis. i.e. I'd rather not
move recipes
from between layers, but update them where they currently are. But
broadcasting the
work to this list definitely works.


>
>
>> * I added/changed some system configuration files
>>>
>>
>> We'd have to look at those closely, system level config is something that
>> either needs to
>> be controlled by packageconfigs, or is a distro policy. So they may not
>> be something
>> that you need to send at all.
>>
>
> Some are the various init config files (I tested the systemd one and
> quickly the sysvinit one) and most important one is the dnsmasq.conf, which
> locally (due to a meta-virt append) conflicts with a LXD dnsmasq setting
> taken from (again) the Ubuntu install package
>

Everyone (people and packages) love to poke with dnsmasq. Mark Asselstine
sent
changes to meta-oe that enabled the use of the dnsmasq.d configuration
directory
versus everything needing to modify dnsmasq.conf directly.

Regardless, we'd have to look at those changes carefully since there's no
one right
configuration for dnsmasq.

For init system files, they shouldn't be an issue.


>
>
>>
>> * I added some kernel modules - but without a real knowledge of which are
>>> strictly needed: I just checked those needed by docker (using the checking
>>> script from coreos docker's repo -- https://github.com/coreos/d
>>> ocker/blob/master/contrib/check-config.sh) and created corresponding
>>> kernel scc and cfg files (I also updated the docker's ones but this is a
>>> collateral and I don't know if it's needed).
>>>
>>
>> That would be fine, following what we do for docker makes sense.
>>
>
> My only concert is that I may have added some unnecessary kernel
> configurations here
>

When I see the patch, I can comment further.


>
>
>>
>>> Now I got a bit more insight on the overall process I may try to update
>>> the recipes to use the new go compiler structure (but for the moment I
>>> still need to keep it working for morty.. and I wouldn't like to keep two
>>> different versions of the recipes).
>>>
>>> By the way, now LXD seems to be working on my test image; there are
>>> still few thing I have to do manually after the installation (which should
>>> be automatized within the building process and I haven't been able to, yet)
>>> and few "side" things missing:
>>> * I could not build criu (as per previous message to the list) which is
>>> indicated as a tool to be used together with LXD on the build instructions
>>>
>>
>> unless you are doing container migration or snapshots, you can ignore it,
>> and even make
>> it an optional dependency.
>>
>>
>>> * I have not been able to use it with apparmor (I didn't manage to build
>>> it from the meta-security)
>>>
>>
>> this would be optional anyway, apparmor is a distro type config, and
>> building it in, or out, of
>> LXD would be a packageconfig or distro feature.
>>
>>
>>> * In his blog, LXD main developer suggests to use ZFS as ideal container
>>> fs but it's currently missing from Yocto...
>>>
>>
>> I wouldn't worry about this either, we can't dictate the FS that people
>> use, so the recipes need
>> to be generic and that's up to the distro or image assembler.
>>
>
> Yes, I named the above as "side" missing parts as I know they are not
> strictly necessary but it was to clarify that atm this package is not as
> complete as an Ubuntu user may expect it to be.
>
> If is ok that I start with the morty packages, I will submit the pull
> requests in the next few days and then look after the master recipes after
> that.
>

Sounds ok to me.

Bruce


>
> Cheers,
>     Max
>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

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