Location of hammer config files

i'm glad that a solution has been made where individual hammer plugins each have their own config files to avoid writing a file that it did not install, but i disagree on the placement of hammer's module-config directory.

i think that hammer's configs should not be placed inside /etc/foreman. hammer very well could be used for something that isn't foreman at all.

i'd suggest /etc/hammer/modules.d

··· -- Adam Price Software Engineer Red Hat Inc., Raleigh

adprice at redhat dot com

http://www.ohloh.net/accounts/komidore64

I tend to agree… If we can make it easy… lets do that. If I scan for
Foreman in the hammer code, there is bleed over. So. the likelyhood
today of being used is low… but it is good practice.

– bk

··· On 03/21/2014 02:08 PM, Adam Price wrote: > i'm glad that a solution has been made where individual hammer plugins each have their own config files to avoid writing a file that it did not install, but i disagree on the placement of hammer's module-config directory. > > i think that hammer's configs should not be placed inside /etc/foreman. hammer very well could be used for something that isn't foreman at all. > > i'd suggest /etc/hammer/modules.d >

+1 Hammer does not have to be foreman specific. I originally wanted to
package it this way. Martin convinced me to postpone the change as it
breaks backward compatibility. If we agree we can live with that at this
stage of development, let's go for it.

Martin, how do you see it?

T.

··· On 03/21/2014 07:11 PM, Bryan Kearney wrote: > On 03/21/2014 02:08 PM, Adam Price wrote: >> i'm glad that a solution has been made where individual hammer plugins >> each have their own config files to avoid writing a file that it did >> not install, but i disagree on the placement of hammer's module-config >> directory. >> >> i think that hammer's configs should not be placed inside >> /etc/foreman. hammer very well could be used for something that isn't >> foreman at all. >> >> i'd suggest /etc/hammer/modules.d >> > I tend to agree.. If we can make it easy.. lets do that. If I scan for > Foreman in the hammer code, there is bleed over. So. the likelyhood > today of being used is low.. but it is good practice. > > -- bk >

I agree that /etc/hammer is more proper place for the hammer config.
However it seems that quite a lot of people is already using Hammer and
upgrade to new config paths could cause problems.

I was thinking about /etc/hammer being the deafult with option to change
to anything else with $HAMMER_CONFIG_NAME env variable. That way it
could be possible to add +alias
myproject-cli='HAMMER_CONFIG_NAME=myproject hammer'+ making hammer to
read /etc/myproject and ~/.myproject. It could help to separate configs
for unrelated projects using hammer. We could use this feature to keep
the /etc/foreman as one option.

Other option is to check both (/etc/hammer and /etc/foreman) and print
warning for a couple of versions.

What would hammer users prefer?

Martin

··· On 03/24/2014 10:34 AM, Tomas Strachota wrote: > On 03/21/2014 07:11 PM, Bryan Kearney wrote: >> On 03/21/2014 02:08 PM, Adam Price wrote: >>> i'm glad that a solution has been made where individual hammer plugins >>> each have their own config files to avoid writing a file that it did >>> not install, but i disagree on the placement of hammer's module-config >>> directory. >>> >>> i think that hammer's configs should not be placed inside >>> /etc/foreman. hammer very well could be used for something that isn't >>> foreman at all. >>> >>> i'd suggest /etc/hammer/modules.d >>> >> I tend to agree.. If we can make it easy.. lets do that. If I scan for >> Foreman in the hammer code, there is bleed over. So. the likelyhood >> today of being used is low.. but it is good practice. >> >> -- bk >> > > +1 Hammer does not have to be foreman specific. I originally wanted to > package it this way. Martin convinced me to postpone the change as it > breaks backward compatibility. If we agree we can live with that at > this stage of development, let's go for it. > > Martin, how do you see it? > > T. >

IMHO… I would keep the old location for a release… and then layer the
new one on top of it. That way you dont break anything. You can warn the
folks if you are pulling the config from the deprecated location.

– bk

··· On 03/24/2014 06:25 AM, Martin Bačovský wrote: > On 03/24/2014 10:34 AM, Tomas Strachota wrote: >> On 03/21/2014 07:11 PM, Bryan Kearney wrote: >>> On 03/21/2014 02:08 PM, Adam Price wrote: >>>> i'm glad that a solution has been made where individual hammer plugins >>>> each have their own config files to avoid writing a file that it did >>>> not install, but i disagree on the placement of hammer's module-config >>>> directory. >>>> >>>> i think that hammer's configs should not be placed inside >>>> /etc/foreman. hammer very well could be used for something that isn't >>>> foreman at all. >>>> >>>> i'd suggest /etc/hammer/modules.d >>>> >>> I tend to agree.. If we can make it easy.. lets do that. If I scan for >>> Foreman in the hammer code, there is bleed over. So. the likelyhood >>> today of being used is low.. but it is good practice. >>> >>> -- bk >>> >> >> +1 Hammer does not have to be foreman specific. I originally wanted to >> package it this way. Martin convinced me to postpone the change as it >> breaks backward compatibility. If we agree we can live with that at >> this stage of development, let's go for it. >> >> Martin, how do you see it? >> >> T. >> > I agree that /etc/hammer is more proper place for the hammer config. > However it seems that quite a lot of people is already using Hammer and > upgrade to new config paths could cause problems. > > I was thinking about /etc/hammer being the deafult with option to change > to anything else with $HAMMER_CONFIG_NAME env variable. That way it > could be possible to add +alias > myproject-cli='HAMMER_CONFIG_NAME=myproject hammer'+ making hammer to > read /etc/myproject and ~/.myproject. It could help to separate configs > for unrelated projects using hammer. We could use this feature to keep > the /etc/foreman as one option. > > Other option is to check both (/etc/hammer and /etc/foreman) and print > warning for a couple of versions. > > What would hammer users prefer? > > Martin >

> >>>> i'm glad that a solution has been made where individual hammer plugins
> >>>> each have their own config files to avoid writing a file that it did
> >>>> not install, but i disagree on the placement of hammer's module-config
> >>>> directory.
> >>>>
> >>>> i think that hammer's configs should not be placed inside
> >>>> /etc/foreman. hammer very well could be used for something that isn't
> >>>> foreman at all.
> >>>>
> >>>> i'd suggest /etc/hammer/modules.d
> >>>>
> >>> I tend to agree… If we can make it easy… lets do that. If I scan for
> >>> Foreman in the hammer code, there is bleed over. So. the likelyhood
> >>> today of being used is low… but it is good practice.
> >>>
> >>> – bk
> >>>
> >>
> >> +1 Hammer does not have to be foreman specific. I originally wanted to
> >> package it this way. Martin convinced me to postpone the change as it
> >> breaks backward compatibility. If we agree we can live with that at
> >> this stage of development, let's go for it.
> >>
> >> Martin, how do you see it?
> >>
> >> T.
> >>
> > I agree that /etc/hammer is more proper place for the hammer config.
> > However it seems that quite a lot of people is already using Hammer and
> > upgrade to new config paths could cause problems.
> >
> > I was thinking about /etc/hammer being the deafult with option to change
> > to anything else with $HAMMER_CONFIG_NAME env variable. That way it
> > could be possible to add +alias
> > myproject-cli='HAMMER_CONFIG_NAME=myproject hammer'+ making hammer to
> > read /etc/myproject and ~/.myproject. It could help to separate configs
> > for unrelated projects using hammer. We could use this feature to keep
> > the /etc/foreman as one option.
> >
> > Other option is to check both (/etc/hammer and /etc/foreman) and print
> > warning for a couple of versions.
> >
> > What would hammer users prefer?
> >
> > Martin
> >
> IMHO… I would keep the old location for a release… and then layer the
> new one on top of it. That way you dont break anything. You can warn the
> folks if you are pulling the config from the deprecated location.

in this particular case, i don't think it's necessarily bad to break backwards-compatibility. all you have to do is add an output message if it can't find /etc/hammer config stuff.

  1. "if you have hammer config stuff in /etc/foreman please move it to /etc/hammer"
  2. cp directory
  3. everybody's happy and we didn't have to add complicated code to check for multiple config locations.
··· ----- Original Message ----- > On 03/24/2014 06:25 AM, Martin Bačovský wrote: > > On 03/24/2014 10:34 AM, Tomas Strachota wrote: > >> On 03/21/2014 07:11 PM, Bryan Kearney wrote: > >>> On 03/21/2014 02:08 PM, Adam Price wrote:

– bk


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

  • adam price

>>>>>> i'm glad that a solution has been made where individual hammer plugins
>>>>>> each have their own config files to avoid writing a file that it did
>>>>>> not install, but i disagree on the placement of hammer's module-config
>>>>>> directory.
>>>>>>
>>>>>> i think that hammer's configs should not be placed inside
>>>>>> /etc/foreman. hammer very well could be used for something that isn't
>>>>>> foreman at all.
>>>>>>
>>>>>> i'd suggest /etc/hammer/modules.d
>>>>>>
>>>>> I tend to agree… If we can make it easy… lets do that. If I scan for
>>>>> Foreman in the hammer code, there is bleed over. So. the likelyhood
>>>>> today of being used is low… but it is good practice.
>>>>>
>>>>> – bk
>>>>>
>>>>
>>>> +1 Hammer does not have to be foreman specific. I originally wanted to
>>>> package it this way. Martin convinced me to postpone the change as it
>>>> breaks backward compatibility. If we agree we can live with that at
>>>> this stage of development, let's go for it.
>>>>
>>>> Martin, how do you see it?
>>>>
>>>> T.
>>>>
>>> I agree that /etc/hammer is more proper place for the hammer config.
>>> However it seems that quite a lot of people is already using Hammer and
>>> upgrade to new config paths could cause problems.
>>>
>>> I was thinking about /etc/hammer being the deafult with option to change
>>> to anything else with $HAMMER_CONFIG_NAME env variable. That way it
>>> could be possible to add +alias
>>> myproject-cli='HAMMER_CONFIG_NAME=myproject hammer'+ making hammer to
>>> read /etc/myproject and ~/.myproject. It could help to separate configs
>>> for unrelated projects using hammer. We could use this feature to keep
>>> the /etc/foreman as one option.
>>>
>>> Other option is to check both (/etc/hammer and /etc/foreman) and print
>>> warning for a couple of versions.
>>>
>>> What would hammer users prefer?
>>>
>>> Martin
>>>
>> IMHO… I would keep the old location for a release… and then layer the
>> new one on top of it. That way you dont break anything. You can warn the
>> folks if you are pulling the config from the deprecated location.
>
> in this particular case, i don't think it's necessarily bad to break backwards-compatibility. all you have to do is add an output message if it can't find /etc/hammer config stuff.
>
> 1. "if you have hammer config stuff in /etc/foreman please move it to /etc/hammer"
> 2. cp directory
> 3. everybody's happy and we didn't have to add complicated code to check for multiple config locations.
>

Yeah, please check out https://github.com/theforeman/hammer-cli/pull/97

··· On 03/24/2014 04:59 PM, Adam Price wrote: > ----- Original Message ----- >> On 03/24/2014 06:25 AM, Martin Bačovský wrote: >>> On 03/24/2014 10:34 AM, Tomas Strachota wrote: >>>> On 03/21/2014 07:11 PM, Bryan Kearney wrote: >>>>> On 03/21/2014 02:08 PM, Adam Price wrote:

– bk


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

> >>>>>> i'm glad that a solution has been made where individual hammer plugins
> >>>>>> each have their own config files to avoid writing a file that it did
> >>>>>> not install, but i disagree on the placement of hammer's module-config
> >>>>>> directory.
> >>>>>>
> >>>>>> i think that hammer's configs should not be placed inside
> >>>>>> /etc/foreman. hammer very well could be used for something that isn't
> >>>>>> foreman at all.
> >>>>>>
> >>>>>> i'd suggest /etc/hammer/modules.d
> >>>>>>
> >>>>> I tend to agree… If we can make it easy… lets do that. If I scan for
> >>>>> Foreman in the hammer code, there is bleed over. So. the likelyhood
> >>>>> today of being used is low… but it is good practice.
> >>>>>
> >>>>> – bk
> >>>>>
> >>>>
> >>>> +1 Hammer does not have to be foreman specific. I originally wanted to
> >>>> package it this way. Martin convinced me to postpone the change as it
> >>>> breaks backward compatibility. If we agree we can live with that at
> >>>> this stage of development, let's go for it.
> >>>>
> >>>> Martin, how do you see it?
> >>>>
> >>>> T.
> >>>>
> >>> I agree that /etc/hammer is more proper place for the hammer config.
> >>> However it seems that quite a lot of people is already using Hammer and
> >>> upgrade to new config paths could cause problems.
> >>>
> >>> I was thinking about /etc/hammer being the deafult with option to change
> >>> to anything else with $HAMMER_CONFIG_NAME env variable. That way it
> >>> could be possible to add +alias
> >>> myproject-cli='HAMMER_CONFIG_NAME=myproject hammer'+ making hammer to
> >>> read /etc/myproject and ~/.myproject. It could help to separate configs
> >>> for unrelated projects using hammer. We could use this feature to keep
> >>> the /etc/foreman as one option.
> >>>
> >>> Other option is to check both (/etc/hammer and /etc/foreman) and print
> >>> warning for a couple of versions.
> >>>
> >>> What would hammer users prefer?
> >>>
> >>> Martin
> >>>
> >> IMHO… I would keep the old location for a release… and then layer the
> >> new one on top of it. That way you dont break anything. You can warn the
> >> folks if you are pulling the config from the deprecated location.
> >
> > in this particular case, i don't think it's necessarily bad to break
> > backwards-compatibility. all you have to do is add an output message if it
> > can't find /etc/hammer config stuff.
> >
> > 1. "if you have hammer config stuff in /etc/foreman please move it to
> > /etc/hammer"
> > 2. cp directory
> > 3. everybody's happy and we didn't have to add complicated code to check
> > for multiple config locations.
> >
>
> Yeah, please check out https://github.com/theforeman/hammer-cli/pull/97

awesome! thanks!

··· ----- Original Message ----- > On 03/24/2014 04:59 PM, Adam Price wrote: > > ----- Original Message ----- > >> On 03/24/2014 06:25 AM, Martin Bačovský wrote: > >>> On 03/24/2014 10:34 AM, Tomas Strachota wrote: > >>>> On 03/21/2014 07:11 PM, Bryan Kearney wrote: > >>>>> On 03/21/2014 02:08 PM, Adam Price wrote:

– bk


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

  • adam price