[Starlingx-discuss] [Build] Feedback on stxb demo

[Ornelas Aguayo, Jesus]

From: Saul Wold <sgw at linux.intel.com>
Date: Monday, September 10, 2018 at 12:33 PM
To: "McKenna, Jason" <Jason.McKenna at windriver.com>, "'starlingx-discuss at lists.starlingx.io'" <starlingx-discuss at lists.starlingx.io>
Subject: Re: [Starlingx-discuss] [Build] Feedback on stxb demo

    Sorry I missed this today, I am in Denver.
    
    Can you point me at the repo you are working in please?

	https://review.openstack.org/#/c/601366/ 
	https://review.openstack.org/#/c/601306/
	https://review.openstack.org/#/c/601308/ 
	https://review.openstack.org/#/c/601309/ 

    
    On 09/10/2018 09:02 AM, McKenna, Jason wrote:
    > Hi build team,
    > 
    > Many thanks for the demo today, I think we’re on the right track.  As 
    > promised, here are a few feedback points on the demo, from the 
    > perspective of a developer:
    > 
    > -I really like how the creation of the docker image is streamlined.
    > 
    > -The system as currently demo’d as two copies of the repos.  One in 
    > /(developers_path)/, and a second in 
    > /(developers_path)/stx-tools/(docker_image_root_dir)/localdisk/designer/builder/starlingx/.  
    > There should only one repo downloaded.
    > oAs a related point, a developer working on changes to a file would 
    > expect to make their changes to the repo in /(developers_path)/, rather 
    > than to the version in the docker image’s filesystem.  If I edited a 
    > puppet manifest (for example) 

	Hi, I think there are a lot of user scenarios that we need to consider, and we 
	Should be adding functionality  step by step, so far the commits mentioned simplify
	The building process to new users and can be used to add more functionality
	Four our next steps, I think we should create an storyboard  to extend the 
	Functionality  by adding the  scenario that  need to be covered, starting with
	the ones Jason mentioned in this email:
 
	What about using two flags set by opts , one to use a local repo path and another one
               And another one to  specify if the user wants to use a repo from a different
	Manifest and  url.

    > /(developers_path)/cgcs-root/stx/stx-config/…/ then I would expect the 
    > build command to detect and use my changes if I do a build.

	It could be an update flag, it the value is false, then it could skip the
	Updates/downloads  and use the local content only
  
    > -I’m a bit confused on the syntax regarding specifying and using 
    > localized mirrors, specifically with the –n and –p options.  Would you 
    > provide examples of what commands I’d execute for use cases 1 and 2 
    > below? I’m pretty sure these usages are supported, but am just seeking 
    > clarification.

	`stxb build mirror`creates a defauilt mirror in the local workspace/mirror if no opts are given,
	 In the current path ($PWD/starlingx/mirror),
		If the `stx build mirror -n my-staging-mirror` is given the path would be 
			$PWD/starlingx/my-staging-mirror
		If the `stx build mirror -p /mnt/nfs` is given the path would be
			/mnt/nfs/mirror
		If the `stx build mirror -p /mnt/nfs/ww11/ -n monday` is given the path would be
			/mnt/nfs/mirror/www11/Monday
		
			
    > -Very happy do see it down to 1 docker image, rather than 2 J
    > 
    > -Native build – Being able to build in a docker image is great, but the 
    > would ideally be an option to perform a native build, rather than have 
    > to use a container

    > -Minor nit - logs should be in a user directory (like 
    > $MY_REPO_ROOT_DIR/logs/) rather than in /var/log, as a non-privileged 
    > user wouldn’t be able to log to /var/log.

	The PR changed the path to use the ${WORKSPACE}, and specify another
	Another path if needed with the opt `-p` 

    > -Question – what privileges are required to create the docker image?  
    > Does the script assume the user has sudo privileges?
    
	So far I've running it without using sudo, using a user with docker group 
	Permissions

 
    > -I’m unclear on what would happen with use cases 3-5 below.  Have these 
    > types of uses been considered yet?
    >