You are here
Eric (tssgery) - Tue, 2011/10/11 - 02:44
I took a look at the confconsole code to determine what variables allow substitution, and the only one that seems implemented is the $ipaddr variable.
It would be nice if we could also use $hostname (to display whatever 'hostname' returned).
What's the best way to submit an enhancement request, or can I submit the change myself?
Forum:
You could fork it
The confconsole code is here on GitHub so you could fork it, adjust it as you see fit and issue a oull request and hope the core devs like your changes...?! Otherwise posting here (as you have) is probably as good a thing to do as anything. The core devs read (and post on) the forums so they'll see it.
hostname substitution
An older version of confconsole used to substitute $hostname, but that was changed when we moved to using services.txt instead of usage.txt (see the commit).
The appliances hostname is still displayed though, just not via template substitution:
I saw that
In my mind, there are three substitution values that could be used effectively:
I see that the upper case hostname is shown, but it's shown as the application name. The problem with using the hostname in this manner is that if I choose to stand up two of the same appliance types... they both show the same name.
Now, I understand that this feature request is nowhere near the top of your stack. I'm happy to contribute a change back for this if it's something people are interested in. If not, I'll just apply the change to my own TKLpatches. I just didn't understand the process involved in asking for features or contributing code.
Good feedback
I think you have a good point there re the naming. I think it would be a nice feature for each one to use it's own name. But as I've mentioned in discussion on another thread, I'm not a coder - more of a tinkerer! :) So I can't really give much more input than that.
Also the point you raise about feature requests is a good one. One that can hopefully be addressed soon. The core devs have been busy with their backend changes and I think some streamlining to frontend processes (such as feature requests etc) would be a good next step once they have that sorted. I think that your input into that would be useful. I've got and had lots of ideas some which have been implemented, some which haven't but input from others is very useful I think.
I guess one of my pet hates here is that there are only 2 subforums. I think the tagging system helps, but it is still painful to just browse the forums. The core devs have argued that they want to see it kept simple and I agree with that philosophy. Sometimes forums have too many subforums that just working out the right place to post can be daunting (and offputting). But I think that at least a few subforums (things such as 'Bugs', "Feature Requests', 'TKLPatches', etc) may make casual usage of the forums a bit nicer. Initially the LaunchPad Blueprints was used along with the Dev Wiki, but they are largely untouched for some time now. So I'd see the forums suggestion I mentioned above as a better option. Would that be something that would make sense to you, or do you have some other ideas of what you think would be better?
My thoughts...
I have forked the confconsole project and implemented the ability to subsititute in the hostname for $hostname as well as the "application name" for $appname. Now, I just have to figure out how to get my changes into a patch (I am thinking it be pretty easy with a tklpatch stanza).
As far as enhancement requests go. It'd be nice if there were an active place to submit requests (blueprints woulod be fine with me). I personally don't think forums are a good place for them. Additionally, I think that enhancements should be implemented by the user community whenever possible. That is, after all, the power of open source. It would just take some definition of the process works.
The only real forum change I'd like to see is a listing of community completed TKLpatches. Merging this in with the other forums makes it a little hard to see the work that others have done.
Well lets revive the Blueprints then!
I think that is a fine place for it - I mean that's what it's designed for! And if we start using it again then it will come back to life. Perhaps I'll head over there when I get a chance and do some tidying up.
As for TKLPatches, IIRC there was a page on the Dev Wiki where they were all listed (and pointed back to the relevant forum post) but again it has not been used for some time. Otherwise the easiest way to find the patches is to use the tag 'tklpatch'. I try to make sure that all new patches have at least that tag (as they are submitted) although there are perhaps some that slip through the cracks.
Add new comment