Re: [Puppet-dev] Non-breaking changes and puppet 3.7.x
Le 04/12/2014 22:24, Kylo Ginsberg a écrit : So Charlie, Spencer, Eric0 and I just had a quick convo on #puppet-dev about where non-breaking changes to puppet should land, given that the transition to puppet 4 will take a while for many sites. The tldr was the proposal that: * non-breaking changes should default to 3.7.x until some time passes after 4.0 is out For PRs, this implies a bit of a change to our SOP (which makes sense since that SOP was pretty driven by the last 2.5 years of 3.y releases). I.e. the SOP has been, roughly: only regressions in the last Y go to stable, new bug fixes and features go to master. Why not creating a 3.8 release which will be 3.7 + non-breaking changes from 4.0 ? This will be more compliant with your SOP and more understandable for users. Instead of having a 3.7.8, 3.7.9 which will introduce new features, etc... Aurélien -- 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/5481699A.60104%40cea.fr. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Handling Interdependent Files in a typeprovider
Fellow Humans! i would like solicit your expert knowledge in designing a type provider for Apache Traffic Server's [storage.config](http://trafficserver.readthedocs.org/en/latest/reference/configuration/storage.config.en.html) The basic outline of my general idea, which i implemented with finch's Filemapper, and finch's help(!) can be found here: type: https://github.com/Brainsware/puppet-trafficserver/blob/types/lib/puppet/type/trafficserver_storage.rb provider baseclass: https://github.com/Brainsware/puppet-trafficserver/blob/types/lib/puppet/provider/trafficserver_storage.rb (literally, a class, this was finch's idea ;) provider for linux: https://github.com/Brainsware/puppet-trafficserver/blob/types/lib/puppet/provider/trafficserver_storage/udev_storage.rb (ignore it for now;) now the problem that i'm trying to solve is as follows: storage.config *drives* the configuration process: when it changes, *something* on the system changes too. this could either mean a * directory needs to be created and chowned to the correct user * udev|devfs entry needs to be made and udev needs to be reloaded the first case is easy and platform independent (i.e.: it works on all Unix platforms equally, and traffic server only runs on Unix, so it's fine ;) the second case however is more problematic as it means we need to keep two syntactically distinct files in sync. it also means that we need to verify, and possibly recreate that secondary file if *nothing* in the primary file at all has changed. now, from what i gather, a provider cannot be split on a line-by line basis, but maybe i'm wrong there. in my design above i integrated the directory case - as an if statement - into the base provider. Considering all the things i've learned about refactoring in the past three months, this strikes me now as a profoundly bad move ;) as for the second case, at least with filemapper, this is really hard to do: the udev/devfs files would have to be handled in ruby, rather than in filemapper, if i use inheritance. and so i'm stuck, and would like some advise on how to handle this properly. thank you very much in advance. -- o/~ i Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641 -- 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/122470397.139030.1417771731123.JavaMail.zimbra%40brainsware.org. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Handling Interdependent Files in a typeprovider
On 12/05/2014 10:28 AM, Igor Galić wrote: * directory needs to be created and chowned to the correct user * udev|devfs entry needs to be made and udev needs to be reloaded the first case is easy and platform independent (i.e.: it works on all Unix platforms equally, and traffic server only runs on Unix, so it's fine ;) the second case however is more problematic as it means we need to keep two syntactically distinct files in sync. it also means that we need to verify, and possibly recreate that secondary file if *nothing* in the primary file at all has changed. Hi, I'm not sure that I fully understand a problem, but if at all possible, I like to try and solve such things by generating additional resources. The idea is roughly: * add a generate hook to the trafficserver_storage type * make it invariably generate a file resource for the directory * depending on the agent platform, it can * generate file resources for the udev config * generate a service resource for the udev refresh If the user manages any of those in their own manifest, the respective resource will not be added to the catalog. This might be problematic, of course. For the service reload, but you might be able to accomodate using Trevors autonotify hooks. As for the files, those might fail silently (fail only if the manifest manages a state that is not sufficient for your type's needs;, otherwise it will Just Work). You might want to raise exceptions if the files are managed already, so that the user is aware of possible trouble. (You could even inspect the resources in the catalog and raise very specific problems that the user can address in their manifest.) HTH, Felix -- 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/5481894B.8040603%40alumni.tu-berlin.de. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?
On 2014-12-03 22:42, Rob Reynolds wrote: For the other items, please create tickets (feel free to point back to this discussion) and we can get them prioritized. Thanks! You mean, like https://tickets.puppetlabs.com/browse/PUP-1298 back from 2013. Or http://projects.puppetlabs.com/issues/7241 from 2011? Regards, David -- * Always looking for people I can help with awesome projects * Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt Blog: http://club.black.co.at/log/ LinkedIn: http://at.linkedin.com/in/davidschmitt -- 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/5481AE10.6090906%40dasz.at. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?
On Fri, Dec 5, 2014 at 7:07 AM, David Schmitt da...@dasz.at wrote: On 2014-12-03 22:42, Rob Reynolds wrote: For the other items, please create tickets (feel free to point back to this discussion) and we can get them prioritized. Thanks! You mean, like https://tickets.puppetlabs.com/browse/PUP-1298 back from 2013. Or http://projects.puppetlabs.com/issues/7241 from 2011? I just bumped the one only on redmine over to https://tickets.puppetlabs.com/browse/PUP-3745. Of course these would already exist. :) Regards, David -- * Always looking for people I can help with awesome projects * Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt Blog: http://club.black.co.at/log/ LinkedIn: http://at.linkedin.com/in/davidschmitt -- 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/5481AE10.6090906%40dasz.at. For more options, visit https://groups.google.com/d/optout. -- Rob Reynolds Developer, Puppet Labs *Join us at **PuppetConf 2015, October 5-9 in Portland, OR - * http://2015.puppetconf.com/ *Register early to save 40%!* -- 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/CAMJiBK5YeV%2BRO7in5KnbXdigbPms69Sv4ghMgcVjMG%3DwCP0K4A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Re: Non-breaking changes and puppet 3.7.x
On 2014-05-12 3:56, Kylo Ginsberg wrote: On Thu, Dec 4, 2014 at 3:46 PM, Henrik Lindberg henrik.lindb...@cloudsmith.com mailto:henrik.lindb...@cloudsmith.com wrote: On 2014-04-12 22:24, Kylo Ginsberg wrote: * non-breaking changes should default to 3.7.x until some time passes after 4.0 is out Eh, no, not in general please. We have lots of code removal and anything that needs to go through the process of being implemented both an old and a new way should not be done at all on stable IMO except if there is burning need / bug. We have removed lots of code to save us work, remove complexity etc. I am fine with non-breaking /bug fixes/ should default to 3.7.x until some time passes after 4.0 is out. Ah yes, I agree. I was thinking bug fixes specifically (but the wrong words came out). Maybe the criteria are more like non-breaking bug fixes, not in support of any deprecated features, and trivially merged up to 4.x or some such. There is no need to rename branches. I *think* we'd still need an additional branch if we want to support any level of changes to 3.7.x after 4.0 is released b/c we'd have: * branch for 3.7.x * branch for 4.0.x * branch for 4.1/5.0 which could be named 3.7.x/stable/master respectively (although we should discuss Josh H's comment too). Or am I missing your point here? You are right when we reach 4.0.0, we will use stable for 4.0.x, and master for 4.x, so we do need a 3.7.x branch. The workflow will be backwards compatible bugfixes that do not involve removed features go to 3.7.x, then stable, and then master. And as you said, the work is really setting up CI and have the extra 3.7.x branch being managed. - henrik -- 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/m5snkc%24bn2%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] beaker 2.0 and beaker-rspec 4.0 released
beaker 2.0 and beaker-rspec 4.0 are now released and available publicly from rubygems. These updates to beaker and beaker-rspec EOL ruby 1.8, update minitest dependency and provide a long list of improvements and bug fixes. See here for the complete rundown: https://github.com/puppetlabs/beaker/blob/master/HISTORY.md#LATEST If you have any questions please follow up here, on freenode irc #puppet-dev, or email al...@puppetlabs.com. alice. -- 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/0e44bac2-6024-45df-9926-6f8dce0bee73%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Re: beaker 2.0 and beaker-rspec 4.0 released
Awesome! Off to go pull it down and give it a spin! On Friday, December 5, 2014 4:47:49 PM UTC-6, Alice Nodelman wrote: beaker 2.0 and beaker-rspec 4.0 are now released and available publicly from rubygems. These updates to beaker and beaker-rspec EOL ruby 1.8, update minitest dependency and provide a long list of improvements and bug fixes. See here for the complete rundown: https://github.com/puppetlabs/beaker/blob/master/HISTORY.md#LATEST If you have any questions please follow up here, on freenode irc #puppet-dev, or email al...@puppetlabs.com javascript:. alice. -- 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/7e497063-3b1f-4e13-96ba-19caf3331010%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Non-breaking changes and puppet 3.7.x
On Fri, Dec 5, 2014 at 12:15 AM, DEGREMONT Aurelien aurelien.degrem...@cea.fr wrote: Le 04/12/2014 22:24, Kylo Ginsberg a écrit : So Charlie, Spencer, Eric0 and I just had a quick convo on #puppet-dev about where non-breaking changes to puppet should land, given that the transition to puppet 4 will take a while for many sites. The tldr was the proposal that: * non-breaking changes should default to 3.7.x until some time passes after 4.0 is out For PRs, this implies a bit of a change to our SOP (which makes sense since that SOP was pretty driven by the last 2.5 years of 3.y releases). I.e. the SOP has been, roughly: only regressions in the last Y go to stable, new bug fixes and features go to master. Why not creating a 3.8 release which will be 3.7 + non-breaking changes from 4.0 ? This will be more compliant with your SOP and more understandable for users. Instead of having a 3.7.8, 3.7.9 which will introduce new features, etc... I'm hoping this was answered elsewhere in the thread, but: 3.7.x would be for *bug fixes*, not for new features. New features would be introduced in master as today. Apologies for the confusion in my initial wording. Kylo Aurélien -- 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/5481699A.60104%40cea.fr https://groups.google.com/d/msgid/puppet-dev/5481699A.60104%40cea.fr?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- Kylo Ginsberg | k...@puppetlabs.com | irc: kylo | twitter: @kylog *Join us at **PuppetConf 2015, October 5-9 in Portland, OR - * http://2015.puppetconf.com. *Register early to save 40%!* -- 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/CALsUZFEO2M6MNFE4RiANZ%3DRJOBicKVtrhGDxSR_P-hY3sUzo0g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
