Review Board 1.7.22


BIGTOP-939. Make usage of bigtop-tomcat more dynamic

Review Request #12526 - Created July 12, 2013 and updated

Sean Mackrory
master
BIGTOP-939
Reviewers
bigtop
mgrover
bigtop
Explained on JIRA - uploaded here only for commenting convenience.
Explained on JIRA - uploaded here only for commenting convenience.
Posted (July 12, 2013, 11:09 p.m.)

   

  
Should this be	
chmod 644 $HTTPFS_ETC_DIR/conf.empty/tomcat-deployment/conf/*?
The old code shows that we need to change 2 xml files for ssl configuration - web.xml and server.xml.

You only seem to be changing web.xml. Should we change server.xml as well here (you seem to be changing that in the init script)?
Should we have a default webapps symlink (pointing to the non-SSL configuration) out of the box? It would get copied over when we do cp -r in the init script.
I think we should forcefully remove the symlink to be on the safe side before we create it. Alternatively, we can force create the symlink, overriding the previous symlink.
Ok, so how does this work if someone wants to use their own custom configuration for oozie? Historically, we have provided that option so all users have to do is to update the alternatives symlink to their own custom config directory but this doesn't seem to be in line with that. 
extra prepending slash before ${DEPLOYMENT_TARGET}?
Posted (July 12, 2013, 11:14 p.m.)

   

  
The reason I say this is because we are referring to conf directory here. We delivered the conf.dist directory through packages. Conf dir can technically be pointing to anything. I may just be overthinking this:-)
Posted (July 15, 2013, 3:13 p.m.)

   

  
Good catch - does look like it should be. Will fix...
We shouldn't be changing it in both places, if that's what you're asking. Bruno also expressed concern about the specific "feature" in the init to enable SSL, however, so I am considering different approaches to this aspect if it.

We should not to have webapps/ under /etc/conf because it can contain binary artifacts, but this is one case where some configuration under webapps has had to change.
We shouldn't be changing it in both places, if that's what you're asking. Having a specific "feature" in the init script to deal with ssl-server.xml is something Bruno expressed concern about on Jira too, so yes I am considering other approaches to this part.
We could. I don't see much of a difference. Do you?
What effect do you think forcefully removing it will have? It's already wrapped in a conditional to see if it exists. -f is more succinct, but am I missing something in your suggestion?
What do you think forcefully removing it is going to do? It's more succinct than the existing conditional, but AFAIK there's no functional difference.
They can still use their own custom configuration, but if they're upgrading from a previous version they'll need to copy in tomcat-deployment from conf.dist, so we ought to document that somewhere. (Is there a concept of "Release Notes" in Apache releases?)

Not ideal, but all of the alternatives I can think of are much worse. We shouldn't be copying it into their custom config for them, we shouldn't leave it the way it is, etc...
Fixed. Should have no effect, though.