Re: [openstack-dev] [tripleo] proposing Alex Schultz tripleo-core in all projects

[Marios Andreou]

On Fri, Jul 7, 2017 at 8:39 PM, Emilien Macchi  wrote:

> Alex has demonstrated high technical and community skills in TripleO -
> where he's already core on THT, instack-undercloud, and puppet-tripleo
> - but also very involved in other repos.
> I propose that we extend his core status to all TripleO projects and
> of course trust him (like we trust all core members) to review patches
> were we feel confortable with.
>
> He has shown an high interest in reviewed other TripleO projects and I
> think he would be ready for this change.
> As usual, this is an open proposal, any feedback is welcome.
>


+1



>
> Thanks,
> --
> Emilien Macchi
>
> __
> 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

Re: [openstack-dev] [Vitrage] [aodh] Integration with doctor

[Juvonen, Tomi (Nokia - FI/Espoo)]

Hi,

Inline for “set instance state”

Br,
Tomi


From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Sunday, July 09, 2017 3:14 PM
To: dong.wenj...@zte.com.cn; openstack-dev@lists.openstack.org
Subject: Suspected SPAM - Re: [openstack-dev] [Vitrage] [aodh] Integration with 
doctor

Hi dwj,

Adding [aodh] for item #2.
Please see my answers inline.

Best Regards,
Ifat.



From: "dong.wenj...@zte.com.cn" 
>
Date: Friday, 7 July 2017 at 10:53

Hi,



For the integration Vitrage with doctor, I have some issues which need to be 
confirmed~  :)



1.  Notification strategies: conservative (nova->Aodh)

@Ifat

In the host_down_scenarios.yaml[1], we only set the host state as error.

But in doctor current use case, we need to call nova API 'nova reset-state' to 
set instance state as error to trigger the event alarm and notify the consumer.

Is it needed to be fix?

[Tomi] Either to have this fixed or propose an alternative in Doctor project 
where project (tenant) is able to have alarm about instances affected by other 
means. Project anyhow already know about “host forced down” in Nova servers API 
trough “host_status”, so it is just about getting an alarm on instance (server) 
level also.

We need to add 'Aodh' and 'Nova' notifier plugins in Vitrage config file for 
doctor integration,  right?



[Ifat] Vitrage currently doesn’t call set instance state, but this can easily 
be added. The required steps are:

  *   Add “set state” action for the instances in the template yaml file
  *   In the Nova notifier, add a call to nova reset-state API
  *   The Aodh plugin is not needed in this case, since the flow is Vitrage -> 
Nova -> Aodh with no direct calls from Vitrage to Aodh





2. Notification strategies: shortcut  (inspector->Aodh)

@Ryota

Do we have any plans to change to shortcut notification?

@Ifat

If we use the shortcut notification, in the Aodh notifier plugin, maybe we need 
to create aodh alarm with 'alarm_actions'.



[Ifat] The Aodh plugin is defined as a POC, and is not very usable. We have 
discussed with the Aodh team possible enhancements (like adding an 
“external/custon alarm” in Aodh) that will enable creating an Aodh alarm from 
Vitrage, but we didn’t reach a clear conclusion. There are a few problems with 
the current implementation, related to the facts that the event-alarm does not 
exactly suit the use case; and that Vitrage may raise the same alarm several 
times for different instances. If you chose the shortcut strategy, we will have 
to open this discussion again.

Having that said, I believe that the shortcut strategy is much better for 
Vitrage. While on the conservative strategy we can support notifications to 
Nova, in the shortcut strategy we can write the Aodh plugin once and support 
all kinds of notifications (to Nova, Neutron, Heat or even external components) 
with no additional effort.





Correct me if I miss something.



[1]. 
https://github.com/openstack/vitrage/blob/master/etc/vitrage/templates.sample/host_down_scenarios.yaml



BR,

dwj










__
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] proposing Alex Schultz tripleo-core in all projects

[Wesley Hayutin]

+1

On Fri, Jul 7, 2017 at 5:25 PM, Pradeep Kilambi  wrote:

> +1 to Alex
>
> On Fri, Jul 7, 2017 at 4:20 PM, Juan Antonio Osorio 
> wrote:
> > +1
> >
> > He's a great reviewer
> >
> > On 7 Jul 2017 8:40 pm, "Emilien Macchi"  wrote:
> >>
> >> Alex has demonstrated high technical and community skills in TripleO -
> >> where he's already core on THT, instack-undercloud, and puppet-tripleo
> >> - but also very involved in other repos.
> >> I propose that we extend his core status to all TripleO projects and
> >> of course trust him (like we trust all core members) to review patches
> >> were we feel confortable with.
> >>
> >> He has shown an high interest in reviewed other TripleO projects and I
> >> think he would be ready for this change.
> >> As usual, this is an open proposal, any feedback is welcome.
> >>
> >> Thanks,
> >> --
> >> Emilien Macchi
> >>
> >> 
> __
> >> 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
> >
>
>
>
> --
> Cheers,
> ~ Prad
>
> __
> 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

Re: [openstack-dev] [TripleO] Forming our plans around Ansible

[Wesley Hayutin]

On Fri, Jul 7, 2017 at 6:20 PM, James Slagle  wrote:

> On Fri, Jul 7, 2017 at 5:31 PM, David Moreau Simard 
> wrote:
> > On Fri, Jul 7, 2017 at 1:50 PM, James Slagle 
> wrote:
> >> (0) tripleo-quickstart which follows the common and well accepted
> >> approach to bundling a set of Ansible playbooks/roles.
> >
> > I don't want to de-rail the thread but I really want to bring some
> > attention to a pattern that tripleo-quickstart has been using across
> > it's playbooks and roles.
> > I sincerely hope that we can find a better implementation should we
> > start developing new things from scratch.
>
> Yes, just to clarify...by "well accepted" I just meant how the git
> repo is organized and how you are expected to interface with those
> playbooks and roles as opposed to what those playbooks/roles actually
> do.
>
> > I'll sound like a broken record for those that have heard me mention
> > this before but for those that haven't, here's a concrete example of
> > how things are done today:
> > (Sorry for the link overload, making sure the relevant information is
> available)
> >
> > For an example tripleo-quickstart job, here's the console [1] and it's
> > corresponding ARA report [2]:
> > - A bash script is created [3][4][5] from a jinja template [6]
> > - A task executes the bash script [7][8][9]
>
> From my limited experience, I believe the intent was that the
> playbooks should do what a user is expected to do so that it's as
> close to reproducing the user interface of TripleO 1:1.
>
> For example, we document users running commands from a shell prompt.
> Therefore, oooq ought to do the same thing as close as possible.
> Obviously there will be gaps, just as there is with tripleo.sh, but I
> feel that both tools (tripleo.sh/oooq) were trying to be faithful to
> our published docs as mush as possible, and I think there's something
> to be commended there.
>

That is exactly right James, CI should be as close to a user driven install
as possible IMHO.

David you are conflating two use cases as far as I can tell. The first use
case (a) ansible used in the project/product that is launched by
openstack/project commands,  and the second use case (b) ansible as a
wrapper around commands that users are expected to execute.

Using navtive ansible modules as part of the project/product (a) as James
is describing is perfectly fine and ansible, ARA and other tools work
really well here.

If the CI reinterprets user level commands (b) directly into ansible module
calls you basically loose the 1:1 mapping between CI, documentation and
user experience.
The *most* important function of CI is guarantee that users can follow the
documentation and have a defect free experience [docs].  Having to "look at
the logs" is a very small
price to pay to preserve that experience.   I think we'll be able to get
the logs from the templated bash into ARA, we just need a little time to
get that done.
IMHO CI is a very different topic than what James is talking about in this
thread and hopefully won't interupt this converstation further.

Thanks

[docs]
https://docs.openstack.org/tripleo-quickstart/latest/design.html#problem-help-make-the-deployment-steps-easier-to-understand



> Not saying it's right or wong, just that I believe that was the intent.
>
> An alternative would be custom ansible modules that exposed tasks for
> interfacing with our API directly. That would also be valuable, as
> that code path is mostly untested now outside of the UI and CLI.
>
> I think that tripleo-quickstart is a slightly different class of
> "thing" from the other current Ansible uses I mentioned, in that it
> sits at a layer above everything else. It's meant to automate TripleO
> itself vs TripleO automating things. Regardless, we should certainly
> consider how it fits into a larger plan.
>
> --
> -- James Slagle
> --
>
> __
> 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] index_footer in openstack logs

[Wesley Hayutin]

posting to openstack-dev

On Sun, Jul 9, 2017 at 10:08 AM, Wesley Hayutin  wrote:

> Greetings Andreas, Paul
>
> I'm looking for some pointers on how to include some instructions in our
> openstack logs in the same way the devstack gate works [1] and I'm not able
> to piece things together atm.
>
> I see the support for adding an index_footer was removed in [2], but I
> don't see what it was replaced by.  I was hoping you guys could point us in
> the right direction to enable embedding instructions directly in our logs
> like [3]
>
> Thank you for the help!
>
> [1] https://github.com/openstack-infra/devstack-gate/tree/master/help
> [2] https://github.com/openstack-infra/project-config/commit/
> 183aabbeaf528f5ef637a7bb51245eea4fab94b8#diff-
> 03d414c17dcd54548b8810c4a442b655
> [3] http://logs.openstack.org/29/480429/1/check/gate-
> tempest-dsvm-neutron-full-ubuntu-xenial/76071e1/logs/
>
__
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] [nova] The definition of 'Optional' parameter in API reference

[Matt Riedemann]

On 7/4/2017 7:13 PM, Takashi Natsume wrote:

On 2017/07/04 21:12, Alex Xu wrote:

2017-07-04 15:40 GMT+08:00 Ghanshyam Mann :


On Mon, Jul 3, 2017 at 1:38 PM, Takashi Natsume
 wrote:

In Nova API reference, there is inconsistency in
whether to define parameters added in new microversion as 'optional' or

not.

Those should be defined based on how they are defined in respective
microversion. If they are 'optional' in that microversion they should
be mentioned as 'optional' and vice versa. Any parameter added in
microversion is mentioned as 'New in version 2.xy' which shows the non
availability of that parameter in earlier versions. Same case for
removal of parameter also.

But if any microversion change parameter from option param to required
or vice versa then it is tricky but IMO documenting the latest
behavior is right thing but with clear notes.
For example, microversion 2.37,   where 'network' in request made as
required from optional. In this cases, api-ref have the latest
behavior of that param which is 'required' and a clear notes about
till when it was optional and from when it is mandatory.

In all cases, doc should reflect the latest behavior of param with
notes(manual or auto generated with min_version & max_version)



++


Thank you for your replies and the fix in 
https://review.openstack.org/#/c/480162/ .


In the case that the parameter is always included in the response 
after a

certain microversion,
some parameters(e.g. 'type' [1]) are defined as 'required', but some
parameters (e.g. 'project_id', 'user_id'[2])
are defined as 'optional'.

[1] List Keypairs in Keypairs (keypairs)
https://developer.openstack.org/api-ref/compute/?expanded=

list-keypairs-detail#list-keypairs



'keypairs_links' in the response should be the required parameter. 
Because

it always show up after 2.35.


The 'keypairs_links' is an optional parameter.
When the 'get_links' method of the view builder for keypairs operations
returns an empty list, the 'keypairs_links' does not appear
in the response.

https://github.com/openstack/nova/blob/32e613b9cd499847b7a7dc49d43020523b96c1d1/nova/api/openstack/compute/keypairs.py#L286-L288 


I noticed the same thing with hypervisor_links in the os-hypervisors 
API. The links are not shown if a limit is not in the request query 
parameters and there aren't more results than the default max limit 
(1000). In other words, you don't need links to another page if there is 
not another page to get.





Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp



__
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


Thanks for starting this thread. I've been struggling with this a bit 
too lately in some changes I'm working on, for example:


https://review.openstack.org/#/c/454322/

In there, instance_action_events are optional before 2.50, but required 
in >= 2.50. It gets doubly confusing because actually the 'events' in 
the response are required if you are an admin user before 2.50. So there 
are really three cases there:


1. Microversion < 2.50, admin user: 'events' are required
2. Microversion < 2.50, non-admin user: 'events' are optional
3. Microversion >= 2.50, admin or non-admin user: 'events' are required

I've tried to clarify with the description on each, and used the max/min 
versions for the behavior differences for when they are optional or not, 
but I can see where it's still a bit confusing.


--

Thanks,

Matt

__
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] [Vitrage] [aodh] Integration with doctor

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi dwj,

Adding [aodh] for item #2.
Please see my answers inline.

Best Regards,
Ifat.



From: "dong.wenj...@zte.com.cn" 
Date: Friday, 7 July 2017 at 10:53


Hi,



For the integration Vitrage with doctor, I have some issues which need to be 
confirmed~  :)



1.  Notification strategies: conservative (nova->Aodh)

@Ifat

In the host_down_scenarios.yaml[1], we only set the host state as error.

But in doctor current use case, we need to call nova API 'nova reset-state' to 
set instance state as error to trigger the event alarm and notify the consumer.

Is it needed to be fix?



We need to add 'Aodh' and 'Nova' notifier plugins in Vitrage config file for 
doctor integration,  right?



[Ifat] Vitrage currently doesn’t call set instance state, but this can easily 
be added. The required steps are:

· Add “set state” action for the instances in the template yaml file

· In the Nova notifier, add a call to nova reset-state API

· The Aodh plugin is not needed in this case, since the flow is Vitrage 
-> Nova -> Aodh with no direct calls from Vitrage to Aodh





2. Notification strategies: shortcut  (inspector->Aodh)

@Ryota

Do we have any plans to change to shortcut notification?

@Ifat

If we use the shortcut notification, in the Aodh notifier plugin, maybe we need 
to create aodh alarm with 'alarm_actions'.



[Ifat] The Aodh plugin is defined as a POC, and is not very usable. We have 
discussed with the Aodh team possible enhancements (like adding an 
“external/custon alarm” in Aodh) that will enable creating an Aodh alarm from 
Vitrage, but we didn’t reach a clear conclusion. There are a few problems with 
the current implementation, related to the facts that the event-alarm does not 
exactly suit the use case; and that Vitrage may raise the same alarm several 
times for different instances. If you chose the shortcut strategy, we will have 
to open this discussion again.

Having that said, I believe that the shortcut strategy is much better for 
Vitrage. While on the conservative strategy we can support notifications to 
Nova, in the shortcut strategy we can write the Aodh plugin once and support 
all kinds of notifications (to Nova, Neutron, Heat or even external components) 
with no additional effort.





Correct me if I miss something.



[1]. 
https://github.com/openstack/vitrage/blob/master/etc/vitrage/templates.sample/host_down_scenarios.yaml



BR,

dwj










__
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] Forming our plans around Ansible

[Yolanda Robla Mota]

What i'd like to dig more is how Ansible and Heat can live together. And
what features do Heat offer that are not covered by Ansible as well? Is
there still the need to have Heat as the main engine, or could that be
replaced by Ansible totally in the future?

On Sat, Jul 8, 2017 at 12:20 AM, James Slagle 
wrote:

> On Fri, Jul 7, 2017 at 5:31 PM, David Moreau Simard 
> wrote:
> > On Fri, Jul 7, 2017 at 1:50 PM, James Slagle 
> wrote:
> >> (0) tripleo-quickstart which follows the common and well accepted
> >> approach to bundling a set of Ansible playbooks/roles.
> >
> > I don't want to de-rail the thread but I really want to bring some
> > attention to a pattern that tripleo-quickstart has been using across
> > it's playbooks and roles.
> > I sincerely hope that we can find a better implementation should we
> > start developing new things from scratch.
>
> Yes, just to clarify...by "well accepted" I just meant how the git
> repo is organized and how you are expected to interface with those
> playbooks and roles as opposed to what those playbooks/roles actually
> do.
>
> > I'll sound like a broken record for those that have heard me mention
> > this before but for those that haven't, here's a concrete example of
> > how things are done today:
> > (Sorry for the link overload, making sure the relevant information is
> available)
> >
> > For an example tripleo-quickstart job, here's the console [1] and it's
> > corresponding ARA report [2]:
> > - A bash script is created [3][4][5] from a jinja template [6]
> > - A task executes the bash script [7][8][9]
>
> From my limited experience, I believe the intent was that the
> playbooks should do what a user is expected to do so that it's as
> close to reproducing the user interface of TripleO 1:1.
>
> For example, we document users running commands from a shell prompt.
> Therefore, oooq ought to do the same thing as close as possible.
> Obviously there will be gaps, just as there is with tripleo.sh, but I
> feel that both tools (tripleo.sh/oooq) were trying to be faithful to
> our published docs as mush as possible, and I think there's something
> to be commended there.
>
> Not saying it's right or wong, just that I believe that was the intent.
>
> An alternative would be custom ansible modules that exposed tasks for
> interfacing with our API directly. That would also be valuable, as
> that code path is mostly untested now outside of the UI and CLI.
>
> I think that tripleo-quickstart is a slightly different class of
> "thing" from the other current Ansible uses I mentioned, in that it
> sits at a layer above everything else. It's meant to automate TripleO
> itself vs TripleO automating things. Regardless, we should certainly
> consider how it fits into a larger plan.
>
> --
> -- James Slagle
> --
>
> __
> 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
>



-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat



C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639


__
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