From: Saul Wold <sgw@linux.intel.com> Date: Monday, September 10, 2018 at 12:33 PM To: "McKenna, Jason" <Jason.McKenna@windriver.com>, "'starlingx-discuss@lists.starlingx.io'" <starlingx-discuss@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? >