[Toaster] [RFC] Configuration variables in Toaster

Damian, Alexandru alexandru.damian at intel.com
Fri Jul 18 02:39:04 PDT 2014


Hi,

Details inline, below,

Alex


On Thu, Jul 17, 2014 at 7:46 PM, Wymore, Farrell W (Wind River) <
farrell.wymore at windriver.com> wrote:

>  Alex,
>
>
>
> A few further, key questions: can the bldcontrol run on a remote host?
>>
>Bldcontrol runs a single instance, usually on the same machine (but not
necessarily) as the web server.  Bldcontrol can start builds on remote
machines through various interfaces, e.g. ssh, buildbot API, etc.
​

>> Are there any runtime dependencies
> ​​
>
>  between bldcontrol and toaster, apa
> ​​
> rt from the database?
>>
> The connection point is the database.​
​

>> Can there be multiple bldco
> ​​
> ntrol-ers running on
>
> several remote hosts?
>>
>No, but there may be more builds running at the same time, for a single
bldcontrol instance, on multiple machines. Bldcontrol is "fire-and-forget",
it just starts the build and then disconnects from the bitbake server.
ToasterUI will know when the build is over, send the server shutdown
command, and retrieve relavant artifacts.
​

>>
>
>
> -          fw
>
>
>
> *From:* Reyna, David
> *Sent:* Thursday, July 17, 2014 1:22 AM
> *To:* DAMIAN, ALEXANDRU
>
> *Cc:* BARROS PENA, BELEN; toaster at yoctoproject.org; Wymore, Farrell; Paul
> Eggleton; Richard Purdie
> *Subject:* RE: [Toaster] [RFC] Configuration variables in Toaster
>
>
>
> Hi Alex,
>
>
>
> After reading your email and having a conversation with Farrell, I see
> that my missing “actor-in-the-machine” is exactly your “bldcontrol”
> application.
>
>
>
> Let me write out what I think is the workflow and OOB, to see if I have a
> decent understanding.
>
>
>
> 1) Setup by the  “System Administrator” (SA)
>
>
>
>   * The SA installs YP
>   * The SA installs MySQL (or some other SQL database), and points Toaster
> at it
>
>   * The SA sets the “default policy”, specifically the (b) variables, in
> some manner *(to be determined?)*
>
>   * The SA starts the instance of Toaster et. al.
>
>   * The SA starts the instance of Bldcontrol
>
>   * The SA goes to the pub, and lets his server toast projects
>
>
>
> 2) Usage by the Client(s)
>
>
>
>   * The client starts their browser and opens a connection to the remote
> Toaster
>
>   * The client creates a project
>
>   * The client clicks the “build” button, and goes out for tea
>
>   * The Bldcontrol sees the build request, and immediately processes it:
>
>         * it extracts the user’s (a) configure variables
>
>         * it merges the SA’s “default policy” (b) variables
>
>         * it sets up the bitbake environment, and starts bitbake
>
>   * The client returns from tea, sees that the build completed and that
> Toaster database has the build results
>
>   * All rejoice
>
>
>
> 3) The Out-of-Box Experience (OOB) Summary
>
>
>
>   * The user can use basic Toaster as they did in YP-1.6
>
>       * The simple “source toaster start” command can be used to set
> things up with one step
>
>       * The database and web server instance and initialization is
> automatic
>
>       * Users can immediately use Toaster on their projects
>
>
>
>   * The user can use the new “managed build” Toaster with YP-1.7
>
>       * The SA will perform the basic set up steps outlined above
>
>           (*is there an optional command for a one-step default setup*?)
>
>       * The included Bldcontrol build service will do all requested builds
> on that server
>
>       * Remote users can immediately connect, create projects, have them
> built, browse the results at completion
>
>
> 4) Customization and Advanced Users (after OOB)
>
>
>
> We (meaning you) have already provided various tools to (a) set up the
> alternate databases and/or place it in a shared location, and (b)
> separately start the web server.
>
>
>
> What about Bldcontrol? If the developer wants a different functionality
> for managing the builder service, shall we just point them at the source
> for Bldcontrol and encourage them to have-at-it? I myself am fine with that
> for Toaster-1.7, given the huge scope of difference goals and different
> constraints from the many customers. We can optimize a few more workflows
> in Toaster-1.8 based on the feedback on how people are actually using it.
>
>
>
> - David
>
>
>
>
>
> *From:* Damian, Alexandru [mailto:alexandru.damian at intel.com
> <alexandru.damian at intel.com>]
> *Sent:* Wednesday, July 16, 2014 7:26 AM
> *To:* Reyna, David
> *Cc:* BARROS PENA, BELEN; toaster at yoctoproject.org; Wymore, Farrell; Paul
> Eggleton; Richard Purdie
> *Subject:* Re: [Toaster] [RFC] Configuration variables in Toaster
>
>
>
>
>
>
>
> On Wed, Jul 16, 2014 at 9:27 AM, Reyna, David L (Wind River) <
> david.reyna at windriver.com> wrote:
>
> Hi Alex,
>
>
>
> I have been giving your email some considerable thought…
>
>
>
> > “… wouldn't it be confusing for the users if they could change these
> variables …”
>
>
>
> Ok, I am going to go with your model, for this reason.
>
>
>
> > “I would suggest a big red warning that ​these variables could be
> overridden without further warnings by the build system.”
>
>
>
> Ok.
>
>
>
> > “Not sure what OOB?”
>
>
>
> *O*ut-*O*f-*B*ox experience, hence my questions about what happens during
> the first time usage.
>
>
>
> > “During this extra step, an extra step is taken to create a default
> admin user”
>
>
>
> Ok.
>
>
>
> > “postconf versus preconf”
>
>
>
> Here is the crux of my confusion, for the OOB and for these variables.
>
>
>
> What actor is setting the (b) variables in the end? In your description of
> postconf and preconf I still do not see that detail, only that we are
> trying to keep Toaster from doing it.
>
>
>
> Perhaps when you write “bitbake server”, there is actually something with
> new intelligence that selects proper values for the (b) variables? Or
> perhaps a new settings file created (as part of the OOB first time use)
> that populates the intended default values, which the system manager then
> edits?
>
>>
>>
> The actor for this part of the configuration would be the system
> administrator. This role will be performed by a system manager for hosted
> instances for Toaster, and by the user for local instances. The preferred
> file for these settings is "local.conf", but it may be overridden by the
> administrator by asking bitbake to read multiple configuration files at
> startup.
>
>
>
> This is highly analogous with editing the local.conf files to set
> PARALLEL_MAKE or SSTATE_MIRRORS first time you start a new project - set
> them once and forget about them.
>
>>
>>
>
>
> > “As for the *local* and *remote* build, I would suggest avoiding
> thinking in these terms”
>
>
>
> Without understanding the intended agent that manages the builds and the
> (b) variables, I am not sure I understand the symmetry between these two
> types of builds, hence my asking.
>
>
>
> Type b). variables will​ be different between local and remote builds, but
> the outcome of the process (the build results) will be identical. The type
> a). variables will be identical between remote and local builds.
>
> ​​
>
>>
>   ​​
>
> The “local” build to me is very closely tied to the OOB experience, so I
> want
>
> ​​
>
> to make sure I understand this. Also, specifically, for the “local” build
> there i
>
> ​​
>
> s a persistence of the “local.conf” that is valuable (as per my previous
>
> ​​
>
> discussion around command line versus Toaster GUI developers) that
>
> ​​
>
> has no relevance in the “remote” world.
>
>>
>>
> I think that "local​.conf" is too broad of a term as it holds both a).
> type and b). type variables.
>
>
>
> I would love to identify *what variables are valuable *in local.conf
> persistence, *why* are they valuable (because if they are better to
> configure the build process , we'll put them in category by, and keep them
> in local.conf), and see if we can fit the variables that influence what you
> build (e.g. IMAGE_INSTALL_append) in the a). category.
>
>
>
>>
> ​​
>
>
>
> ​​
>
> ​​
>
> > I would favour 1)
>
> ​​
>
>
>
> ​​
>
> As would I since it removes the need for the extra intermediate file.
>
>
>
> Thanks,
>
> David
>
>
>
>
>
>
>
> *From:* Damian, Alexandru [mailto:alexandru.damian at intel.com]
> *Sent:* Monday, July 14, 2014 4:01 AM
>
>
> *To:* Reyna, David
> *Cc:* BARROS PENA, BELEN; toaster at yoctoproject.org; Wymore, Farrell; Paul
> Eggleton; Richard Purdie
> *Subject:* Re: [Toaster] [RFC] Configuration variables in Toaster
>
>
>
> Hi,
>
>
>
> Thanks for the input,
>
> I have comments inline, and I hope this will shed a bit more light on how
> I think about builds,
>
> Cheers,
>
> Alex
>
>
>
> On Fri, Jul 11, 2014 at 8:16 AM, Reyna, David L (Wind River) <
> david.reyna at windriver.com> wrote:
>
> Hi Alex,
>
>
>
> > In this respect, I propose that we blacklist from Toaster interface any
> variable in category b), at least for 1.7 release.
>
> While I am reluctant, I can accept this if we are just trying to solve
> 1.7, and come back to this in 1.8.
>
>
>
> I still stand by my point that the buildbot (or other infrastructure) will
> _*always*_ have to dynamically compute and "sanitize" the (b) variables
> to do its job, so I am still unclear how you are saving work for the
> buildbot with your proposal. Perhaps you are hoping to use buildbot
> unmodified and/or without an intermediary agent, but I do not see how that
> will work.
>
>
>
> This is exactly the point - the building infrastructure will have to
> sanitize the variables set. ​Since these variables will ALWAYS be
> overridden, wouldn't it be confusing for the users if they could change
> these variables, but the changes would have no effect ?
>
>
>
> I would also like to understand your OOB scenario for Toaster users, since
> you are counter-proposing my suggestions on that point.
>
>
>
> ​Not sure what OOB :) is ?​
>
>
>
> ​Out Of Band ?​
>
>
>
> For example:
>
>   * Will Toaster create a default admin setup on-the-fly for first time
> users, just as today it will create a default database on-the-fly?
>
>
>
> ​When launched in managed mode (i.e. outside a build environ​ment), there
> are additional tables created on first startup. During this extra step, an
> extra step is taken to create a default admin user. We don't currently use
> this admin user, nor we enable the admin interface, but at lease we have
> the base to allow us to extend related functionality in the future.
>
>     * Will Toaster aggressively detect and reject if the user should
> attempt to manually add the (b) variables in the custom configure var page?
>
>
>
> ​I would suggest a big red warning that ​these variables could be
> overridden without further warnings by the build system.
>
>
>
>
>
> I will mention that my immediate issue is that I am positioning Toaster to
> replace the Wind River Linux 7.0 project configuration tools, and for that
> I _*do*_ have to consider the local case. I can accept some extra work on
> my team above and beyond your Toaster-1.7 design, as long as the
> Toaster-1.7 does not prevent what I need to do.
>
>>
> ​I understand this, and I'm trying to support your model of usage for
> Toaster. ​
>
>
>
> ​The thing is, unless I understand in detail how you intend to use
> Toaster, I will probably favour decisions that will create some hardship
> for you. I'm trying to avoid this situation.
>
> What variables ​are set influence how the build control system is
> designed, actually. There are two ways to go about it:
>
> 1). postconf - start bitbake server, and connect to it and push changed
> variables; this will create problems for variables in category b), but we
> can be sure that the variables that we set are not overridden by the
> infrastructure; in order to do this, we need to make sure that we don't set
> any variables that could create problems for the infrastructure, so the
> sanitize is on toaster side.
>
> 2). preconf - create a specific config file (let's say user-toaster.conf)
> that can be pushed to bitbake to be used when the server starts. This
> allows us to configure any kind of variable, because a proper "local.conf"
> deployed by the infrastructure can override dangerous variables. The
> downside is that we can't guarantee that the variables set by the user will
> not be affected or changed by the variables pushed by infrastructure.
>
> In between choices 1). and 2)., I would favour 1)., because, while
> limiting the user in what he can do, it will not lie to the user by setting
> variables that will not be reflected in the build.
>
>
>
> ​As for the *local* and *remote* build, I would suggest avoiding thinking
> in these terms - ​what I think we should concerned about is the
> *repeatability* of the build, i.e. regardless of where the build
> executes, we must make sure that on the same project configuration, we get
> the same output.
>
> The use case I'm using to  evaluate the repeatability is : if a user
> configures a project to his liking, working only on his machine, and then
> if he exports the project settings to a file, and then imports that file to
> a hosted Toaster infrastructure: Can we certify that the output of the
> build on the infrastructure is identical to the build that the developer
> had on his machine ?
>
> I am not sure how compatible is this view with WR's intended usage for
> Toaster, so I'm appreciating all your input :)
>
>
>
>
>
> Thanks,
>
> David
>
>
>
> *From:* Damian, Alexandru [mailto:alexandru.damian at intel.com]
> *Sent:* Thursday, July 10, 2014 8:48 AM
> *To:* Reyna, David
> *Cc:* BARROS PENA, BELEN; toaster at yoctoproject.org; Wymore, Farrell; Paul
> Eggleton; Richard Purdie
> *Subject:* Re: [Toaster] [RFC] Configuration variables in Toaster
>
>
>
> Hello,
>
> I've been reviewing this proposal, and I think it's good to have this
> discussion now, and the points raised are excellent.
>
> I'm seeing a different angle to the variable story. CCing Paul and Richard
> so they can track this discussion.
>
> I think that we can separate the bitbake variables in two different
> categories, even if bitbake itself makes no such separation, -
>
> a). variables that influence WHAT will be built - e.g
> EXTRA_IMAGE_FEATURES, or IMAGE_INSTALL_append
>
>
> b). variables that influence HOW it will be build - e.g. PARALLEL_MAKE, or
> SSTATE_MIRRORS for that matter
>
>
>
> When you configure bitbake, you have to put two different hats, a
> developer hat for a). and a sysadmin hat for b).
>
> I think that, at the current point, Toaster should focus at being only a
> developer tool, and it should concern itself only with the a). hat.
>
> In this respect, I propose that we blacklist from Toaster interface any
> variable in category b), at least for 1.7 release.
>
> In this way, we reduce the chance that Toaster settings will screw
> something up on the infrastructure setup, and we'll also solve the problem
> of having the buildbot (or other infrastructure) "sanitize" the variables
> set by Toaster.
>
>
>
> In respect to the a). variables, I think it's a good idea to provide a set
> of commonly-used variables with sane defaults, and offer help for the user
> when he adds other variables, e.g. link to manual description or help
> searching variable name.
>
> What do you think ?
>
> Cheers,
> Alex
>
>
>
> On Wed, Jul 9, 2014 at 11:28 PM, Reyna, David <david.reyna at windriver.com>
> wrote:
>
> Hi Belén,
>
> You write: "In a Toaster instance connected to a build farm, a user of
> Toaster should not be able to override any variables that impact how
> hardware runs builds and where
> artifacts are stored."
>
> I would think of this in the opposite manner.
>
> Proposed wording: "In a Toaster instance connected to a build farm, the
> remote build instance will _always_ override any variables that impact how
> hardware runs builds and where artifacts are stored, regardless of any
> default bitbake settings or explicit user settings."
>
> Here is my reasoning:
>
>   * The remote build instance's manager/configuration will need to
> dynamically set these values regardless and in all cases, based on its
> current resources and environment, whether they are previously defined or
> not.
>
>   * We cannot prevent the user from manually setting the values no matter
> what we do, as per your mention of the free form "add variables" option.
>
>   * We can think of this class of variables as "preferences". If it is a
> local build then these values will be used (not overridden) and user will
> get what they expect. If it is a remote build then the values will be
> expected to be overridden by design and again the user will get what they
> expect.
>
>   * With this model there are no surprises, both workflows are easily
> covered, and everyone is happy.
>
> - David
>
>
>
>
> > -----Original Message-----
> > From: Barros Pena, Belen [mailto:belen.barros.pena at intel.com]
> > Sent: Wednesday, July 09, 2014 9:42 AM
> > To: toaster at yoctoproject.org
> > Cc: Wymore, Farrell; Reyna, David; Lerner, Dave
> > Subject: [RFC] Configuration variables in Toaster
> >
> > Some discussion happened today about the list of variables that Toaster
> > should expose (see below from previous thread). It was observed that, for
> > cases when you are in control of the build hardware, it would be handy to
> > be able to set variables like PARALLEL_MAKE, BB_NUMBER_THREADS and
> > SSTATE_DIR. I took out those variables from the list because they impact
> > how hardware runs builds and where build artifacts are stored, which are
> > things that a user of a Toaster instance connected to a build farm should
> > probably not touch.
> >
> > It was suggested that maybe the list of variables could change if Toaster
> > is running on the same machine that runs the builds. There is also the
> > "add variables" option, which is free form and that will allow you to
> type
> > any variable and any value you want. So that option would in theory allow
> > you to set PARALLEL_MAKE or anything else you might want to set.
> >
> > Now: that brings up a question about variable handling. In a Toaster
> > instance connected to a build farm, a user of Toaster should not be able
> > to override any variables that impact how hardware runs builds and where
> > artifacts are stored. If the user adds PARALLEL_MAKE = "8" to a Toaster
> > project configuration, that should have no effect on the PARALLEL_MAKE
> > value that a build server in a farm is supposed to use, and that should
> > have been set by whomever administers that farm. Same goes for
> SSTATE_DIR,
> > SSTATE_MIRRORS, DL_DIR, etc. Maybe I am just not looking at this in the
> > right way, or there is something I don't fully understand, but it seems
> to
> > me that Toaster could become a liability otherwise.
> >
> > Any thoughts on how this should be handled would be much appreciated.
> >
> > Thanks!
> >
> > Belén
> >
> > On 08/07/2014 15:40, "Barros Pena, Belen" <belen.barros.pena at intel.com>
> > wrote:
> >
> > >That's the Toaster page that allows you to edit the project local.conf
> > >file. I am trying to come up with a final list of the variables that
> will
> > >be listed in that page.
> > >
> > >Looking at the default local.conf file, and excluding stuff that should
> be
> > >defined by the Toaster instance (things like SSTATE_MIRRORS or DL_DIR),
> > >this is what I'm left with:
> > >
> > >PACKAGE_CLASSES
> > >SDKMACHINE
> > >EXTRA_IMAGE_FEATURES
> > >USER_CLASSES
> > >TEST_IMAGE
> > >OE_TERMINAL
> > >PATCHRESOLVE
> > >PACKAGECONFIG_pn-qemu-native (for Qemu configuration)
> > >ASSUME_PROVIDED (for Qemu configuration)
> > >CONF_VERSION
> > >
> > >Of the above, I am not sure we should expose the Qemu configuration
> stuff
> > >or CONF_VERSION, but I could be wrong.
> > >
> > >
> > >Hob also allows you to set:
> > >
> > >INCOMPATIBLE_LICENSE
> > >IMAGE_FSTYPES
> > >IMAGE_EXTRA_SPACE
> > >TOOLCHAIN_BUILD
> > >LINGUAS_INSTALL
> > >plus proxy configuration variables (http_proxy, https_proxy, ftp_proxy,
> > >all_proxy, CVS_PROXY_HOST, CVS_PROXY_PORT)
> > >
> > >Should we list this Hob stuff as well (except the proxy variables, I
> > >guess)?
> > >
> > >Apart from the above, there will be a way to set IMAGE_INSTALL_append,
> and
> > >also an option to add any other variable (free text kind of thing).
> > >
> > >Any thoughts on this list?
> > >
> > >Thanks!
> > >
> > >Belén
> > >
> > >--
> > >_______________________________________________
> > >toaster mailing list
> > >toaster at yoctoproject.org
> > >https://lists.yoctoproject.org/listinfo/toaster
> >
>
> --
> _______________________________________________
> toaster mailing list
> toaster at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/toaster
>
>
>
>
> --
>
> Alex Damian
>
> Yocto Project
>
> SSG / OTC
>
>
>
>
> --
>
> Alex Damian
>
> Yocto Project
>
> SSG / OTC
>
>
>
>
>
> --
>
> Alex Damian
>
> Yocto Project
>
> SSG / OTC
>



-- 
Alex Damian
Yocto Project
SSG / OTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/toaster/attachments/20140718/65729378/attachment-0001.html>


More information about the toaster mailing list