create mirror of foreign OS does not propagate customized comps.xml in repo

[de21...@gmail.com]

Good Day All!

i'm new to the group and to stacki - if this topic is out of line please redirect me to the appropriate forum.

some background

we have an appliance that is a customization of centos distributions. we have our own rpm repo that contains the standard centos distro plus our customizations and additions to it. we have added our own group to the repomd.xml.

i am trying to create a foreign pallet that we can deploy via stacki but i discovered that create mirror does not propagate the comps.xml file from our repo. more accurately, the mirror contains the file BUT when the iso is created there are no comps.xml.

i'm using stacki 5.0. our custom OS is based upon Centos 7.5.

i've looked at /opt/stack/lib/python3.6/site-packages/stack/commands/create/mirror/__init__.py and found the "addcomps" switch in the makeRollXML function but that only seems to have caused the "foundation-comps" to be added to the iso - not our comps.xml from the repo.

i've looked for the pallet developer guide referenced in the documentation but have not found it anywhere.

is this the wrong workflow to create a pallet that will deploy our customized OS?

thanks in advance
denis

[Bill Sanders]

Hi Denis,

Sorry for the lag.  We've all been heads down working on a release, so we've dropped the ball over here.

I don't have an easy answer for you unfortunately.  From my understanding of your description, you'll want to create a new ("native") pallet that represents the logical delta between your distro and stock centos.  Then when you are ready to deploy hosts with stacki, you'll put them in a Box that contains the Stacki pallet, the "foreign" CentOS pallet (which is just the stock media), and your new pallet.

Some general instructions follow, which assume your new pallet will be called 'bob', and you want to version this pallet 1.0.  Please let me know if any of this is confusing and I'll try to clarify.

From a Stacki frontend:

cd /export/
stack create new pallet name=bob version=1.0

That creates a directory ./bob/, which is the basic skeleton of a pallet (pre-compilation) and whose contents looks like:

bob
├── graph
│   └── bob.xml
├── Makefile
├── nodes
│   ├── bob-base.xml
│   ├── bob-client.xml
│   └── bob-server.xml
├── src
│   ├── bob
│   │   ├── Makefile
│   │   └── version.mk
│   └── Makefile
└── version.mk

You should version control this directory (in fact, it might assume that you have and throw an error during pallet compilation time - I'll need to investigate)

git init
git add .
git commit -m "Initial commit of bob pallet"

What you have here is not a pallet, it's merely the source-code for one.

Stacki has a lot of Makefile-fu available and this skeleton structure makes use of it.  If you type `make` at the top level, it will recursively build rpm's and then finally an ISO which is a pallet stacki is able to import.  Unfortunately, this skeleton comes with a folder which is incomplete (./src/bob/) and does not build - deleting (or making it actually have something to build) ./src/bob and typing make will allow the pallet to build.

If you just have a bunch of RPM's the easiest way to include them in your new pallet is to simply place them in a directory under ./src/, such as ./src/RPMS

mkdir ./src/RPMS

We have a special Makefile implementation for this situation.

cat << 'EOF' > ./src/RPMS/Makefile
RPM.STRATEGY    = copy
ROLLROOT        = ../..
ROLL.MEMBERSHIP = $(ROLL)
include $(STACKBUILD)/etc/CCRules.mk
EOF

At that point, you can build the pallet and if you `stack add pallet` and `stack enable pallet` the resulting ISO in Stacki those RPM's will be available to install via yum.  However, they will not be installed automatically, or during host installation.  That will require modifying the node XML files.

The node XML files are how you can leverage stacki's own framework to control host installation.  This is a bit of a simplification: node XML files get rendered into a kickstart file (on RedHat based systems).  For more information, check out the SUX documentation (https://github.com/Teradata/stacki/wiki/Stacki-Universal-XML).

Looking in ./nodes, the default pallet setup creates a few XML files, of which `bob-client.xml` contains code that will run on backend machines which have the pallet enabled.

Open ./nodes/bob-client.xml and add some package tags toward the middle of the file for the RPM's you've added like so:

<stack:package>bob-utils</stack:package>
<stack:package>bob-devel</stack:package>

Note that these are the rpm package names, *not* the file names.

At that point, you can `rm ./src/bob/` the useless example folder if you haven't already, then cd to the root of the pallet repo and type `make`.  Depending on the size of the RPM's you've added, it may take a few minutes, but if everything goes well, you will have an ISO at `./build-bob-master/bob-1.0-redhat7.x86_64.disk1.iso` (or so).  If you add this pallet to stacki, and enable it for the default pallet, these RPM's will be installed during installation of backend nodes.

You can get fancier with the node xml -- if you have any scripts that you want to run during installation, they can run there, or if you want packages to be installed only based on some condition, you can do that as well.  The SUX documentation has more info.

If you'd like to change the version number or the name of the pallet, edit ./version.mk and modify the ROLL and VERSION values (ROLLVERSION can usually be ignored).

Hope this helps, sorry again for the delay.

Bill

[de21...@gmail.com]

Hi Bill!

thanks for the reply. this looks very comprehensive. i need time to digest it and give it a try. i'll post back with my results and questions probably next week.

thanks again
denis

[Bill Sanders]

Please do let me know if you run through it - it's fairly advanced usage but we (the stacki team) interact with custom pallets daily.  After sending these instructions yesterday, I looked up, stretched, and saw a bunch of fingers pointing at me to draft up the elusive Pallet Developer Guide.  There's actually quite a lot of functionality in pallets.

I ran through it myself last night and I have one piece of errata and a few more bits of advice.

It looks like at some point, our `stack create new pallet` command defaulted to creating pallets meant to be installed on SLES.  So you should change that particular instruction to:

stack create new pallet name=bob version=1.0 os=redhat

Note that for Stacki, we sort of sloppily interchange "redhat" and "centos".  I've got a fix coming up that defaults to the OS of the frontend running that command, instead.

A reasonable .gitignore file for our repo would be:

```
build-*-*/
src/order-*.mk
.buildenv-*
.rpmmacros
*.pyc
roll-*.xml

```

We also have a `make bootstrap` target.  Among other things, we use this one internally to actually fetch RPM's from a repository (S3, ftp, artifactory, etc) meant for holding binaries, but you *can* simply check your binaries into git -- there's issues with git and binaries (search around the web), but it certainly does work.  Just noting that.

Note that the built artifacts always appear under ./build-{pallet}-{git_branch}/.  You should be able to delete this folder at any time.  It contains the built ISO as well as individual RPM's.  If you ever want to rebuild just an RPM, you can delete it from this build directory, and then jump over to its place in the source directory and just type `make rpm`.

Along those lines we also have 'make clean', 'make nuke.all'.  These tidy up build artifacts in the tree, to different degrees.  One file they don't kill is `./src/order-{pallet}.mk` (I'm making a note to fix this).  This is the file that tracks the order in which packages should be built.  If you add a new folder under ./src/ you'll need to rm that file (it will be regenerated next time make is run).  When I was first starting to make pallets, I would constantly forget to regenerate this file -- the symptom is that it all builds just fine, but the package(s) aren't in the resulting pallet.iso.

Bill

[de21...@gmail.com]

Hi Bill!

Thanks for this update and checking back. I really appreciate your help.

i have been trying to build an iso/pallet but without success; perhaps because i'm cutting some corners ;-) I'll try to recount what i have and have not done and the results I've had. This could get long - I apologize in advance.

1. I used the 'create new pallet' command to initialize the directory tree - in the latest incarnation this is called "solo".
2. I created .../src/RPMS and copied direct a few rpms into it.
3. I created the Makefile in .../src/RPMS to copy files as you documented earlier.

NOTE: I have not created a git repo for the 'solo' directory - perhaps this is a cause of my troubles.

4. From the root of the 'solo' I issued a make command.  It ran for a bit but eventually failed. At that point I started walking through the makefiles. I did find the default to an SLES pallet and changed the code to 'redhat' (not knowing there was an option to do that).

I have attached the screen output of issuing make.

A. the first item is a complaint that .buildenv-solo/[depend,install,scripts,rcfiles].mk do not exist.
B. it starts to "build packages" (there is no source - just RPMS)
C.make copies RPMS from ...solo/src/RPMS to .../solo/build-solo-/RPMS/x86_64  (note the missing suffix on the build-solo- directory -because no git?)
D. "building rpm for solo-1.0-redhat6" followed immediately by "Cleaning before build" (but there is no source)
E. "creating.../rpmmacros" the "creating redhat build directories" and "creating source tarball" the pretar
F. repeat complaint from A adding install-rpm.mk
G. no work for pretar
H. .../solo/build-solo-/SOURCES/solo-1.0.tar.gz created containing Makefile and .mk files
I. "building rpm from source"   - no source - up to date
J. rpmbuild -bb .../SPECS/solo.spec
K. "%prep" script execution - exit 0
L. "%build" script exection - "### build ###" then an error that "solo-1.0.tar.gz" does not exist and it downhill from here.

I have included a recursive directory listing  of .../solo for reference

does the build assume that there is at least some source files to be built? 

all of our software is packaged in rpms in an rpm repo on a different server under git control. the goal is to build systems from the repo using stacki with as little duplication and transfer of the rpms as possible.

I have been manually deleting the .buildenv-solo and build-solo directories before each attempt; the clean and nuke-all targets will be helpful.i

any additional pointers gratefully accepted

denis


On Thursday, January 24, 2019 at 11:35:08 AM UTC-5, de21...@gmail.com wrote:

[de21...@gmail.com]

One more thing - i'll gladly be a guinea pig to test drive the pallet development guide if you need one.

On Thursday, January 24, 2019 at 11:35:08 AM UTC-5, de21...@gmail.com wrote:

[Bill Sanders]

What you're hoping to do is definitely achievable.  Internally, all of our pallets pull RPM's from another "canonical" source.  We also build some packages from source (pallets can ship extensions to the stack command line, for example) so there's definitely lots of flexibility here.  Let's get the proof of concept working, then we can document how you could get the pallet to fetch RPM's from the right place.  Maybe along the way we'll end up writing a draft for that pallet dev guide, heh.

From my playing around, the lack of a git repo may increase the error message noise, but it should be ignore-able.  I'm able to create and add a pallet without one.  But that leads me to a question: I was considering having create new pallet *start* with a git repo in place -- you still wouldn't need to use it, but it would be there already if you wanted it.  Is there a reason you would *not* want this, or were you just trying to move ahead without it?

Two things stick out to me:

1) it looks like you still have the broken-by-default ./src/{pallet_name}/ directory.  Since it doesn't work (it's looking for a solo-1.0.tar.gz to unpack and build) and you're not using that as a basis for anything, be sure to delete that entire sub-directory, and then delete ./src/order-{pallet_name}.mk. Run make nuke.all (ignore the ignored-but-noisy error), rm -rf ./build-solo-*/ and then make again.

2) there's references scattered around your output to redhat6, which is concerning - I have no idea if any of this works on EL6 distros anymore.  Just to make sure, this frontend is CentOS or RedHat 7, right?

If the above commands from 1) don't clear up 2), run `stack list pallet` as well as `/opt/stack/share/build/bin/os-release` and post the output.

Bill

[de21...@gmail.com]

Hi Bill!

success of a sort!!!

i editted .../solo/src/order-solo.mk removing solo from the list of SRCDIRS.

i then did a make nuke.all taking advantage of the fact that order-solo.mk is not removed

i then did a make from the top and it build an iso in .../solo/build-solo-!!

i mounted the iso and it looks "normal" but i still have the issue that the comps.xml file is not being generated in the repodata directory. i need that generated since we want to install groups defined by the developers.

i noticed someplace that generation of comps was turned off - i'll need to research that again and let you know. can i simply turn this on?

our appliance is based on centos 7.5 - i figured the centos/redhat 6 refs were an initialization issue someplace that i can address later.

progress!!!

On Thursday, January 24, 2019 at 11:35:08 AM UTC-5, de21...@gmail.com wrote:

[Bill Sanders]

So stacki doesn't support generating/including a comps.xml in a pallet.  I'm not sure how much work it would be.  However, I may have found a workaround.  There might be a more "stacki-native" approach to this problem, but this seemed to work for me.  I'll also confess here that I don't much use yum groups.

step 0: build the pallet

step 1: stack add pallet solo.iso

step 2: stack enable pallet solo.iso

step 3:

cd /export/stack/pallets/bob/1.0/redhat7/redhat/x86_64 # (path will vary, depending on your pallet name, pallet version)

cp /path/to/comps.xml .

createrepo --groupfile=comps.xml .

You'd have to do step 3 by hand, anytime you re-add the pallet.  Note the '.'s which are tiny on my screen

I'm curious what you're hoping your workflow would be?  You want to install a base CentOS automatically, hand the machine to a developer, and then they can choose to install group A vs B?  Or when you re-install a machine will you know ahead of time which group of packages it will want (like "dev vs prod" or "basic edition vs enterprise")?

Bill

[de21...@gmail.com]

Good Morning Bill!

thanks for the quick response.

i'll give this a try later today i hope.

the workflow is basically - developers will develop/update rpm packages and update the rpm repo. there are different groups defined based upon intended use of the backend machine - there will be developer backend configs, CI/CD config for automated testing, training configs and production configs. i hope to get customer configs in there too in the future.

if i can get the comps piece to work i'll be set.

i'll let you know.
thanks
denis

[de21...@gmail.com]

Hi Bill!

this did not work for me perhaps because i also copied all of the files from the pallet's repodata/repodata into repodata :-( i got an error about likely error in installation source. i'll recreate this when i can.

but i did try something else based upon our discussion and the youtube video Joe Kaiser did with 3.2.

using a CentOS 7.5 pallet that i created earlier using create pallet and a cart that included a couple of files and four groups i tried to install this to a backend system. i've attached the cart xml file and the profile output. Joe's demo used "@core" so  I expected this to work but it did not. is there a problem with the cart file? xmllint complained but a profile did not.

thanks

denis

On Tuesday, February 5, 2019 at 8:05:13 PM UTC-5, Bill Sanders wrote:

[de21...@gmail.com]

FYI - using the same iso and recreating the pallet seems to have fixed the error i saw earlier