canonical-ci-engineering team mailing list archive

[Ricardo Salveti de Araujo <ricardo.salveti@xxxxxxxxxxxxx>]

Hey,

On Wed, May 13, 2015 at 9:02 AM, Ursula Junque
<ursula.junque@xxxxxxxxxxxxx> wrote:
> Hi all,
> On Wed, May 13, 2015 at 8:01 AM, Sergio Schvezov
> <sergio.schvezov@xxxxxxxxxxxxx> wrote:
>>
>> On Wed, May 13, 2015 at 06:09:01PM +1200, Thomi Richards wrote:
>> > Hi Sergio,
>> >
>> >
>> > I tried to get hold of you on IRC today, but I guess I must have missed
>> > you.
>>
>> It's because I am off this week ;-)
>>
>> > The CI team need a way to generate a snappy image with one or more
>> > additional debian packages applied.
>> >
>> > Our current approach is to regenerate the rootfs tarball for the latest
>> > image, mount it in a chroot, install the new packages, unmount it, and
>> > then
>> > (hopefully) pass that modified rootfs tarball to u-d-f and have it
>> > generate
>> > an image based on our modified tarball, rather than the one downloaded
>> > from
>> > the image server.
>> >
>> > I've had a look at the source code today for u-d-f (BTW, trunk FTBFS, as
>> > lp:snappy/progress API seems to have made backwards-incompatible
>> > changes),
>> > and this doesn't seem like it would be very difficult, but there's
>> > enough
>> > alien code in there that I'm not confident enough to do it myself.
>>
>> Will fix when I get back (the new incarnation of u-d-f is moving into
>> snappy itself fwiw).
>>
>> > Do you think this is a plausible / sane approach?
>>
>> It would of been before the plan to move the rootfs to a snappy package.
>>
>> Even though we use debs to build the image today, we might not in the
>> future.

Even after we move the rootfs to a snappy package, it will still be
created from the archive (using similar methods). As Sergio said, this
might change later on, but we still need to discuss that better (and
build a proper plan for it).

>> Do you need debs btw? Isn't it possible to solve your problems by creating
>> a snappy framework package?

I'd like us to try to simulate the same logic that gets applied when
building the original rootfs, so we can test similar artifacts.

> I like this conversation already. :)
>
>> > Is this something you'd be willing to add to the u-d-f tool?
>>
>>
>> Not anymore, support for system image is going away. It can be added,
>> but would be short lived, so I guess it depends on the immediate gains
>> this option will provide.
>
> There is a discussion going on about the right approach to solve this (and
> other related) problems [1]. We could use the opportunity now to implement
> this in the right place, maybe u-d-f isn't really that.

Yeah, it seems this change to migrate the flashing logic to another
tool might happen soon, so it's not clear yet which would be the right
target to use.

Some options we have:
- Enable support for flashing a rootfs in u-d-f (easy, but we might
change to another tool soon)
- Create our own script/logic to flash the image, but then it'd be
something the CI team would have to maintain and change when required

I wouldn't personally mind to change u-d-f now and provide a similar
option when we switch the logic into snappy itself.

Cheers,
-- 
Ricardo Salveti de Araujo