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

[Arevalo, Mario Alfredo C]

Hi folks,

I have been seen excellent ideas that we can to add to the tool, 
however I think we are walking a little out of the first scope, what do you think
if we include this as first version a we can post our ideas in the storyboard?:

https://storyboard.openstack.org/#!/story/2003712

Then we can track all ideas suggested :)

Best regards.
Mario.
________________________________________
From: Saul Wold [sgw at linux.intel.com]
Sent: Monday, September 10, 2018 10:33 AM
To: McKenna, Jason; '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?

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)
> /(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?
>
Jason,

Thanks for this feedback and the use case suggestions below, see
additional comments.

> 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
>
Based on your usage of /export and /import below, /export is on a server
machine and /import is on the local developer build machine, just for
clarification.

Also, this job would run native on the host Linux OS not containerized?


> 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.
>
To further clarify this one, the remote mirror could contain all binary
rpms along with their cooresponding src rpm, such that if no changes all
the building of an ISO would be done from the mirror rpms, no actual
local rpm build required unless it changes (use case 4/5 below).

> 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?
>
I would say not just puppet manifest, but any change to files in the repos.

> 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?
>
I look forward to seeing the demo also.

Sau!

>
>
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
>

_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss