[yocto] Some questions about the webhob design

[Zhang, Jessica]

Please see my comments/questions below...

-----Original Message-----
From: yocto-bounces at yoctoproject.org [mailto:yocto-bounces at yoctoproject.org] On Behalf Of Paul Eggleton
Sent: Thursday, July 05, 2012 3:01 AM
To: yocto at yoctoproject.org
Subject: Re: [yocto] Some questions about the webhob design

On Tuesday 03 July 2012 12:10:57 Xu, Dongxiao wrote:
> Today Jessica and PRC team had a discussion of the webhob tasks listed
> in the wiki page, and about the "Group" and "Project" concept, we
> still have some questions.

Let's be clear though from the below, we're talking about projects only.
 [JZ] Yeah, let's focus on project's configuration for this thread.

> Say user A and user B are privileged users, who have the right to
> customize images, while user C is normal user (Say a TME) and only "building image"
> is allowed.
>
> 1) If user A customized an image with certain configurations, and he
> told user C that the environment is ready, and user C can build his
> demo image there. However, before user C starts to build, user B
> changed some configurations, making the final output not the expected version.

So firstly, in the design, any change to a project made by a user that occurs while another user is also configuring a build on that same project should be reflected in real-time in the other user's interface, and will be accompanied by a notification that a change has been made.


<JZ> Can we clarify some definition here, when we talk about project build configuration, are they the same as in current hob's saved template? So, if a user configure a build for the project and want to preserve the changes, he/she will achieve so through save template? And we only allow one build configuration per project? </JZ>


When more than one user is working on a project, it is expected that they would all be working towards the same goal. Creating separate projects for separate work efforts that may have different needs is intended to be easy.

<JZ> Agreed overall, but let's look at some particular cases to flesh out the rule further.  Say we have a project webhobtesting. For user A he set the package system as RPM, where user B wants to use deb.  So should we 1) create 2 projects webhobtesting-rpm and webhobtesting-ipk; 2)one webhobtesting project, but depends on who made the modification last, the package system will be set as the last user's preference? This will be what Dongxiao's talking about in the original question.  After user A configure as RPM and told TME to open the project and run the build.  In the meantime, user B switch it to deb.  So the TME's build output will not match what he'd expected that user A has set it to.  Also, we can't expect that user A is also login to receive the notification that his configuration has been changed; 3) we allow multiple configuration files against same project, which requires a project level configuration management mechanism. </JZ>

 If a user does want to do some experimenting on a project in isolation, the design provides for the ability to duplicate the project which can then be modified privately without affecting the original project.

<JZ> So this means we will allow each individual user to create his/her own sandbox which I agree.  Then we'll need to design the mechanism to distinguish the real project build configuration and user private ones. And the implication of that </JZ>

It's also a similar situation to working with any other shared resource such as a source code repository or a shared document - some discipline is required, and there's a limit to how much the tool can enforce in terms of people not messing up other people's work (other than providing a permissions framework, of course).

> 2) Another issue may be how to avoid global project changes happened
> together? For example user A and user B change the setting in the same
> time?

At the implementation level, with the usual database-level locking there must be a "winner" and a "loser" in this situation. The "winner" in our case should be whoever made the change last. As above there will be notifications shown to both users.

<JZ> But if we are really talking about concurrency here, isn't committing the change will be protected by a critical section and whoever got the lock wins?</JZ>

> 3) If user A changes the global project setting, what's the impact to
> the user B who already kicked off a build based on the original setting?

Once the build has started it should be isolated from the configuration within the interface, i.e. any subsequent changes should not affect it. Internally in the implementation I would recommend taking a lock on the project settings as soon as the user requests the build to start, which shortly afterwards can be released once the build has actually started - but this is not something that should be visible at a user level, except as a minor delay. In case user B goes back in to view the settings that are now different to what is being used for the build, the system should be able to fairly easily show a note within the configuration screen that the settings shown have been changed since the currently executing build was started.

<JZ> Agreed </JZ>
Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre
_______________________________________________
yocto mailing list
yocto at yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto