On Wed, Dec 7, 2016 at 4:15 PM, Eric Sorenson <[email protected]> wrote:
> > On Dec 5, 2016, at 2:11 PM, Trevor Vaughan <[email protected]> wrote: > > Hi Eric, > > Unfortunately, you've now built a distribution (a very minor distribution, > but one nonetheless). As such, I would *highly* recommend following the > time honored (and massively tedious) method of having something like > collections for rolling major release updates and snapshots in time as you > roll forward. > > This is how we do it and we modeled it off of the CentOS, Ubuntu, Debian, > RedHat, Suse, etc... models where a lot of disparate moving parts need to > have some level of stability over time. > > > But you control which agents are pointed at a given repo, right? That is > kind of a fundamentally different design constraint: we want nearly > everyone to start out from the same place and to carry as many people > forward with new releases without them having to revisit their repository > setup. > Yes, but nowhere that I've been, or worked, would allow an upstream vendor to dictate the update schedule. Every update had to be mirrored, approved, tested, and scheduled. > > So, what I would find easiest to deal with would be something like keeping > the PC1, PC2, etc.... nomenclature but taking that whole hog. > > So: > > PC1 -> Latest everything in the PC1 distribution > PC1.0.0 -> Package snapshot at PC1.0.0 > PC1.0.1 -> Package snapshot at bugfix release PC1.0.1 > PC2 -> Latest everything in the PC2 distribution > PC2.0.0 -> Major breaking change from PC1.X > > > Do mean making each one of these things an entire separate repository? > With its own release package, directory structure, and package contents for > every operating system supported at that point? > Yes, this would mirror most projects that I've used and mirrors the expectation that was met by the PackageCloud team. If you're self hosting, it's usually just symlink management. > > PCX -> Insane stuff that might break, basically Fedora/Tumbleweed for > Puppet > > > I kicked around the idea of a smaller version of this for a while, but got > stuck on the problem of how to get people using the latest-and-greatest > *off* it if they wanted to stabilize onto a numbered release, and > conversely what they'd do if a repo they were on was EOL'ed and no longer > receiving security updates. > The same as Fedora/Tumbleweed/etc... Front page announcements and mailing list posts that you're going to have a bad time if you stay on release X. A lot of us patch our code from the repos on the fly because we need new features and/or want to test things. Being able to just point our test system at a repo and let it fly would be nice. > > > Etc.... > > I would definitely not recommend making it difficult for users that need > to mirror repositories for offline networks. In terms of high compliance > environments, this is pretty much all of them. > > > Is there something in the proposal that makes mirroring harder or easier > than it is today? > Maybe I'm reading it wrong, but what I need is to guarantee that I'm downloading the 'collection formerly known as PC1.0.0'. Which is difficult right now so I have a bunch of janky scripts to cobble it together. If I had snapshot repos, People that were approved to use PC1.0.0 would have a known, stable, place to start from. People that could upgrade to PC1.1.0 could point to that repository, etc... Alternatively, for YUM systems at least, you could put together a groups file that would coalesce everything in a given version. Makes it more difficult for non-yum base system sync tools to deal with though. > > Eric Sorenson - [email protected] > director of product, puppet ecosystem > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/puppet-dev/0CB30596-CCDC-44A7-B71A-266F0EDC8178%40puppet.com > <https://groups.google.com/d/msgid/puppet-dev/0CB30596-CCDC-44A7-B71A-266F0EDC8178%40puppet.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXJ55aKY29VXHAfSoTzgwrcwQcDFCdSb%3D2rXU3kh_Td%2BQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
