Re: Plea for eyes (and votes) on STATUS proposals
On Jan 21, 2013, at 4:09 PM, Rainer Jung rainer.j...@kippdata.de wrote: On 21.01.2013 15:26, Jim Jagielski wrote: Disabling BalancerInherit is only needed when using the Balancer Manager and only if there are conflicts between a Balancer in the top-level server and a vhost. With BI On, if a balancer is defined at the top level, then vhosts A and B get their own individual copy. But when using the Balancer Manager, it may be difficult or impossible to affect change in the balancer you want. If you use BM to change the Balancer of the top-level server, those changes do not get applied to the vhosts that had inherited them when httpd was 1st started. This can be confusing. Understood and agreed. Having BI Off ensures that: 1. All Balancers must be explicitly defined for whatever vhosts are using them 2. All changes on those Balancers affect ONLY that specific server. I find it hard to really understand what's going on after applying the patch. Many configuration items are still inherited even with BI Off, but the underlying balancers and/or workers are no longer inherited. Examples are ProxyPass or Proxy. I am unsure what kind of behavior this could lead to. For example I tested: What's important is to recall that it's just the Balancers and Workers which are affected. Nothing else. Thats the reason for the directive name-change, to make it clear that it only affects those 2 components. You would have noticed that if you had used ProxyPass /p/ http://myvhost:8080/ then even with BI Off, it would have worked in the vhost case. Again, the balancer is defined in the top level server but it's not inherited. Also note that BI *only* is of interest if people do silly things like define all their Balancers at the top level and use them only in Vhosts. If they do reasonable things, like define all Proxy-related stuff in the vhosts where they should apply, then it doesn't matter if BI is off or on. BI exists only for edge-cases, and that's why it defaults to the existing behavior; but in some, you want to be able to disable that inheritance.
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On 01/21/2013 01:02 AM, Nick Kew wrote: On 19 Jan 2013, at 23:26, Daniel Gruno wrote: Hello dear dev@, I'd like to propose that we rewrite and rethink modules.apache.org. snip As suggested by a fellow ASFer, I am going to play this a bit hard and fast, as not a lot of people really care that much about the old site in its current state. A replacement site for modules.apache.org is in the works (it's actually nearly completed already, you can see it at http://modules.humbedooh.com/ - do try it out), and as such, I'd like to propose we make the switch from the old site to the new, and start afresh with the database, as it's very lacking in its current state. Once this is done, anyone with an interest in further developing the site is most welcome to contact me, and we'll start hashing out what remains to be done (I can always think of new things to add, such as Nick's suggestion about DOAP files, possibly supporting multiple Apache projects etc). This will be done by lazy consensus; If I hear no complaints within the next 72 hours, I will consider the subject agreed upon and start upgrading the site to the new system. So, if you do have objections, I suggest you let them be heard :) But please do try out the new system before you make up your mind - it's got lots of improvements, both for visitors and module authors. With regards, Daniel.
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On 22 Jan 2013, at 22:29, Daniel Gruno wrote: This will be done by lazy consensus; If I hear no complaints within the next 72 hours, I will consider the subject agreed upon and start upgrading the site to the new system. I object! Not to the proposal: I have yet to review your candidate site. But to the 72 hour timescale. You should give it at least a weekend, and then however long it takes to resolve any discussions arising. The problem then comes when some discussion thread(s) get stuck in a dead end. Then you drop a 72-hour ultimatum on it! -- Nick Kew
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
This will be done by lazy consensus; If I hear no complaints within the next 72 hours, I will consider the subject agreed upon and start upgrading the site to the new system. So, if you do have objections, I suggest you let them be heard :) But please do try out the new system before you make up your mind - it's got lots of improvements, both for visitors and module authors. 72hr lazy consensus is not enough to scrap the site and data that we stepped up to support in the not so distant past.
RE: [Discuss] Time to rewrite/rethink modules.apache.org?
-Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Wednesday, 23 January 2013 9:25 AM To: dev@httpd.apache.org Subject: Re: [Discuss] Time to rewrite/rethink modules.apache.org? This will be done by lazy consensus; If I hear no complaints within the next 72 hours, I will consider the subject agreed upon and start upgrading the site to the new system. So, if you do have objections, I suggest you let them be heard :) But please do try out the new system before you make up your mind - it's got lots of improvements, both for visitors and module authors. 72hr lazy consensus is not enough to scrap the site and data that we stepped up to support in the not so distant past. hmm, how have you been supporting it since the code was moved to the infra repo ? svn log shows : gmcdonald: (50 commits) joes: (8 commits) danielsh: (27 commits) markt: (64 commits) igalic (2 commits) as the only folks to touch the code since we move it to ASF servers.
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On Tue, Jan 22, 2013 at 6:08 PM, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Wednesday, 23 January 2013 9:25 AM To: dev@httpd.apache.org Subject: Re: [Discuss] Time to rewrite/rethink modules.apache.org? This will be done by lazy consensus; If I hear no complaints within the next 72 hours, I will consider the subject agreed upon and start upgrading the site to the new system. So, if you do have objections, I suggest you let them be heard :) But please do try out the new system before you make up your mind - it's got lots of improvements, both for visitors and module authors. 72hr lazy consensus is not enough to scrap the site and data that we stepped up to support in the not so distant past. hmm, how have you been supporting it since the code was moved to the infra repo ? I think you're contrasting httpd vs. infra and saying we didn't live up to our end of the bargain. I'm not disagreeing with that, and I guess step up is probably a bit misleading. What I intended to convey was that people cared about this during the last reboot (whether or not we fulfilled a committment properly), and that 72h lazy was not enough consideration for them and the submitters of data. I could be totally misunderstanding you though. Do you take issue with slowing things down or is this a tangent?
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On 01/23/2013 01:00 AM, Eric Covener wrote: On Tue, Jan 22, 2013 at 6:08 PM, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Wednesday, 23 January 2013 9:25 AM To: dev@httpd.apache.org Subject: Re: [Discuss] Time to rewrite/rethink modules.apache.org? This will be done by lazy consensus; If I hear no complaints within the next 72 hours, I will consider the subject agreed upon and start upgrading the site to the new system. So, if you do have objections, I suggest you let them be heard :) But please do try out the new system before you make up your mind - it's got lots of improvements, both for visitors and module authors. 72hr lazy consensus is not enough to scrap the site and data that we stepped up to support in the not so distant past. hmm, how have you been supporting it since the code was moved to the infra repo ? I think you're contrasting httpd vs. infra and saying we didn't live up to our end of the bargain. I'm not disagreeing with that, and I guess step up is probably a bit misleading. What I intended to convey was that people cared about this during the last reboot (whether or not we fulfilled a committment properly), and that 72h lazy was not enough consideration for them and the submitters of data. I could be totally misunderstanding you though. Do you take issue with slowing things down or is this a tangent? Personally, I'm find with you guys objecting to a lazy consensus - it means this isn't just being ignored any more, as the site seems to have been for years, to be honest. The site is in a big need of an overhaul - there are no moderators for it currently, besides Gavin and me, and updates are done in the most painful way you can imagine. What I propose is a new site that lets authors update their modules in an easy, comfortable way, either manually adding new releases or managing it through a DOAP file, and which gives the visitors a better bang for their buck. The data we have on record now is stale, it's very sparse, and does not invite authors to do anything but just register the name of their module and a one-liner that'll hopefully get visitors attention - not much of a site if you ask me. I implore you to try out the new site, both as a regular visitor and as a (fake) module author, and see if this isn't a vast improvement of what we have. And I also ask you to consider, that with the new improvements, getting new module data will be a lot easier, and much of the scrapped data will surely come back in a hurry - except maybe for those modules that haven't been updated in this century or have been incorporated into httpd. So, for now, I'll withdraw my lazy consensus, and I'll instead put up a vote once the discussion has been had. This however requires some participation! With regards, Daniel.
RE: [Discuss] Time to rewrite/rethink modules.apache.org?
-Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Wednesday, 23 January 2013 10:31 AM To: dev@httpd.apache.org; Gavin McDonald Subject: Re: [Discuss] Time to rewrite/rethink modules.apache.org? On Tue, Jan 22, 2013 at 6:08 PM, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Wednesday, 23 January 2013 9:25 AM To: dev@httpd.apache.org Subject: Re: [Discuss] Time to rewrite/rethink modules.apache.org? This will be done by lazy consensus; If I hear no complaints within the next 72 hours, I will consider the subject agreed upon and start upgrading the site to the new system. So, if you do have objections, I suggest you let them be heard :) But please do try out the new system before you make up your mind - it's got lots of improvements, both for visitors and module authors. 72hr lazy consensus is not enough to scrap the site and data that we stepped up to support in the not so distant past. hmm, how have you been supporting it since the code was moved to the infra repo ? I think you're contrasting httpd vs. infra and saying we didn't live up to our end of the bargain. I'm not disagreeing with that, and I guess step up is probably a bit misleading. What I intended to convey was that people cared about this during the last reboot (whether or not we fulfilled a committment properly), and that 72h lazy was not enough consideration for them and the submitters of data. I could be totally misunderstanding you though. Do you take issue with slowing things down or is this a tangent? I don't want to start another debate here, but what I intended to say was that perhaps Daniel should just be left to get on with it seeing as no one has wanted to scratch that itch so far. Back when the modules site was move to the ASF hardware a year ago, talk back then was that it needed to be rewritten. So there's been plenty of time for others to step up between now and then. Daniel now has , and in only takes but 5 minutes to see what an improvement it is, it's a no brainer. Then, if this re-invigorates folks to jump in and help with improvements and new features then that's great too. [+] I'll agree that 72 hours [*] may not be enough for some folks if they are away or whatever, lets have Daniel extend until after the weekend then, but really no more, his itch is burning and we shouldn't stop that flow without good reason. And I don't see any good reason. Gav... [+] - I'm here with that intention , hope others do too. [*] - I planted Daniel with the suggestion of 72 hours , so blame me for that, I thought no one would dare object :)
Re: Plea for eyes (and votes) on STATUS proposals
On 1/21/2013 3:09 PM, Rainer Jung wrote: I find it hard to really understand what's going on after applying the patch. Many configuration items are still inherited even with BI Off, but the underlying balancers and/or workers are no longer inherited. Examples are ProxyPass or Proxy. I am unsure what kind of behavior this could lead to. For example I tested: ProxyPass /p/ balancer://myvhost:8080/ Proxy balancer://myvhost:8080/ BalancerMember http://myvhost:8080/ /Proxy BalancerInherit Off VirtualHost *:8080 DocumentRoot htdocs/myvhost ServerName myvhost ErrorLog logs/myvhost-error_log CustomLog logs/myvhost-access_log common /VirtualHost As usual, mileage varies. I didn't test the case of a proxypass at server level with a balancer there as well... here is my config: BalancerInherit Off Proxy balancer://mycluster BalancerMember https://127.0.0.1:4433 route=1 /Proxy ProxyPass /proxy/ balancer://mycluster/ Listen 192.168.0.103:80 VirtualHost 192.168.0.103:80 ... ProxyPass /proxy2/ balancer://mycluster/ /VirtualHost Attempts to hit /proxy/ on that vhost work every time (with BalancerInherit Off). Attempts to hit /proxy2/ return a 503 and AH01171: balancer://mycluster: No workers in balancer. I'd say that the former is definitely unexpected but the latter is fairly reasonable. There was a ProxyPassInherit as part of the original patch... maybe that needs to be revisited? -- Daniel Ruggeri
