[Starlingx-discuss] [Build] Feedback on stxb demo
McKenna, Jason
Jason.McKenna at windriver.com
Mon Sep 10 16:02:41 UTC 2018
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20180910/62f1db18/attachment.html>
More information about the Starlingx-discuss
mailing list