It is apparently hosted at safe-mbox.org:

$ dig +nocomment +nostats cloud-foundations.org

; <<>> DiG 9.10.6 <<>> +nocomment +nostats cloud-foundations.org
;; global options: +cmd
;cloud-foundations.org.         IN      A
cloud-foundations.org.  864     IN      A       45.55.5.21
$ dig +nocomment +nostats safe-mbox.com

; <<>> DiG 9.10.6 <<>> +nocomment +nostats safe-mbox.com
;; global options: +cmd
;safe-mbox.com.                 IN      A
safe-mbox.com.          864     IN      A       45.55.5.21

I wanted to learn more about the organization currently holding the copyright since we only recently learned this repository moved from https://github.com/Symantec/Dominator and updated our dependencies. I found your homepage @rgooch: https://www.safe-mbox.com/~rgooch/

Currently if you want to have your resolv.conf configured during your image build a few unexpected things happen.

1. If you configure resolv.conf with the files folder it will be overwritten right away by the internal copy of resolv.conf from the host system.
2. If you configure resolve.conf in post-install-files it will be overwritten by /dev/null shortly after.

It would be nice if this was only managed in the filters file as this seems to be an exception to that during the image build process. In our case we have an anycast IP that would be nice to control in a single location.

go: downloading github.com/go-fsnotify/fsnotify v0.0.0-20180321022601-755488143dae
github.com/Cloud-Foundations/keymaster/eventmon/eventrecorder imports
github.com/Cloud-Foundations/Dominator/lib/fsutil imports
gopkg.in/fsnotify/fsnotify.v0 tested by
gopkg.in/fsnotify/fsnotify.v0.test imports
github.com/go-fsnotify/fsnotify: module github.com/go-fsnotify/fsnotify@latest found (v0.0.0-20180321022601-755488143dae), but does not contain package github.com/go-fsnotify/fsnotify

I believe this is unintended behavior or at least unexpected to me when I was testing out an image build. If you have a base image that you are building on top of and the manifest being used has no filter or filter.add (same for triggers) the build image will show Image has no filter: sparse image.

It's easy enough to add in an empty filter.add file but it's a little unexpected and has caused some confusion for users.

Can we change this so that if no *.add file is present the source image filters/triggers are propagated.

I'm not sure if this falls under documentation or a bug but it has me a bit confused so I wanted to check if my understanding was correct before looking into it more.

I am building a bootstrap image that has the following filter lines defined.

	    "FilterLines": [
		"/etc/fstab",
		"/etc/hostname",
		"/etc/machine-id",
		"/data(|/.*)$",
		"/var/log/.*",
		"/var/mail",
		"/var/spool/mail"
	    ]

I have an image that inherits from this image and defines only a filter.add file. No filter file exists in the git repo when building.

When i deploy this to one of my subs for testing I get the following update loop that keeps on happening.

2019/11/22 21:13:01 Fetch(10.131.135.76:6971) 5 objects at unlimited speed
2019/11/22 21:13:01 Fetch() complete. Read: 38364 B in 443µs (84482 KiB/s)
2019/11/22 21:13:01 Boosting CPU limit: 100%
2019/11/22 21:13:02 Update()
2019/11/22 21:13:02 Made inode: /home/admin/test/.subd/root/var/log/alternatives.log from: 02df44f4aa2956aaf0a087d66090e093c6e10dfb9514dd0648cdc55fa6b4c266006d57b24acdde2657b25410c2ff5959554dd348974c0e5ec669a4e97a30caa2
2019/11/22 21:13:02 Made inode: /home/admin/test/.subd/root/var/log/apt/eipp.log.xz from: a58fa549fd8814fb7c4728667f915cfd04b44cbefbc8909ff98bf66a81a9cf7b928809c715a5bb59f9149e346e3a0bd1b35bb6ec1300ffe048b9892ae6bc56d3
2019/11/22 21:13:02 Made inode: /home/admin/test/.subd/root/var/log/apt/history.log from: c71c4e4b259ef78749f0737120f545c05c2d56740c4ec5770a4f859007b0c6f924e9da53565270d86b1faefc5786d24e14c8c924762c64f2669f14779003ae3c
2019/11/22 21:13:02 Made inode: /home/admin/test/.subd/root/var/log/apt/term.log from: 6fedf96409a5bf21fbefd6f05d6c15689bb55da7916ab3d522924aa2d9f2dc23f4e3f60c00a5d8e38464691d46eeae57734fdfbc71df84dda7df89dc766dc777
2019/11/22 21:13:02 Made inode: /home/admin/test/.subd/root/var/log/dpkg.log from: cb4a2cd397dd4447f1605295f48c0c4e548ab950a62741a8542c9f66574189885847564bf8d7255964d5372f5b4040c30d59766d3265eaab408a0fc9d6f0554d
2019/11/22 21:13:02 Update() completed in 527.727µs (change window: 506.367µs)
2019/11/22 21:13:03 Restoring CPU limit: 8%

This sub is using the default exclude files constants. I would expect that these files don't show up or try to be placed on the file system at all since they are filtered in the bootstrap image. Additionally I can tell /etc/fstab is properly excluded in the inherited image.

Currently if your SourceImage has computed-files specified they are not passed on to the current building image. An example use case could be for generating your /etc/hostname or /etc/motd file dynamically.

It seems like computed-files would be propagated and just a single computed-files would suffice or should the same convention be followed to give users the ability to add or override computed files via computed-files and computed-files.add.

From @rgooch on slack

Indeed, following the same pattern as filters and triggers would give the most flexibility. You then get three possibilities:

1. no computed files (replaced with zero-length regular files);
2. specify a new set of computed files (existing computed files that are not listed would be replaced with zero-length regular files);
3. add more computed files (changing the Source location for ones that are inherited).

Summary
We we have a large mdb.json file, say 100+, the dominator binary throws off a data race, when ran under the race detector.

this race condition seems to originate in dom/herd package, where a lot of read/writes are happening in a concurrency unsafe manner in the sub.go file, under methods connectAndPoll.

this originates from the usage of the derived datatype subStatus.

Is there any plan on addressing these data races, and leverage atomic operations for read/writes?

Expected behavior:

• Invoke subd
• subd starts

Actual behavior:

• Invoke subd
• subd can't find the device path for the filesystem and refuses to start.

Sample error message:

# ./subd -certFile ./subd.pem -keyFile ./subd.key.pem -alsoLogToStderr -initialLogDebugLevel 100 -subdDir .subd -rootDir /
Mounted tmpfs on: /.subd/tmp
Unable to measure read speed: unable to find device path for: /.subd/root

Some different ways of looking at the root filesystem in question:

# df -h /
Filesystem         Size  Used Avail Use% Mounted on
rpool/ROOT/buster   76G  758M   76G   1% /
# mount | grep ROOT
rpool/ROOT/buster on / type zfs (rw,relatime,xattr,noacl)
# zfs list rpool/ROOT/buster
NAME                USED  AVAIL     REFER  MOUNTPOINT
rpool/ROOT/buster   758M  75.0G      758M  /

This zpool happens to be on a single block device:

# zpool status rpool
  pool: rpool
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          vda1      ONLINE       0     0     0

errors: No known data errors

It should be noted, however, that ZFS supports other disk configurations too.

Of course, for entertainment purposes (not an acceptable workaround), when given an ext4 filesystem formatted on top of a zvol, subd is satisfied:

# zfs list -t volume
NAME            USED  AVAIL     REFER  MOUNTPOINT
rpool/testvol  20.6G  95.6G     2.50M  -

# ls -l /dev/zvol/rpool/testvol
lrwxrwxrwx 1 root root 9 Dec 11 18:46 /dev/zvol/rpool/testvol -> ../../zd0

# mount | grep ext4
/dev/zd0 on /var/cache/subd-test type ext4 (rw,relatime,stripe=2)

# df -h /var/cache/subd-test/
Filesystem      Size  Used Avail Use% Mounted on
/dev/zd0         20G   45M   19G   1% /var/cache/subd-test

# ./subd -certFile ./subd.pem -keyFile ./subd.key.pem -alsoLogToStderr -initialLogDebugLevel 100 -subdDir .subd -rootDir /var/cache/subd-test
Mounted tmpfs on: /var/cache/subd-test/.subd/tmp
2019/12/11 18:47:24 Restoring CPU limit: 50% 
2019/12/11 18:47:53 reverse listener: remember(redacted): 0xc000010008
2019/12/11 18:58:37 reverse listener: forget(redacted)

This is a duplicate of Symantec/Dominator#432 that I am moving over to this repo.

Of relevance in that ticket is the following from @rgooch.

I'm not really keen on that. I consider the tricorder/Scotty ecosystem a better solution (it supports more than floats and has a better UI for humans to discover and explore the available metrics for an application), and it follows the vision of more integrations in the metrics space (like integrating with the health-agent for health checking during rollouts). Also, I don't want to add another code dependency and bloat out the system. Note also that the tricorder library creates a /metrics endpoint already.

What might be a good alternative is to add the ability to push metrics from Scotty to Prometheus. The advantage of this approach is that none of the Dominator ecosystem components need to be changed.

Please take a look:
https://github.com/Symantec/scotty
https://docs.google.com/document/d/e/2PACX-1vQPhkHYiLK7aKHLECa9EFtSCBSPK-obgGB8C66d72Kl-ej9NikRKYGsuFj1R9aDTlGiZA7OmXrVw8P3/pub

Is this still the correct path to take for getting prom style metrics out of dominator in a way that can be contributed back upstream? I think some additional conversation may need to happen in the scotty repo mostly around prom scraping scotty instead of scotty pushing to it if that is an option.