Design - dropping support for stand-alone analysis mode (7711)

Design - dropping support for stand-alone analysis mode (7711)

[Barros Pena, Belen]

This Bugzilla feature

https://bugzilla.yoctoproject.org/show_bug.cgi?id=7711

Has considerable impact on how users interact with projects. If you can,
please check the design document attached to the Bugzilla feature and
comment as needed.

Thanks!

Belén

Re: Design - dropping support for stand-alone analysis mode (7711)

[Reyna, David]

Hi Belén,

I think that I am fine with this general design proposal. 

I have some comments and questions, mostly around the details for the not-yet-written "How to set up an analysis project" content.

1) Connecting Analysis Projects to External Builds?

It appears that the connection of analysis project to its build directory and artifacts is solely managed by the external build system? I assume that this is the case given the complexity and diversity of possible external build systems?

If that is the case, why do we support creating such project in the Toaster GUI? Is it perhaps to support a use case where the Toaster user would get the otherwise "unattached" project's ID number (on page 5) and enter it in the external build system to complete that connection?

2) Use case for current local analysis workflow?

Today you would use the tool "source toaster start" to connect a specific build directory to a Toaster build, and the "external builder" is in fact the command line user that initiates the build(s).

Will we still support this general workflow? In other words, could be provide the equivalent of ...

  $ cd <build_dir>
  $ source toaster start [project_id]
  $ bitbake core-image-base

... where some tool will be able to (a) attach this build to <project_id> if that parameter is passed, (b) find the Toaster project for this path if it exists and add this build, or (c) create a new Toaster analysis project on the fly if this directory path is not current used?

I believe that this workflow is important because it provides functional backwards compatibility, is easy to integrate for both formal and informal "build managers", and provides an easy way for reluctant command line users to get into the benefits of the deep Toaster Analysis features. 

All of these reasons apply to Wind River and its use of Toaster.

3) Passing data from External Builder

I assume that for external Build Managers the creation and population of an Analysis Project's builds is along the same lines as you have outlined in your Jenkins summary?

In other words, contrary to your statement on page 3, Toaster does not simply "collect" build information, it actually simply "receives" that information and artifacts as passed by say the plug-in for Jenkins?

Specifically, it would seem that (a) during the build the analysis data would be passed directly from that remote bitbake instance to the shared Toaster database, and then (b) upon success the selected build artifacts would then be also be passed by the integration plug-in.

- David

> -----Original Message-----
> From: toaster-bounces@yoctoproject.org [mailto:toaster-
> bounces@yoctoproject.org] On Behalf Of Barros Pena, Belen
> Sent: Thursday, May 14, 2015 8:42 AM
> To: toaster@yoctoproject.org
> Subject: [Toaster] Design - dropping support for stand-alone analysis
> mode (7711)
> 
> This Bugzilla feature
> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=7711
> 
> Has considerable impact on how users interact with projects. If you
> can,
> please check the design document attached to the Bugzilla feature and
> comment as needed.
> 
> Thanks!
> 
> Belén
> 
> 
> --
> _______________________________________________
> toaster mailing list
> toaster@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/toaster

Re: Design - dropping support for stand-alone analysis mode (7711)

[Reyna, David]

Hi again,

I am thinking about how on page 5 you expose the "Project ID" number.

Are you sure you want to do that? That is an internal database integer that I think should be absolutely hidden. It could also be volatile and non-portable, if for example Alex should at some time in the future want to be able to renormalize/port/rebalance the database.

I would think that the "Project Name" should the true and proper key for external lookup and access.

If your concern is that the GUI user may randomly rename the project and thus break the external connection, then perhaps there could be some other unique and persistent ID that is created and associated with the project so that we can we keep its database internal index integer out of this, like how git has the commit ID instead of its database location.

- David

> -----Original Message-----
> From: Reyna, David
> Sent: Tuesday, May 19, 2015 3:26 PM
> To: BARROS PENA, BELEN; toaster@yoctoproject.org
> Subject: RE: [Toaster] Design - dropping support for stand-alone
> analysis mode (7711)
> 
> Hi Belén,
> 
> I think that I am fine with this general design proposal.
> 
> I have some comments and questions, mostly around the details for the
> not-yet-written "How to set up an analysis project" content.
> 
> 1) Connecting Analysis Projects to External Builds?
> 
> It appears that the connection of analysis project to its build
> directory and artifacts is solely managed by the external build system?
> I assume that this is the case given the complexity and diversity of
> possible external build systems?
> 
> If that is the case, why do we support creating such project in the
> Toaster GUI? Is it perhaps to support a use case where the Toaster user
> would get the otherwise "unattached" project's ID number (on page 5)
> and enter it in the external build system to complete that connection?
> 
> 2) Use case for current local analysis workflow?
> 
> Today you would use the tool "source toaster start" to connect a
> specific build directory to a Toaster build, and the "external builder"
> is in fact the command line user that initiates the build(s).
> 
> Will we still support this general workflow? In other words, could be
> provide the equivalent of ...
> 
>   $ cd <build_dir>
>   $ source toaster start [project_id]
>   $ bitbake core-image-base
> 
> ... where some tool will be able to (a) attach this build to
> <project_id> if that parameter is passed, (b) find the Toaster project
> for this path if it exists and add this build, or (c) create a new
> Toaster analysis project on the fly if this directory path is not
> current used?
> 
> I believe that this workflow is important because it provides
> functional backwards compatibility, is easy to integrate for both
> formal and informal "build managers", and provides an easy way for
> reluctant command line users to get into the benefits of the deep
> Toaster Analysis features.
> 
> All of these reasons apply to Wind River and its use of Toaster.
> 
> 3) Passing data from External Builder
> 
> I assume that for external Build Managers the creation and population
> of an Analysis Project's builds is along the same lines as you have
> outlined in your Jenkins summary?
> 
> In other words, contrary to your statement on page 3, Toaster does not
> simply "collect" build information, it actually simply "receives" that
> information and artifacts as passed by say the plug-in for Jenkins?
> 
> Specifically, it would seem that (a) during the build the analysis data
> would be passed directly from that remote bitbake instance to the
> shared Toaster database, and then (b) upon success the selected build
> artifacts would then be also be passed by the integration plug-in.
> 
> - David
> 
> > -----Original Message-----
> > From: toaster-bounces@yoctoproject.org [mailto:toaster-
> > bounces@yoctoproject.org] On Behalf Of Barros Pena, Belen
> > Sent: Thursday, May 14, 2015 8:42 AM
> > To: toaster@yoctoproject.org
> > Subject: [Toaster] Design - dropping support for stand-alone analysis
> > mode (7711)
> >
> > This Bugzilla feature
> >
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=7711
> >
> > Has considerable impact on how users interact with projects. If you
> > can,
> > please check the design document attached to the Bugzilla feature and
> > comment as needed.
> >
> > Thanks!
> >
> > Belén
> >
> >
> > --
> > _______________________________________________
> > toaster mailing list
> > toaster@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/toaster

Re: Design - dropping support for stand-alone analysis mode (7711)

[Barros Pena, Belen]

Hi David,

Thanks for going through the design documents and for the questions /
comments. I'll add an open to the Toaster call to discuss them (easier
than email, I think).

Cheers

Belén

On 20/05/2015 07:57, "Reyna, David" <david.reyna@windriver.com> wrote:

>Hi again,
>
>I am thinking about how on page 5 you expose the "Project ID" number.
>
>Are you sure you want to do that? That is an internal database integer
>that I think should be absolutely hidden. It could also be volatile and
>non-portable, if for example Alex should at some time in the future want
>to be able to renormalize/port/rebalance the database.
>
>I would think that the "Project Name" should the true and proper key for
>external lookup and access.
>
>If your concern is that the GUI user may randomly rename the project and
>thus break the external connection, then perhaps there could be some
>other unique and persistent ID that is created and associated with the
>project so that we can we keep its database internal index integer out of
>this, like how git has the commit ID instead of its database location.
>
>- David
>
>> -----Original Message-----
>> From: Reyna, David
>> Sent: Tuesday, May 19, 2015 3:26 PM
>> To: BARROS PENA, BELEN; toaster@yoctoproject.org
>> Subject: RE: [Toaster] Design - dropping support for stand-alone
>> analysis mode (7711)
>>
>> Hi Belén,
>>
>> I think that I am fine with this general design proposal.
>>
>> I have some comments and questions, mostly around the details for the
>> not-yet-written "How to set up an analysis project" content.
>>
>> 1) Connecting Analysis Projects to External Builds?
>>
>> It appears that the connection of analysis project to its build
>> directory and artifacts is solely managed by the external build system?
>> I assume that this is the case given the complexity and diversity of
>> possible external build systems?
>>
>> If that is the case, why do we support creating such project in the
>> Toaster GUI? Is it perhaps to support a use case where the Toaster user
>> would get the otherwise "unattached" project's ID number (on page 5)
>> and enter it in the external build system to complete that connection?
>>
>> 2) Use case for current local analysis workflow?
>>
>> Today you would use the tool "source toaster start" to connect a
>> specific build directory to a Toaster build, and the "external builder"
>> is in fact the command line user that initiates the build(s).
>>
>> Will we still support this general workflow? In other words, could be
>> provide the equivalent of ...
>>
>>   $ cd <build_dir>
>>   $ source toaster start [project_id]
>>   $ bitbake core-image-base
>>
>> ... where some tool will be able to (a) attach this build to
>> <project_id> if that parameter is passed, (b) find the Toaster project
>> for this path if it exists and add this build, or (c) create a new
>> Toaster analysis project on the fly if this directory path is not
>> current used?
>>
>> I believe that this workflow is important because it provides
>> functional backwards compatibility, is easy to integrate for both
>> formal and informal "build managers", and provides an easy way for
>> reluctant command line users to get into the benefits of the deep
>> Toaster Analysis features.
>>
>> All of these reasons apply to Wind River and its use of Toaster.
>>
>> 3) Passing data from External Builder
>>
>> I assume that for external Build Managers the creation and population
>> of an Analysis Project's builds is along the same lines as you have
>> outlined in your Jenkins summary?
>>
>> In other words, contrary to your statement on page 3, Toaster does not
>> simply "collect" build information, it actually simply "receives" that
>> information and artifacts as passed by say the plug-in for Jenkins?
>>
>> Specifically, it would seem that (a) during the build the analysis data
>> would be passed directly from that remote bitbake instance to the
>> shared Toaster database, and then (b) upon success the selected build
>> artifacts would then be also be passed by the integration plug-in.
>>
>> - David
>>
>> > -----Original Message-----
>> > From: toaster-bounces@yoctoproject.org [mailto:toaster-
>> > bounces@yoctoproject.org] On Behalf Of Barros Pena, Belen
>> > Sent: Thursday, May 14, 2015 8:42 AM
>> > To: toaster@yoctoproject.org
>> > Subject: [Toaster] Design - dropping support for stand-alone analysis
>> > mode (7711)
>> >
>> > This Bugzilla feature
>> >
>> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=7711
>> >
>> > Has considerable impact on how users interact with projects. If you
>> > can,
>> > please check the design document attached to the Bugzilla feature and
>> > comment as needed.
>> >
>> > Thanks!
>> >
>> > Belén
>> >
>> >
>> > --
>> > _______________________________________________
>> > toaster mailing list
>> > toaster@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/toaster