Outcomes from weekly planning

43 views
Skip to first unread message

Andy Parker

unread,
Dec 18, 2012, 8:36:05 PM12/18/12
to puppe...@googlegroups.com
I'm a little late in sending this one out. I've been head down trying to understand #9862 and the implications of that :)

We over-committed last week and weren't able to complete everything so there aren't many new items on the list. I suspect that the same has happened this week since several people are away.

On our plate this week:

  * continuing to understand the issues related to running the acceptance tests against packages. Josh has been trying to get a handle on what exactly fails when we run them this way. We've cut back on what we are trying to accomplish immediately to just understand what is going to be wrong and then we'll take a look at how to proceed from there.
  * The documenting API work continues. Henrik and Patrick are working on Types/Providers and Faces right now. Once that is out of they way they'll move on to Reports. Those should be the major areas that we'll target for now to have as part of the 3.1 release
  * #9862 - Working on this right now. Alex Harvey has as well by the looks of the issue in redmine :)
  * Deprecation of unused settings
  * Refactor to pull out a class for `files_to_load`
  * COMMITTERS.md - I just didn't get to this last week. It is still on our plate to do.

In addition we've been pulling in pull requests that have been related to the work on code loading and settings as part of the final work for #7316.
  * PR puppet/1332 - puppet 3, rspec, and custom resources are broken
  * PR puppetlabs_spec_helper/29 - needs to initialize TestHelper
  * PR puppet/1316 - re-initialize settings metadata after run_mode determined

There has also been some discussion and review of RI's feature request about data in modules (PR puppet/1217).

The New Years present of puppet 3.1 is coming along. This should be another great release!

Andy

Dominic Cleal

unread,
Dec 19, 2012, 6:16:17 AM12/19/12
to puppe...@googlegroups.com
On 19/12/12 01:36, Andy Parker wrote:
> In addition we've been pulling in pull requests that have been related
> to the work on code loading and settings as part of the final work for
> #7316.
> * PR puppet/1332 - puppet 3, rspec, and custom resources are broken
> * PR puppetlabs_spec_helper/29 - needs to initialize TestHelper
> * PR puppet/1316 - re-initialize settings metadata after run_mode
> determined

Great, I'm looking forward to this working! I recently hit a very
similar issue on 2.7.20 where types wouldn't load when using rspec, but
it was caused by something different. I'd appreciate it if this PR
could be looked at soon, so it's fixed in case there's another 2.7.x
release:

https://projects.puppetlabs.com/issues/18187
https://github.com/puppetlabs/puppet/pull/1339

--
Dominic Cleal
Red Hat Engineering

Alex Harvey

unread,
Dec 19, 2012, 9:27:49 AM12/19/12
to puppe...@googlegroups.com
On Wednesday, December 19, 2012 12:36:05 PM UTC+11, Andy Parker wrote:

I'm a little late in sending this one out. I've been head down trying to understand #9862 and the implications of that :)
[...]
  * #9862 - Working on this right now. Alex Harvey has as well by the looks of the issue in redmine :)

To be honest I discovered #9862 several months ago while I was trying to figure out why puppet 2.7 wasn't working on my Solaris 2.6 test host.  I didn't know there was an open bug for it and just assumed it was something to do with me being stupid expecting puppet to run on Solaris 2.6.  Eventually I decided 'no such group' was a red herring and a different solution to that problem emerged.  Still, I did wonder at length why there would be a method 'service_user_available?' but no similar method 'service_group_available?'.

I rediscovered it the other day after the same bug apparently was now stopping every host in my development environment from working after upgrading to puppet 3.  Being no less stubborn I couldn't bring myself to put a group 'puppet' on all my hosts that otherwise wouldn't do anything.  But what are the chances you would be personally trying to figure out the exact same issue out at the exact same time?

And having now looked at your solution, I tried to solve it almost exactly the same way too - I also cloned service_user_available to make a service_group_available? - except it didn't work for me because I had no method group.exists? and didn't know what to do.  So I threw my hands in the air and wrote that lengthy update to the redmine ticket whereas I now see all I needed to do was put user.rb and group.rb next to each other in a text editor and the last piece of the puzzle would have been obvious! :)

(And true, I didn't spot that other issue you did that caused you to add the if ... elsif ... else block.  Still. :)

Andy Parker

unread,
Dec 19, 2012, 1:20:24 PM12/19/12
to puppe...@googlegroups.com
On Wed, Dec 19, 2012 at 6:27 AM, Alex Harvey <alexh...@gmail.com> wrote:
On Wednesday, December 19, 2012 12:36:05 PM UTC+11, Andy Parker wrote:

I'm a little late in sending this one out. I've been head down trying to understand #9862 and the implications of that :)
[...]
  * #9862 - Working on this right now. Alex Harvey has as well by the looks of the issue in redmine :)

To be honest I discovered #9862 several months ago while I was trying to figure out why puppet 2.7 wasn't working on my Solaris 2.6 test host.  I didn't know there was an open bug for it and just assumed it was something to do with me being stupid expecting puppet to run on Solaris 2.6.  Eventually I decided 'no such group' was a red herring and a different solution to that problem emerged.  Still, I did wonder at length why there would be a method 'service_user_available?' but no similar method 'service_group_available?'.

I rediscovered it the other day after the same bug apparently was now stopping every host in my development environment from working after upgrading to puppet 3.  Being no less stubborn I couldn't bring myself to put a group 'puppet' on all my hosts that otherwise wouldn't do anything.  But what are the chances you would be personally trying to figure out the exact same issue out at the exact same time?


I had actually had the bug open to update as I was looking into it and was typing in things I found as I went through. When I tried to submit, it said that the bug had been changed. I updated and found your amazingly complete writeup that outlined what I had just found :)
 
And having now looked at your solution, I tried to solve it almost exactly the same way too - I also cloned service_user_available to make a service_group_available? - except it didn't work for me because I had no method group.exists? and didn't know what to do.  So I threw my hands in the air and wrote that lengthy update to the redmine ticket whereas I now see all I needed to do was put user.rb and group.rb next to each other in a text editor and the last piece of the puzzle would have been obvious! :)

It took a few minutes for me to figure out that the user type had been hacked to allow this use of it. I felt dirty doing it to group too, but I couldn't see another way. I suppose I could call "user.provider.exists?" instead of creating the method on user/group, but I'm not sure if I like that either. Exposing the method on the type seemed like the least objectionable way and seems to point to a need for types to expose methods for manipulating and querying the resource programatically.
 

(And true, I didn't spot that other issue you did that caused you to add the if ... elsif ... else block.  Still. :)
 
Have you tried the branch ? Does it fix the problems in your situation?

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-dev/-/lFPanbYgbGgJ.

To post to this group, send email to puppe...@googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

Andy Parker

unread,
Dec 19, 2012, 2:04:17 PM12/19/12
to puppe...@googlegroups.com
I just took a quick look and added a comment. I'll leave it to Jeff to handle it though.

On the status of 2.7.x, I was hoping that 2.7.20 would be the last release barring any big bugs or security problems. Do you think this is a big enough issue to warrant a 2.7.21?
 


--
Dominic Cleal
Red Hat Engineering

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.

Dominic Cleal

unread,
Dec 20, 2012, 7:15:49 AM12/20/12
to puppe...@googlegroups.com
On 19/12/12 19:04, Andy Parker wrote:
> On Wed, Dec 19, 2012 at 3:16 AM, Dominic Cleal <dcl...@redhat.com
> <mailto:dcl...@redhat.com>> wrote:
>
> On 19/12/12 01:36, Andy Parker wrote:
> > In addition we've been pulling in pull requests that have been related
> > to the work on code loading and settings as part of the final work for
> > #7316.
> > * PR puppet/1332 - puppet 3, rspec, and custom resources are broken
> > * PR puppetlabs_spec_helper/29 - needs to initialize TestHelper
> > * PR puppet/1316 - re-initialize settings metadata after run_mode
> > determined
>
> Great, I'm looking forward to this working! I recently hit a very
> similar issue on 2.7.20 where types wouldn't load when using rspec, but
> it was caused by something different. I'd appreciate it if this PR
> could be looked at soon, so it's fixed in case there's another 2.7.x
> release:
>
> https://projects.puppetlabs.com/issues/18187
> https://github.com/puppetlabs/puppet/pull/1339
>
>
> I just took a quick look and added a comment. I'll leave it to Jeff to
> handle it though.

Thanks.

> On the status of 2.7.x, I was hoping that 2.7.20 would be the last
> release barring any big bugs or security problems. Do you think this is
> a big enough issue to warrant a 2.7.21?

I don't think so, it only affects testing of modules with types. My
hope was it could go into the tree, in preparation for a security release.
Reply all
Reply to author
Forward
0 new messages