[Toaster] Workflow for Image Customization ?

[Barros Pena, Belen]

Hi David, 

The workflow is not quite like you describe.

1. You create a new project
2. You navigate to a "new custom image" page where you can select an
existing image recipe that will become the basis for your customisations
3. If the base image recipe has never been built, you will be asked to
build it before you can see the package list
4. You will see a list of packages that you can add and remove, based on
the layers added to your project
5. You will build your custom image

Repeat 4 and 5 as needed. Now, answers to your questions below.

Cheers

Belén

On 18/11/2015 01:31, "Reyna, David" <david.reyna at windriver.com> wrote:

>Hi Michael and Belen,
> 
>I wanted to understand an aspect of workflow for image customization.
>This is what I understand so far.
> 
>1. You create a new project.
> 
>2. You see a list of image items you can add. The list is the initial
>best of what is available, and what the dependencies are.
> 
>3. You checkbox your initial set of choices, and you build the image
>target, and it runs.
> 
>4. You return to the list of image items. The list content and
>dependencies are now improved because bitbake/Toaster has much better
>information now that a build has been done.
> 
>5. You check and/or un-check your second pass set of choices, and you
>re-build the image target, and it runs.
> 
>6. You again return to the list of image items, make your third pass
>refinements, and re-build the image target.
>
> 
>However, this time the image does not work, either because you removed
>too much functionally for your applications or because there was an error
>in the dependency data and the image is functionally inconsistent.
> 
>7. Here are my questions.
> 
>  * How do you recover to the last working configuration?

This functionality is not planned for v1. All configurations are kept as
part of the build history, so you could see the list of packages installed
in your last working build and add / remove packages from your custom
image to match that.

I agree that returning to a prior configuration would be extremely useful
(please open a Bugzilla feature for this), as it would be build comparison
in order to understand what changed between a successful build and a
failed one (I think we already have a Bugzilla entry for this one).
 

>  * Do we recommend people to clone their projects (i.e. ³Save-as²) so
>that they have a backup?

We don't have clone project functionality at the moment. Again, we have a
Bugzilla entry for it though.

>  * Would we checkpoint the last (or last few) configurations so that
>they could do an undo?

Maybe we could turn each build you run into a "checkpoint" you can return
to. Since we have the configuration saved, we could potentially recreate
it. 

> 
>I ask because in our implementations of image customization the field
>engineers and customers almost always went to a point where the image
>failed, so having a recovery procedure was crucial for customer happiness.

Yes, and it makes complete sense for them to request that. Once more, this
is not about not wanting to do it, it's about not being able to do it in
the current cycle. We are already struggling to deliver this relatively
simple, first version of image customisation. We need to get the ground
work out the door before we can think of these additional features. One
step at a time :)

> 
>- David
> 
> 
> 
> 
>