Hi All,
Is this the expected behaviour? I’ve raised it as an issue in github
(https://github.com/opscode/knife-ec2/issues/41), but thought I’d seek
others opinions here as well. It seems to prevent knife ec2 commands
from being scripted effectively if there are entries in knife.rb.
Use case is having defaults in knife.rb to spin up instances quickly
while testing things without having to type a command line as long as
your arm, but occasionally want a different AMI or to start an instance
in a different AZ by quickly overriding on the command line. At the
moment it’s a case of having to change the knife.rb, run the command,
change it back or, alternatively, leave the options out of knife.rb and
always pass as command line arguments.
It surprises me that this isn’t affecting anyone else, so I’m wondering
if I’m doing something to cause this behaviour?
Cheers
Nick
I've had more than one occasion where it's impossible to set an option
via the knife.rb, only the CLI. There are a number of issues here. I
have occasionally resorted to medium-Ruby magic to inject my custom,
overridable settings into Knife.
Would definitely like to see both sides of this blade sharpened a little.
--AJ
On 26 April 2012 20:13, Nick Peirson nickpeirson@gmail.com wrote:
Hi All,
Is this the expected behaviour? I've raised it as an issue in github
(knife.rb takes precedence over command line preventing defaults from being overridden · Issue #41 · chef/knife-ec2 · GitHub), but thought I'd seek
others opinions here as well. It seems to prevent knife ec2 commands from
being scripted effectively if there are entries in knife.rb.
Use case is having defaults in knife.rb to spin up instances quickly while
testing things without having to type a command line as long as your arm,
but occasionally want a different AMI or to start an instance in a different
AZ by quickly overriding on the command line. At the moment it's a case of
having to change the knife.rb, run the command, change it back or,
alternatively, leave the options out of knife.rb and always pass as command
line arguments.
It surprises me that this isn't affecting anyone else, so I'm wondering if
I'm doing something to cause this behaviour?
Cheers
Nick
The way the options parser is written, without a custom function either
knife.rb overrides command line options, or command line default values
override knife.rb.
For the knife vsphere plugin I ended up writing a get_config function to
force command line options > knife.rb > default values in the code.
Not the cleanest approach, but at the time the config hash is being
generated, the knife.rb has not yet been parsed, so it isn't possible to
set defaults from knife.rb using the built in mixlib.
See
https://github.com/ezrapagel/knife-vsphere/blob/master/lib/chef/knife/BaseVsphereCommand.rb
-Jesse
On Apr 26, 2012 4:47 AM, "AJ Christensen" aj@junglist.gen.nz wrote:
I've had more than one occasion where it's impossible to set an option
via the knife.rb, only the CLI. There are a number of issues here. I
have occasionally resorted to medium-Ruby magic to inject my custom,
overridable settings into Knife.
Would definitely like to see both sides of this blade sharpened a little.
--AJ
On 26 April 2012 20:13, Nick Peirson nickpeirson@gmail.com wrote:
Hi All,
Is this the expected behaviour? I've raised it as an issue in github
(knife.rb takes precedence over command line preventing defaults from being overridden · Issue #41 · chef/knife-ec2 · GitHub), but thought I'd seek
others opinions here as well. It seems to prevent knife ec2 commands from
being scripted effectively if there are entries in knife.rb.
Use case is having defaults in knife.rb to spin up instances quickly
while
testing things without having to type a command line as long as your arm,
but occasionally want a different AMI or to start an instance in a
different
AZ by quickly overriding on the command line. At the moment it's a case
of
having to change the knife.rb, run the command, change it back or,
alternatively, leave the options out of knife.rb and always pass as
command
line arguments.
It surprises me that this isn't affecting anyone else, so I'm wondering
if
I'm doing something to cause this behaviour?
Cheers
Nick
The option handling code needs to be re-examined across the board. I recently ran into the same thing while rewriting the knife terremark plugin. This behavior seems to surprise everyone.
-C
On Apr 26, 2012, at 7:03 AM, Jesse Campbell wrote:
The way the options parser is written, without a custom function either knife.rb overrides command line options, or command line default values override knife.rb.
For the knife vsphere plugin I ended up writing a get_config function to force command line options > knife.rb > default values in the code.
Not the cleanest approach, but at the time the config hash is being generated, the knife.rb has not yet been parsed, so it isn't possible to set defaults from knife.rb using the built in mixlib.
See https://github.com/ezrapagel/knife-vsphere/blob/master/lib/chef/knife/BaseVsphereCommand.rb
-Jesse
On Apr 26, 2012 4:47 AM, "AJ Christensen" aj@junglist.gen.nz wrote:
I've had more than one occasion where it's impossible to set an option
via the knife.rb, only the CLI. There are a number of issues here. I
have occasionally resorted to medium-Ruby magic to inject my custom,
overridable settings into Knife.
Would definitely like to see both sides of this blade sharpened a little.
--AJ
On 26 April 2012 20:13, Nick Peirson nickpeirson@gmail.com wrote:
Hi All,
Is this the expected behaviour? I've raised it as an issue in github
(knife.rb takes precedence over command line preventing defaults from being overridden · Issue #41 · chef/knife-ec2 · GitHub), but thought I'd seek
others opinions here as well. It seems to prevent knife ec2 commands from
being scripted effectively if there are entries in knife.rb.
Use case is having defaults in knife.rb to spin up instances quickly while
testing things without having to type a command line as long as your arm,
but occasionally want a different AMI or to start an instance in a different
AZ by quickly overriding on the command line. At the moment it's a case of
having to change the knife.rb, run the command, change it back or,
alternatively, leave the options out of knife.rb and always pass as command
line arguments.
It surprises me that this isn't affecting anyone else, so I'm wondering if
I'm doing something to cause this behaviour?
Cheers
Nick
On 26/04/2012 16:20, Christopher Brown wrote:
The option handling code needs to be re-examined across the board. I
recently ran into the same thing while rewriting the knife terremark
plugin. This behavior seems to surprise everyone.
-C
I'm happy to write up a ticket for this, but it's probably better if
someone who knows which bits of code need to be lumped under this
re-examination write it up and reference it. Any volunteers?
If there's no takers I'll put something up tomorrow and drop a reference
back here to give a starting point.
Cheers
Nick
+1 Me too having the same problem. Now for sure, its a bug.
@millisami
~ Sachin Sagar Rai
Ruby on Rails Developer
http://tfm.com.np
http://nepalonrails.tumblr.com
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Thursday, April 26, 2012 at 9:29 PM, Nick Peirson wrote:
On 26/04/2012 16:20, Christopher Brown wrote:
The option handling code needs to be re-examined across the board. I
recently ran into the same thing while rewriting the knife terremark
plugin. This behavior seems to surprise everyone.
-C
I'm happy to write up a ticket for this, but it's probably better if
someone who knows which bits of code need to be lumped under this
re-examination write it up and reference it. Any volunteers?
If there's no takers I'll put something up tomorrow and drop a reference
back here to give a starting point.
Cheers
Nick
This same problem happens in knife-cloudstack. +1 for fixing this in a
generic way that solves it for everyone.
KC
Same issues here had to work around it. The other feature that would be nice is the ability to pass the same argument multiple times.
In my example using an internal plugin we can provision/bootstrap machines and specifying -D 8g will give you an 8g disk. Knife opt parse IMO should give you an array of those options if you use it multiple times.
On Apr 27, 2012, at 4:00 AM, KC Braunschweig kcbraunschweig@gmail.com wrote:
This same problem happens in knife-cloudstack. +1 for fixing this in a
generic way that solves it for everyone.
KC
On 26/04/2012 20:00, KC Braunschweig wrote:
This same problem happens in knife-cloudstack. +1 for fixing this in a
generic way that solves it for everyone.
KC
I'm keen to get this fixed so I invested the time to learn about
contributing and the ticketing system. I was intending to raise a
ticket, but there's a ticket from October 2010 that already covers it:
http://tickets.opscode.com/browse/CHEF-1772
I've had a look for an indication of how tickets are prioritised, but
couldn't see anything obvious. Not sure if it's taken into account, but
there's a voting mechanism on the tickets, so I'd suggest that anyone
'+1'ing this thread vote for the ticket as well.
I'll try and add more info to the ticket and dig out some references to
the code. Given enough time I may even try and brush up on my ruby
skills to have a crack at a pull request.
Cheers
Nick