Re: [openstack-dev] [TripleO/heat] openstack debug command

2015-12-01 Thread Lennart Regebro
On Tue, Dec 1, 2015 at 3:39 AM, Steve Baker  wrote:
> I mean _here_
>
> https://review.openstack.org/#/c/251587/

OK, that's great! If you want any help implementing it, I can try.

//Lennart

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [TripleO/heat] openstack debug command

2015-11-30 Thread Lennart Regebro
I'm tasked to implement a command that shows error messages when a
deployment has failed. I have a vague memory of having seen scripts
that do something like this, if that exists, can somebody point me in
teh right direction?

Any opinions on what that should do, specifically? Traverse failed
resources to find error messages, I assume. Anything else?

//Lennart

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] TripleO client answers file.

2015-11-27 Thread Lennart Regebro
On Thu, Nov 26, 2015 at 2:01 PM, Qasim Sarfraz  wrote:
> +1. That would be really helpful.
>
> What about passing other deployment parameters via answers.yaml ?  For
> example, compute-flavor, control-flavor etc

The overcloud update command doesn't take those parameters, however
most of those will change heat parameters, so you can put them in an
environment file and include that in the answers file. That way the
parameters will be preserved if you do a overcloud update.

//Lennart

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] TripleO client answers file.

2015-11-26 Thread Lennart Regebro
We are proposing to have an "answers file" for the tripleoclient so
that you don't have to have a ling line of

   openstack overcloud deploy --templates /home/stack/mytemplates
--environment superduper.yaml --environment loadsofstuff.yaml
--envirnoment custom.yaml

But instead can just do

   opennstack overcloud deploy --answers-file answers.yaml

And in that file have:

  templates: /home/stack/mytemplates
  environments:
- superduper.yaml
- loadsofstuff.yaml
- custom.yaml

This way you wont mess up the command line or confuse multiple subtle
command-line variations from Bash history and deploy the wrong one
(Yeah, we did that on a deployment).

A change request exists: https://review.openstack.org/#/c/249222/

Feedback?

//Lennart

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

2015-11-10 Thread Lennart Regebro
These changes are fine to me.

I'm not so sure about the idea that we can't "hijack" other projects
namespaces. If only ironic is allowed to use the prefix "baremetal",
then the prefix should not have been "baremetal" in the first place,
it should have been "ironic". Which of course means it would just be a
replacement for the ironic client, making these whole namespaces
pointless.

I do agree that many of these should not be in baremetal at all as
they are not baremetal specific, but tripleo-things, and hence is a
part of the overcloud/undercloud namespace, and that in the minimum
teaches us to be more careful with the namespaces. We should probably
double-check with others first.

Oh, sorry, I mean "We should probably increase cross-team
communication visibility to synchronize the integrational aspects of
the openstack client project, going forward."


On Mon, Nov 9, 2015 at 1:44 PM, Dmitry Tantsur  wrote:
> Hi OOO'ers, hopefully the subject caught your attentions :)
>
> Currently, tripleoclient exposes several commands in "openstack baremetal"
> and "openstack baremetal introspection" namespaces belonging to ironic and
> ironic-inspector accordingly. TL;DR of this email is to deprecate them and
> move to TripleO-specific namespaces. Read on to know why.
>
> Problem
> ===
>
> I realized that we're doing a wrong thing when people started asking me why
> "baremetal introspection start" and "baremetal introspection bulk start"
> behave so differently (the former is from ironic-inspector, the latter is
> from tripleoclient). The problem with TripleO commands is that they're
> highly opinionated workflows commands, but there's no way a user can
> distinguish them from general-purpose ironic/ironic-inspector commands. The
> way some of them work is not generic enough ("baremetal import"), or uses
> different defaults from an upstream project ("configure boot"), or does
> something completely unacceptable upstream (e.g. the way "introspection bulk
> start" deals with node states).
>
> So, here are commands that tripleoclient exposes with my comments:
>
> 1. baremetal instackenv validate
>
>  This command assumes there's an "baremetal instackenv" object, while
> instackenv is a tripleo-specific file format.
>
> 2. baremetal import
>
>  This command supports a limited subset of ironic drivers and driver
> properties, only those known to os-cloud-config.
>
> 3. baremetal introspection bulk start
>
>  This command does several bad (IMO) things:
>  a. Messes with ironic node states
>  b. Operates implicitly on all nodes (in a wrong state)
>  c. Defaults to polling
>
> 4. baremetal show capabilities
>
>  This is the only commands that is generic enough and could actually make it
> to ironicclient itself.
>
> 5. baremetal introspection bulk status
>
>  See "bulk start" above.
>
> 6. baremetal configure ready state
>
>  First of all, this and the next command use "baremetal configure" prefix. I
> would not promise we'll never start using it in ironic, breaking the whole
> TripleO.
>
>  Seconds, it's actually DELL-specific.
>
> 7. baremetal configure boot
>
>  This one is nearly ok, but it defaults to local boot, which is not an
> upstream default. Default values for images may not work outside of TripleO
> as well.
>
> Proposal
> 
>
> As we already have "openstack undercloud" and "openstack overcloud" prefixes
> for TripleO, I suggest we move these commands under "openstack overcloud
> nodes" namespace. So we end up with:
>
>  overcloud nodes import
>  overcloud nodes configure ready state --drac
>  overcloud nodes configure boot
>
> As you see, I require an explicit --drac argument for "ready state" command.
> As to the remaining commands:
>
> 1. baremetal introspection status --all
>
>   This is fine to move to inspector-client, as inspector knows which nodes
> are/were on introspection. We'll need a new API though.
>
> 2. baremetal show capabilities
>
>   We'll have this or similar command in ironic, hopefully this cycle.
>
> 3. overcloud nodes introspect --poll --allow-available
>
>   I believe that we need to make 2 things explicit in this replacement for
> "introspection bulk status": polling and operating on "available" nodes.
>
> 4. overcloud nodes import --dry-run
>
>   could be a replacement for "baremetal instackenv validate".
>
>
> Please let me know what you think.
>
> Cheers,
> Dmitry.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] os-cloud-config support for custom .ssh configs

2015-09-15 Thread Lennart Regebro
In bug https://bugzilla.redhat.com/show_bug.cgi?id=1252255 is about adding a 
possibility to have an .ssh directory that is not in ~/.ssh
Currently the blocker there is os-cloud-config, that just calls ssh, and ssh 
will look in the users homedirectory for .ssh/config no matter what. 

To solve this we would need a way to add support for custom .ssh configs in 
os-cloud-config, specifically to the _perform_pki_initialization() method, so 
that you can specify a ssh config file, which otherwise will default to 
~/.ssh/con fig. 

Either we can always use ~/.ssh/config, but perform the user expansion in the 
Python code. That way it will pick up $HOME, and that means you can just set 
$HOME first. (There is a patch linked from the bug for python-tripleoclient to 
allow that).

Or we can pass in the path to the config file as a new paremeter. 

In both cases the change is quite trivial.

Thoughts/opinions on this?

//Lennart

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev