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. o As 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) /(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. - 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. - Very happy do see it down to 1 docker image, rather than 2 :) - 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. - Question - what privileges are required to create the docker image? Does the script assume the user has sudo privileges? - I'm unclear on what would happen with use cases 3-5 below. Have these types of uses been considered yet? Thanks again for the demo, -Jason Use Case 1: I am an organization with a site who is working with StarlingX. I want to provide a local mirror for my employees to use so they don't have to download all artifacts from the external internet every time. I want to create an automated job which I will run daily to download all artifacts from the Internet (if they do not already exist) and place them in directory /export/mirrors/starlingx. Assume the user running the automated job has permissions to write to /export/mirrors/starlingx Use Case 2: I am a developer within an organization which has a local mirror of artifacts available in /import/mirrors/starlingx. I want to build a StarlingX ISO without downloading rpms or src.rpms from the external internet. Use Case 3A: After doing a build, I just performed a repo sync, and the .lst files were not updated. If I perform another build of the ISO, will the system attempt to redownload external artifacts, even though nothing has changed? Use Case 3B: After doing a build, I just performed a repo sync, and noticed that the .lst files have been updated. If I perform another build of the ISO, will the stale mirror content be detected and the new additions downloaded (while not re-downloading anything which has not changed)? Use Case 4: I have manually made a change to a puppet manifest in sysinv (stx-config git) but want to test before I commit anything. How can I build a new ISO with my changes incorporated? Use Case 5: I want to test StarlingX with my own additional program (foobar.x86_64.rpm) on the ISO. How would I perform a build with this file added?