On Wed, Dec 7, 2016 at 4:15 PM, Eric Sorenson <eric.soren...@puppet.com> wrote:
> > On Dec 5, 2016, at 2:11 PM, Trevor Vaughan <tvaug...@onyxpoint.com> 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 - eric.soren...@puppet.com > 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 puppet-dev+unsubscr...@googlegroups.com. > 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 puppet-dev+unsubscr...@googlegroups.com. 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.
