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 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.

- 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?