https://jira.akraino.org This file is an XML representation of an issue en-us 9.4.5 940005 11-04-2023 https://jira.akraino.org/browse/KNI-19 Kubernetes Native Infrastructure <p>Apply_workloads command does not download the newest up to date blueprint once it has been executed once.</p> KNI-19

Apply_workloads after updating blueprint

Bug Medium To Do Unresolved Jonathan Cope Ricardo Noriega KNICTL Wed, 8 Jul 2020 15:22:11 +0000 Wed, 7 Oct 2020 20:41:20 +0000 0 2 <p>I tried creating 3 distinct workloads at each layer.  This was done by writing ngnix deployments, each unique, under 03_services dir for ./site/, ./profile/, and ./base, and appending them to their respective kustomize.yaml resource lists, and finally pushing them to the remote repo.  Executing apply_workloads showed that only new deployments from base and profile were created, but site was not.</p> <p>The issue lies in the way DownloadRepos() and ApplyWorkloads manages relationships between the separate layers (base, profile, site). The process:</p> <ol> <li>Downloads the remote blueprint to ~/.kni/$SITE/blueprint</li> <li>Copies the local (stale) site ~/.kni/$SITE/site =&gt; ~/.kni/$SITE/blueprint/sites/site</li> <li>Walks ~/.kni/$SITE/blueprint/sites/site to replace git urls with relative paths (separately, this seem erroneous b/c the paths have already been replaced in the stale source, but I don't know what's doing it yet)</li> <li>Applies kustomize to ~/.kni/$SITE/blueprint/sites/site (still stale)</li> </ol> <p>So the issue is that it downloads the remote files, but executes against a copy of the locally stored, stale site. The relative paths point the stale site to the new versions of the profile and base. Thus any changes in ~/.kni/blueprint/sites/$SITE (the remote version), are ignored.</p> <p>I've been unable to reproduce the behavior via:</p> <p>1. Spin up a management cluster (<a href="https://github.com/copejon/blueprint-management-hub)" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/copejon/blueprint-management-hub)</a><br/> 2. Apply workloads<br/> 3. Update blueprint components under <tt>edge-mgmt-hub.gcp.devcluster.openshift.com/blueprint/base/03_services/...</tt> and push to above repo<br/> 4. Apply workloads again<br/> 5. Check local ~/.kni copy of blueprints.  In my case, shows the changes made in remote.</p> <p> <br/> Is this the process you've used to reproduce the behavior? If not, please let me know.</p> Development Rank 0|i004g4: