On 19 February 2014 17:14, Nan Liu <[email protected]> wrote: > On Wed, Feb 19, 2014 at 11:55 AM, Andy Parker <[email protected]> wrote: > >> This time was a little more relax and slow. Lots of things piling up in >> the backlog of actions… :( We have started punting a lot of these to the >> 3.6 timeframe. Many are good changes, but with the effort to get 3.5 out we >> don't want to take on more work right now. >> >> There were several discussions about things that were not directly >> related to PRs that we triaged. Those have been recorded below. >> >> Joined: >> >> zaphod42 (Andy), nanlie (Nan), hlindberg (Henrik), cyis (Jeremy), kbarber >> (Ken), joshcooper (Josh), ashp (Ashley), adreyer (Alex), petems (Petems), >> csharpsteen (Charlie), hunner (Hunter) >> > > Fix, irc: nanliu > > >> Items in strikethrough are closed so can come off the review list next >> week. >> Puppet: >> Held over 6x: >> 2200: It would cause a regression. Contributor pinged. Need some >> guidance on how to proceed. *Peter* and *Kylo* to work on this. Work >> continues with the discussion around how to handle versions. *Kylo* will >> carry the discussion over to puppet-dev. *Kylo* to continue discussion. >> Unfortunately we have a decision between regressing and moving to something >> else that we don't have enough information about versioning on this version >> of solaris… Nan had some information and options on this. *Nan* will >> respond to email with some info. >> *http://docs.oracle.com/cd/E26502_01/html/E28984/ghyer.html#fmri >> <http://docs.oracle.com/cd/E26502_01/html/E28984/ghyer.html#fmri>* >> > > Commented in PR 2200, basically changing version insync? behavior to regex > match leading values seem most appropriate for Solaris 11 pkg (due to noted > regression with timestamp). Since we do not want to introduce this behavior > to all packages, I suggested implementing insync? in pkg provider, and the > type check if the provider respond to insync? and use it as override. > > Held over 4x: >> Puppet: >> 2086: *Ashley* and *Adrien* will work out the details. Looks good. Want >> to change the provider name from ruby to ini file. Still in progress but >> might make it in in the coming week. >> Merged!!@!!!!!!!!!#@!!!!#@!!@@!##@$!$!@#@!#$!@#$ >> 2276: Looks ok, but we need a little bit of backstory to justify that we >> can actually do this and needs a ticket. *Adrien* to look into. Give the >> contributor another week. *Adrien* will ping contributor again about >> info. If we get no response then we will do the investigation ourselves. >> Held over 3x: >> >> Puppet: >> >> 2247 - looks good but substantial, try to pull into this week's >> iteration. Got pushed out because of over commitments. Because of the >> timeline for 3.5 and the number of items left, this is going to have to >> wait for 3.6 :( >> >> Held over 2x: >> >> Puppet: >> >> 1974: We'd like to see this changed to use the package_settings property >> and clean up the logic (the "permutations" wording is very confusing and >> not at all clear what it is trying to achieve). *Kylo* to put in the >> feedback. Feedback was incomplete. *Adrien* to flesh out Waiting on >> contributor. Taking off list for now. >> >> 2012: It is doing more than just install options. In fact one of the +1s >> on the issue wouldn't work because of this. *Josh* is commenting. Sent >> back to contributor because it doesn't get the desired functionality. >> >> 2023: Need to squash up and rework the commits. *Adrien* to take, fix >> up, to a little validation and merge in (BSD is another area where we'll >> take what people want) Handing over to *Peter Merged* >> >> 2026: *Adrien* and *Ashley* to go over it. Ask *Charlie* take a look. >> We'll just fix it up time permitting. If anyone else can do it that would >> make it more likely. *Josh* will take the one change about the missing >> method. The rest is fixing the wrong issue. >> >> 2033: We'd love to get this in. Jasperla got stuck on tests and we don't >> have capacity to get this in right now. Probably in the 3.6 timeframe. >> >> 2050: Sending back to *Felix* to fix up the error messages to be clearer. >> *Joshua* to do a small test fixup and merge it in Merged! >> >> 2067: *Adrien* added comment asking about the removing of quoting the >> value. *Felix* will try it out on sure box he has. This needs to be >> pushed to the 3.6 timeframe >> >> Held over 1x: >> >> Puppet: >> >> 2348: Some minor fixups. *Petems* will handle. After some discussion, >> this will continue in a module >> >> 2257: Looks good. *Rob* merged it in Merged >> >> 2328: Msgpack for on-disk serialization. *Henrik* merged it in. Merged >> >> 2347: Looks good. *Charlie* will merge it in Merged >> >> 2117: Mostly good. Some changes to how it looks up what parser it is >> using are wanted. *Felix* will fix up. *Andy* will merge in. Pushed to >> 3.6 and made part of PUP-410. >> >> New: >> >> Discussion: default providers in stdlib. Need to be able to specify >> default providers that are independent of facts. Suggest that we need to >> improve the power of the default and confine for puppet providers. >> > > Ticket created: > https://tickets.puppetlabs.com/browse/PUP-1738 > > This is related to creating a permanent solution to: > https://github.com/puppetlabs/puppetlabs-stdlib/pull/204/ > > I will make an attempt at a patch, but likely will get into the weeds of > type.rb. > > 2363: HTTPS and FTP support for yumrepo. *Henrik* will merge it in. Merged >> >> 2336: *Alex* will take a look and comment on what else to do. >> >> 2342: Cron….again. Looks ok. Fixes a regression introduced by earlier >> crontab fixes. *Charlie* to take a look and merge if good. >> >> 2364: After a lot of discussion back and forth, the overall feature >> doesn't seem to fit well into puppet. *Hunter* will write up the >> concerns on the ticket and close the PR. >> >> Discussion: dynamic scoping of resource defaults. Erik would like to see >> them gone. Felix brings up a discussion that happened in Ghent with Luke >> and Deepak where the decision was that they are value and widely used on >> forge modules. Henrik: what is the use case? Erik: the same as dynamic >> scoping of vars, "send things into classes without specifying parameters". >> Hunter can't think of a case where he has used resource defaults that >> wouldn't have adverse with effects with modules being used. Henrik: we are >> going to have to change all of the internals for puppet 4, so we can >> address this in puppet 4 and do it one way or the other. Getting rid of >> dynamic scoping because it is dangerous. Felix thinks that they aren't >> often used for thinks like File, but are often used with user created >> defined types. >> > > TL;DR, this goes a bit too far trying to 'safe guard' the user. > > So one of the suggested workaround to PUP-1738 was to use resource > defaults in site.pp. So here's a use case: > > File_line { > provider => ruby, > } > > One of the users thread a while back said he would prefer the ability to > set resource default behaviors globally, and removing dynamic scoping would > eliminate any ability to do this. Starting to feel like I'm always the > corner case in these situations :P. > > > No, removing it means they behave the same as for variables, so they are either global or local. But not passed on through include statements etc.
-- Erik Dalén -- 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/CAAAzDLeEen10S0za4KmXUv0QWm_LOM3JhEjgxgY_FFO2kv1WLw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
