date:20171102

Re: [openstack-dev] [nova][neutron] How do you use the instance IP filter?

2017-11-02 Thread Alex Xu

FYI, Nova did use regex
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2408

2017-10-27 11:35 GMT+08:00 Matt Riedemann :

> On 10/26/2017 9:54 PM, Tony Breeds wrote:
>
>> Can you use RLIKE/REGEX? or is that too MySQL specific ?
>>
>
> I thought about that, and my gut response is 'no' because even if it does
> work for mysql, I'm assuming regex pattern matching for postgresql is
> different. And then you have different API behavior between clouds based on
> the backend database they are using, and now we've opened that whole can of
> worms again.
>
>
> --
>
> 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
>
__
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] [Magnum] Docker Swarm Mode Support

2017-11-02 Thread Ricardo Rocha

Hi again.

On Wed, Nov 1, 2017 at 9:47 PM, Vahric MUHTARYAN  wrote:
> Hello Ricardo ,
>
> Thanks for your explanation and answers.
> One more question, what is the possibility to keep using Newton (right now i 
> have it) and use latest Magnum features like swarm mode without upgrade 
> Openstack ? Does it possible ?

I don't think this functionality is available in Magnum Newton.

One option though is to upgrade only Magnum, there should be no
dependency on more recent versions of other components - assuming you
either have a separate control plane for Magnum or are able to split
it.

Cheers,
  Ricardo

>
> Regards
> VM
>
> On 30.10.2017 01:19, "Ricardo Rocha"  wrote:
>
> Hi Vahric.
>
> On Fri, Oct 27, 2017 at 9:51 PM, Vahric MUHTARYAN  
> wrote:
> > Hello All ,
> >
> >
> >
> > I found some blueprint about supporting Docker Swarm Mode
> > https://blueprints.launchpad.net/magnum/+spec/swarm-mode-support
> >
> >
> >
> > I understood that related development is not over yet and no any 
> Openstack
> > version or Magnum version to test it also looks like some more thing to 
> do.
> >
> > Could you pls inform when we should expect support of Docker Swarm Mode 
> ?
>
> Swarm mode is already available in Pike:
> https://docs.openstack.org/releasenotes/magnum/pike.html
>
> > Another question is fedora atomic is good but looks like its not 
> up2date for
> > docker , instead of use Fedora Atomic , why you do not use Ubuntu, or 
> some
> > other OS and directly install docker with requested version ?
>
> Atomic also has advantages (immutable, etc), it's working well for us
> at CERN. There are also Suse and CoreOS drivers, but i'm not familiar
> with those.
>
> Most pieces have moved to Atomic system containers, including all
> kubernetes components so the versions are decouple from the Atomic
> version.
>
> We've also deployed locally a patch running docker itself in a system
> container, this will get upstream with:
> https://bugs.launchpad.net/magnum/+bug/1727700
>
> With this we allow our users to deploy clusters with any docker
> version (selectable with a label), currently up to 17.09.
>
> > And last, to help to over waiting items “Next working items: ”  how we 
> could
> > help ?
>
> I'll let Spyros reply to this and give you more info on the above items 
> too.
>
> Regards,
>   Ricardo
>
> >
> >
> >
> > Regards
> >
> > Vahric Muhtaryan
> >
> >
> > 
> __
> > 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 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][containers]ironic-inspector

2017-11-02 Thread Bogdan Dobrelya


On 11/1/17 7:04 PM, milanisko k wrote:

Folks,
=

I've got a dilemma right now about how to proceed with containerising 
ironic-inspector:


Fat Container
--
put ironic-inspector and dnsmasq into a single container i.e consider a 
container as a complete inspection service shipping unit, use 
supervisord inside to fork and monitor both the services.


Pros:

* decoupling: dnsmasq of inspector isn't used by any other service which 
makes our life simpler as we won't need to reset dnsmasq configuration 
in case inspector died (to avoid exposing an unfiltered DHCP service)


* we can use dnsmasq filter (an on-line configuration files updating 
facility) driver to limit access to dnsmasq instead of iptables, in a 
self-contained "package" that is configured to work together as a single 
unit


* we don't have to worry about always scheduling dnsmasq and inspector 
containers on a single node (both services are bundled)


* we have a *Spine-Leaf deployment capable & containerised undercloud*

* an *HA capable inspector* service to be reused in overcloud

* an integrated solution, tested to work by upstream CI in inspector 
(compatibility, versioning, configuration,...)


Cons:

* inflexibility: container has to be rebuilt to be used with different 
DHCP service (filter driver)


* supervisord dependency and the need to refactor current container of 
inspector


* 

Flat Container
---

Put inspector and dnsmasq into separate containers. Use the (current) 
iptables driver to protect dnsmasq. IIRC this is the current approach.


Pros:

* containerised undercloud

Cons:

* no decoupling of dnsmasq

* no spine-leaf (iptables)

* containers have to be scheduled together on a single node,

* no HA (iptables driver)

* container won't be cool for overcloud as it won't be HA

Flat container with dnsmasq filter driver


Same as above but iptables isn't used anymore. Since it's not the 
current approach, we'd have to reshape the containers of dnsmasq and 
inspector to expose each others configuration so that inspector can 
write dnsmasq configuration on the fly (does inotify work in the mounted 
directories case???)


Pros:

* containerised undercloud

* Spine-Leaf

Cons:

* No (easy) HA (dnsmasq would be exposed in case inspector died)


Could it be managed by pacemaker bundles then?



* No decoupling of dnsmasq (shared between multiple services)


A dedicated side-car container can be used, just like the logging bp [0] 
implements it. So nothing will be shared then.


[0] https://blueprints.launchpad.net/tripleo/+spec/logging-stdout-rsyslog



* containers to be reshaped to expose the configuration


Seems like this is inevitable anyway



* overcloud-uncool container (lack of HA)


Could it be managed by pacemaker bundles then?



No Container
--

we ship inspector as a service and configure dnsmasq for inspector to be 
shut down in case inspector dies (to prevent exposing an unfiltered DHCP 
service interference). We use dnsmasq (configuration) filter driver to 
have a Spine-Leaf deployment capable undercloud.


Pros:

* Spine&Leaf

Cons:

* no HA inspector (shared dnsmasq?)

* no containers

* no reusable container for overcloud

* we'd have to update the undercloud systemd to shut down dnsmasq in 
case inspector dies if we want to use the dnsmasq filter driver


* no decoupling

The Question
--

What is your take on it?

Cheers,
milan


__
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




--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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] Logging format: let's discuss a bit about default format, format configuration and so on

2017-11-02 Thread Bogdan Dobrelya

Hi. Few comments inline.

Dear Stackers,
While working on my locally deployed Openstack (Pike using TripleO), I
was a bit struggling with the logging part. Currently, all logs are
pushed to per-service files, in the standard format "one line per
entry", plain flat text.

It's nice, but if one is wanting to push and index those logs in an ELK,
the current, default format isn't really good.

After some discussions about oslo.log, it appears it provides a nice
JSONFormatter handler¹ one might want to use for each (python) service
using oslo central library.

A JSON format is really cool, as it's easy to parse for machines, and it
can be on a multi-line without any bit issue - this is especially
important for stack traces, as their output is multi-line without real
way to have a common delimiter so that we can re-format it and feed it
to any log parser (logstash, fluentd, …).

After some more talks, olso.log will not provide a unified interface in
order to output all received logs as JSON - this makes sens, as that
would mean "rewrite almost all the python logging management
interface"², and that's pretty useless, since (all?) services have their
own "logging.conf" file.

That said… to the main purpose of that mail:

- Default format for logs
A first question would be "are we all OK with the default output format"
- I'm pretty sure "humans" are happy with that, as it's really
convenient to read and grep. But on a "standard" Openstack deploy, I'm
pretty sure one does not have only one controller, one ceph node and one
compute. Hence comes the log centralization, and with that, the log
indexation and treatments.

For that, one might argue "I'm using plain files on my logger, and
grep-ing -r in them". That's a way to do things, and for that, plain,
flat logs are great.

But… I'm pretty sure I'm not the only one wanting to use some kind of
ELK cluster for that kind of purpose. So the right question is: what
about switching the default log format to JSON? On my part, I don't see
"cons", only "pros", but my judgment is of course biased, as I'm "alone
in my corner". But what about you, Community?

- Provide a way to configure the output format/handler
While poking around in the puppet modules code, I didn't find any way to
set the output handler for the logs. For example, in puppet-nova³ we can
set a lot of things, but not the useful handler for the output.

It would be really cool to get, for each puppet module, the capability
to set the handler so that one can just push some stuff in hiera, and
Voilà, we have JSON logs.

Doing so would allow people to chose between the default (current)
output, and something more "computable".

This is being implemented (for Q) in the scope of this blueprint [0].
By default, containers will keep the current logging behaviour, which is
writing logs into bind-mounted host-path directories, and for those
services that can syslog only, sending the logs to the host journald via
syslog (bind-mounted /dev/log). And if the stdout/stderr feature
enabled, side-car containers will make sure everything is captured in
journald and tagged properly, with multiline entries as well. And
journald can dump messages as JSON as well. I hope that works! Please
send you comments to the aforementioned bp's spec.

[0] https://blueprints.launchpad.net/tripleo/+spec/logging-stdout-rsyslog

Of course, either proposal will require a nice code change in all puppet
modules (add a new parameter for the foo::logging class, and use that
new param in the configuration file, and so on), but at least people
will be able to actually chose.

So, before opening an issue on each launchpad project (that would be…
long), I'd rather open the discussion in here and, eventually, come to
some nice, acceptable and accepted solution that would make the
Openstack Community happy :).

Any thoughts?

Thank you for your attention, feedback and wonderful support for that
monster project :).

Cheers,

¹
https://github.com/openstack/oslo.log/blob/master/oslo_log/formatters.py#L166-L235
²
http://eavesdrop.openstack.org/irclogs/%23openstack-oslo/%23openstack-oslo.2017-11-01.log.html#t2017-11-01T13:23:14
³ https://github.com/openstack/puppet-nova/blob/master/manifests/logging.pp

--
Cédric Jeanneret
Senior Linux System Administrator
Infrastructure Solutions

Camptocamp SA
PSE-A / EPFL, 1015 Lausanne

Phone: +41 21 619 10 32
Office: +41 21 619 10 02
Email: cedric.jeanne...@camptocamp.com

--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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] [Openstack][Ceilometer] interface statistics for SRIO-V based VM

2017-11-02 Thread Franck Baudin

Hi Jai

> On Nov 1, 2017, at 2:14 PM, Jai Singh Rana  wrote:
> 
> Hi,
> 
> Does Ceilometer supports metrics for resource_type
> 'instance_network_interface' for VM based on SRIO-V supported nic?

libvirt doesn’t provide such statistics, and Ceilometer is getting the 
statistics from libvirt. So you’re right, the stats are not available.

> 
> I have pike based setup but i am unable to get these statistics with
> SRIO-V supported nic with vnic_type=direct for the VM.
> 
> If it does, how to configure ceilometer to get these statistics. If
> not, is there any proposal or roadmap to support it in future.

Please feel free to contribute the code :-)

Thanks,
Franck


> 
> Thanks,
> Jai
> 
> __
> 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] [ironic] [nova] traits discussion call - moved to Tue!!

2017-11-02 Thread Dmitry Tantsur


Hi all,

The recording of the call is https://bluejeans.com/s/K3wZZ

On 10/30/2017 03:32 PM, Dmitry Tantsur wrote:
It seems that the new time works for the most of key people, so let's move it to 
tomorrow (Tue), the same time, the same bluejeans.


Apologies to those who won't be able to attend, and sorry for the late notice.

On 10/30/2017 03:13 PM, Jay Pipes wrote:
I'd prefer to have you on the call, Dima. How about we push it back to 
tomorrow at the same time?


Can everyone make it then?

-jay

On 10/30/2017 10:11 AM, Dmitry Tantsur wrote:
Aaaand sorry again, but due to sudden errands I won't be able to attend. 
Please feel free to use my bluejeans room anyway. I think my position on 
traits is more or less clear from previous discussions with John, Sam and Eric.


2017-10-24 18:07 GMT+02:00 Dmitry Tantsur >:


    Sigh, sorry. I forgot that we're moving back to winter time this
    weekend. I *think* the time is 3pm UTC then. It seems to be 11am
    eastern US:
https://www.timeanddate.com/worldclock/converter.html?iso=20171030T15&p1=37&p2=tz_et 

. 




    On 10/24/2017 06:00 PM, Dmitry Tantsur wrote:

    And the winner is Mon, 30 Oct, 2pm UTC!

    The bluejeans ID is https://bluejeans.com/757528759
    
    (works without plugins in recent FF and Chrome; if it asks to
    install an app, ignore it and look for a link saying "join with
    browser")

    On 10/23/2017 05:02 PM, Dmitry Tantsur wrote:

    Hi all!

    I'd like to invite you to the discussion of the way to
    implement traits in
    ironic and the ironic virt driver. Please vote for the time at
    https://doodle.com/poll/ts43k98kkvniv8uz
    . Please vote by
    EOD tomorrow.

    Note that it's going to be a technical discussion - please
    make sure you
    understand what traits are and why ironic cares about them.
    See below for more
    context.

    We'll probably use my bluejeans account, as it works without
    plugins in modern
    browsers. I'll post a meeting ID when we pick the date.


    On 10/23/2017 04:09 PM, Eric Fried wrote:

    We discussed this a little bit further in IRC [1]. 
    We're all in

    agreement, but it's worth being precise on a couple of
    points:

    * We're distinguishing between a "feature" and the
    "trait" that
    represents it in placement.  For the sake of this
    discussion, a
    "feature" can (maybe) be switched on or off, but a
    "trait" can either be
    present or absent on a RP.
    * It matters *who* can turn a feature on/off.
 * If it can be done by virt at spawn time, then it
    makes sense to have
    the trait on the RP, and you can switch the feature
    on/off via a
    separate extra_spec.
 * But if it's e.g. an admin action, and spawn has
    no control, then the
    trait needs to be *added* whenever the feature is *on*,
    and *removed*
    whenever the feature is *off*.

    [1]
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-10-23.log.html#t2017-10-23T13:12:13 

 




    On 10/23/2017 08:15 AM, Sylvain Bauza wrote:



    On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried
    mailto:openst...@fried.cc
    >> wrote:

   I agree with Sean.  In general terms:

   * A resource provider should be marked with a
    trait if that feature
 * Can be turned on or off (whether it's
    currently on or not); or
 * Is always on and can't ever be turned off.


    No, traits are not boolean. If a resource provider
    stops providing a
    capability, then the existing related trait should
    just be removed,
    that's it.
    If you see a trait, that's just means that the
    related capability for
    the Resource Provider is supported, that's it too.

    MHO.

    -Sylvain



   * A consumer wanting that feature present
    (doesn't matter whether it's

[openstack-dev] [Blazar] No meeting next week

2017-11-02 Thread Masahito MUROI


Hi Blazar folks,

Blazar team skips the next weekly meeting since some of us will join the 
Sydney Summit.


best regards,
Masahito


__
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][containers] Please always do mirrored hiera changes for (non)containerized cases

2017-11-02 Thread Bogdan Dobrelya


Hi folks.
When changing hiera defaults for the instack repo or elsewhere, please 
do a "mirrored" change requests to make sure things are consistent for 
containerized overclouds, undercloud containers and those "golden 
images" that instack produces in the end, IIUC.


Please take a look a perfect example with all mirrors all-right [0].
Few more examples for (probably) missing mirrored changes [1], [2].

PS. I wonder how could we automate the check for "missing mirrors" in 
hiera data living instack vs other places?


[0] https://review.openstack.org/#/q/topic:bug/1729293
[1] https://review.openstack.org/#/c/515123/
[2] https://review.openstack.org/#/c/516990/

--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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] [openstack-ansible] Sydney summit -- We'll be there!

2017-11-02 Thread Jean-Philippe Evrard

Hello everyone,

A small delegation of our openstack-ansible team will be in Sydney,
and we are looking forward to meeting all of you!

We'll have an ops feedback session during the forum happening on
Monday 6th, 1:30 pm - 2:10 pm.

If you're willing to get started with openstack-ansible, contribute,
or get to know us, please join us on Tuesday 7th,  9:50 - 10:30 AM.

Last, but not least, if you want to know what happened in
openstack-ansible in the last cycle(s) or if you're interested by our
future strategy, that would be on Tuesday 7th, 5:50 pm - 6:10 pm
during our traditional "Project Update" session.

I am looking forward meeting all of you!

Best regards,
Jean-Philippe Evrard (evrardjp)

PS: We have an etherpad listing all these activities and more details
about the ops session here:
https://etherpad.openstack.org/p/osa-sydney-summit-planning

__
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] [QA] Sydney Summit

2017-11-02 Thread Andrea Frittoli

Dear all,

A few of us from the QA team will be in Sydney at the OpenStack summit.
We will host and on boarding session on Monday afternoon [0] as well as a
few feedback sessions on QA tools through the week [1][2][3].
A project QA update session will take place on Tuesday [4].

If your interested in OpenStack QA, please join us at one of the sessions,
we welcome all type of contributions - feedback, ideas, code, documentation.

We look forward to meeting you in Sydney!

Andrea Frittoli (andreaf)

[0]
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20437/qa-project-onboarding

[1]
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20443/missing-features-and-making-improvements-to-openstack-health

[2]
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20459/the-state-of-test-runners-and-moving-to-stestr

[3]
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20505/users-operators-adoption-of-qa-tools-plugins

[4]
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20385/qa-project-update
__
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] [os-vif] [nova] Changes to os-vif cores

2017-11-02 Thread Stephen Finucane

On Tue, 2017-10-24 at 15:32 +0100, Stephen Finucane wrote:
> Hey,
> 
> I'm not actually sure what the protocol is for adding/removing cores to a
> library project without a PTL, so I'm just going to put this out there: I'd
> like to propose the following changes to the os-vif core team.
> 
> - Add 'nova-core'
> 
>   os-vif makes extensive use of objects and we've had a few hiccups around
>   versionings and the likes recently [1][2]. I'd the expertise of some of the
>   other nova cores here as we roll this out to projects other than nova, and 
>   I trust those not interested/knowledgeable in this area to stay away :)
> 
> - Remove Russell Bryant, Maxime Leroy
> 
>   These folks haven't been active on os-vif  [3][4] for a long time and I 
>   think they can be safely removed.
> 
> To the existing core team members, please respond with a yay/nay and we'll
> wait a week before doing anything.

Both of these are done now. Thanks for the feedback, folks.

Stephen

__
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] [octavia] how to recreate amphora instances

2017-11-02 Thread Kim-Norman Sahm

Hi,

after a rabbitmq problem octavia has removed all amphora instances.
the loadbalancers are in provisioning_status "ACTIVE"

~$ neutron lbaas-loadbalancer-list
neutron CLI is deprecated and will be removed in the future. Use
openstack CLI instead.
| 07b41df6-bb75-4502-975a-20140b0832dd | Load Balancer
4   | 260b0c452e214accaf6cc0e98fb10fc0 |
192.168.1.18   | ACTIVE  | octavia  |
| 25664be7-15cb-426b-ad09-6102afb62b14 | Load Balancer
2   | 260b0c452e214accaf6cc0e98fb10fc0 |
192.168.1.7| ACTIVE  | octavia  |
| 927eb754-7c52-4060-b130-1f5e82d92555 | Load Balancer
6   | 260b0c452e214accaf6cc0e98fb10fc0 |
192.168.1.17   | ACTIVE  | octavia  |
| b4d93c68-89d6-4e4f-b06c-117d4ea933fa | Load Balancer
5   | 260b0c452e214accaf6cc0e98fb10fc0 |
192.168.1.24   | ACTIVE  | octavia  |
| d7699f8d-2106-42d6-8797-5feb72de6e2e | Load Balancer
1   | 260b0c452e214accaf6cc0e98fb10fc0 |
192.168.1.5| ACTIVE  | octavia  |
| dd6114ae-21e9-41bd-b155-325287aed420 | Load Balancer
3   | 260b0c452e214accaf6cc0e98fb10fc0 |
192.168.1.23   | ACTIVE  | octavia  |

How can we trigger octavia to rebuild the amphore instances?
I've tried to restart the octavia services but it didn't solved the
problem.

Best regards
Kim


Kim-Norman Sahm
Cloud & Infrastructure(OCI)
noris network AG
Thomas-Mann-Straße 16-20
90471 Nürnberg
Deutschland
Tel +49 911 9352 1433
Fax +49 911 9352 100

kim-norman.s...@noris.de
https://www.noris.de - Mehr Leistung als Standard
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689






smime.p7s
Description: S/MIME cryptographic signature
__
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] [api][nova] Why we return a redirect (302) when request to 'GET /v2.1'?

2017-11-02 Thread Sean Dague


On 11/01/2017 11:04 PM, Alex X wrote:
There is bug complain about the redirect which returned by the 'GET 
/v2.1' https://launchpad.net/bugs/1728732


'GET /v2.1' will return a redirect to the 'GET /v2.1/'. The response of 
'GET /v2.1/' is the API version info. This seems nova API behaviour for 
a long time.


In the keystone catalog, the endpoint should be the version API I think. 
For nova, it is 'GET /v2.1' which return a redirect instead of version info.


Is there anybody knowing that why we return a redirect?


I thought it was an artifact of the way that paste builds pipelines, and 
the way our resources need urls. I was trying to see if we generate it 
on our side, but I'm not seeing it, so I suspect this is just a 
consequence of the resource mapper and paste.


-Sean

--
Sean Dague
http://dague.net

__
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] Logging format: let's discuss a bit about default format, format configuration and so on

2017-11-02 Thread Juan Antonio Osorio

On Thu, Nov 2, 2017 at 11:15 AM, Bogdan Dobrelya 
wrote:

> Hi. Few comments inline.
>
>
> Dear Stackers,
>> While working on my locally deployed Openstack (Pike using TripleO), I
>> was a bit struggling with the logging part. Currently, all logs are
>> pushed to per-service files, in the standard format "one line per
>> entry", plain flat text.
>>
>> It's nice, but if one is wanting to push and index those logs in an ELK,
>> the current, default format isn't really good.
>>
>> After some discussions about oslo.log, it appears it provides a nice
>> JSONFormatter handler¹ one might want to use for each (python) service
>> using oslo central library.
>>
>> A JSON format is really cool, as it's easy to parse for machines, and it
>> can be on a multi-line without any bit issue - this is especially
>> important for stack traces, as their output is multi-line without real
>> way to have a common delimiter so that we can re-format it and feed it
>> to any log parser (logstash, fluentd, …).
>>
>> After some more talks, olso.log will not provide a unified interface in
>> order to output all received logs as JSON - this makes sens, as that
>> would mean "rewrite almost all the python logging management
>> interface"², and that's pretty useless, since (all?) services have their
>> own "logging.conf" file.
>>
>> That said… to the main purpose of that mail:
>>
>> - Default format for logs
>> A first question would be "are we all OK with the default output format"
>> - I'm pretty sure "humans" are happy with that, as it's really
>> convenient to read and grep. But on a "standard" Openstack deploy, I'm
>> pretty sure one does not have only one controller, one ceph node and one
>> compute. Hence comes the log centralization, and with that, the log
>> indexation and treatments.
>>
>> For that, one might argue "I'm using plain files on my logger, and
>> grep-ing -r in them". That's a way to do things, and for that, plain,
>> flat logs are great.
>>
>> But… I'm pretty sure I'm not the only one wanting to use some kind of
>> ELK cluster for that kind of purpose. So the right question is: what
>> about switching the default log format to JSON? On my part, I don't see
>> "cons", only "pros", but my judgment is of course biased, as I'm "alone
>> in my corner". But what about you, Community?
>>
>> - Provide a way to configure the output format/handler
>> While poking around in the puppet modules code, I didn't find any way to
>> set the output handler for the logs. For example, in puppet-nova³ we can
>> set a lot of things, but not the useful handler for the output.
>>
>
Right, I was also looking into this and am yet to find how it's done. Any
idea how?


>> It would be really cool to get, for each puppet module, the capability
>> to set the handler so that one can just push some stuff in hiera, and
>> Voilà, we have JSON logs.
>>
>> Doing so would allow people to chose between the default  (current)
>> output, and something more "computable".
>>
>
> This is being implemented (for Q) in the scope of this blueprint [0].
> By default, containers will keep the current logging behaviour, which is
> writing logs into bind-mounted host-path directories, and for those
> services that can syslog only, sending the logs to the host journald via
> syslog (bind-mounted /dev/log). And if the stdout/stderr feature enabled,
> side-car containers will make sure everything is captured in journald and
> tagged properly, with multiline entries as well. And journald can dump
> messages as JSON as well. I hope that works! Please send you comments to
> the aforementioned bp's spec.
>
> [0] https://blueprints.launchpad.net/tripleo/+spec/logging-stdout-rsyslog

Correct, as Bogdan mentioned, that will hopefully come as part of the work
of that blueprint. The plan so far is to keep the logs as they currently
are and then put them in JSON format in an rsyslog forwarder (the
implementation is still to come).

However, one thing that would be great would be to have oslo.log already
provide JSON output, that way we would need way less processing. And most
importantly, it would make StackTrace processing easier. Right now it's a
pain to reconstruct python exceptions as they end up being forwarded as
several log lines, and having it as one line, or as JSON output already
would be great. Any idea if this is possible already via oslo.log?

>
>
>
>> Of course, either proposal will require a nice code change in all puppet
>> modules (add a new parameter for the foo::logging class, and use that
>> new param in the configuration file, and so on), but at least people
>> will be able to actually chose.
>>
>> So, before opening an issue on each launchpad project (that would be…
>> long), I'd rather open the discussion in here and, eventually, come to
>> some nice, acceptable and accepted solution that would make the
>> Openstack Community happy :).
>>
>> Any thoughts?
>>
>> Thank you for your attention, feedback and wonderful support for that
>> monster project :).
>>
>

Re: [openstack-dev] [Magnum] Docker Swarm Mode Support

2017-11-02 Thread Spyros Trigazis

Hi Vahric,

A very important reason that we use fedora atomic is that we
are no maintaining our special image. We use the upstream
operating system and we rely on the Fedora Project and we
contribute back to it. If we use ubuntu we would need to
maintain our special qcow image.

We also use the same containers as the Fedora Atomic project
so we have container images tested by more people.

CoreOS is kubernetes oriented, they updated Docker only
last week [1] from 1.12.6 to 17.09. You can contribute a coreos
swarm-mode driver if you want but you it will rely on CoreOS
to update the docker version.

Support for swarm-mode is only added in Pike. You can
follow what Ricardo proposed or as you said update all
your OpenStack services.

Cheers,
Spyros

[1] https://coreos.com/releases/

On 2 November 2017 at 09:34, Ricardo Rocha  wrote:
> Hi again.
>
> On Wed, Nov 1, 2017 at 9:47 PM, Vahric MUHTARYAN  wrote:
>> Hello Ricardo ,
>>
>> Thanks for your explanation and answers.
>> One more question, what is the possibility to keep using Newton (right now i 
>> have it) and use latest Magnum features like swarm mode without upgrade 
>> Openstack ? Does it possible ?
>
> I don't think this functionality is available in Magnum Newton.
>
> One option though is to upgrade only Magnum, there should be no
> dependency on more recent versions of other components - assuming you
> either have a separate control plane for Magnum or are able to split
> it.
>
> Cheers,
>   Ricardo
>
>>
>> Regards
>> VM
>>
>> On 30.10.2017 01:19, "Ricardo Rocha"  wrote:
>>
>> Hi Vahric.
>>
>> On Fri, Oct 27, 2017 at 9:51 PM, Vahric MUHTARYAN  
>> wrote:
>> > Hello All ,
>> >
>> >
>> >
>> > I found some blueprint about supporting Docker Swarm Mode
>> > https://blueprints.launchpad.net/magnum/+spec/swarm-mode-support
>> >
>> >
>> >
>> > I understood that related development is not over yet and no any 
>> Openstack
>> > version or Magnum version to test it also looks like some more thing 
>> to do.
>> >
>> > Could you pls inform when we should expect support of Docker Swarm 
>> Mode ?
>>
>> Swarm mode is already available in Pike:
>> https://docs.openstack.org/releasenotes/magnum/pike.html
>>
>> > Another question is fedora atomic is good but looks like its not 
>> up2date for
>> > docker , instead of use Fedora Atomic , why you do not use Ubuntu, or 
>> some
>> > other OS and directly install docker with requested version ?
>>
>> Atomic also has advantages (immutable, etc), it's working well for us
>> at CERN. There are also Suse and CoreOS drivers, but i'm not familiar
>> with those.
>>
>> Most pieces have moved to Atomic system containers, including all
>> kubernetes components so the versions are decouple from the Atomic
>> version.
>>
>> We've also deployed locally a patch running docker itself in a system
>> container, this will get upstream with:
>> https://bugs.launchpad.net/magnum/+bug/1727700
>>
>> With this we allow our users to deploy clusters with any docker
>> version (selectable with a label), currently up to 17.09.
>>
>> > And last, to help to over waiting items “Next working items: ”  how we 
>> could
>> > help ?
>>
>> I'll let Spyros reply to this and give you more info on the above items 
>> too.
>>
>> Regards,
>>   Ricardo
>>
>> >
>> >
>> >
>> > Regards
>> >
>> > Vahric Muhtaryan
>> >
>> >
>> > 
>> __
>> > 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 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/o

Re: [openstack-dev] [ironic] [nova] traits discussion call - moved to Tue!!

2017-11-02 Thread Ed Leafe

On Nov 2, 2017, at 4:17 AM, Dmitry Tantsur  wrote:
> 
> The recording of the call is https://bluejeans.com/s/K3wZZ

Ugh: "To watch the video, you need Adobe Flash Player 10.1 or higher"


-- Ed Leafe






__
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] [kolla] Proposal to add Marcin (hrw) to kolla images core team

2017-11-02 Thread Michał Jastrzębski

It's my great pleasure to start another voting for core team addition!

Everyone knows hrw, thanks to him Kolla now runs on both Power and ARM!
Voting will be open for 14 days (until 16th of Nov).

Consider this mail my +1 vote

Regards,
Michal

__
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] [kolla] Proposal to add Marcin (hrw) to kolla images core team

2017-11-02 Thread Eduardo Gonzalez

+1 good contributions

2017-11-02 16:58 GMT+01:00 Michał Jastrzębski :

> It's my great pleasure to start another voting for core team addition!
>
> Everyone knows hrw, thanks to him Kolla now runs on both Power and ARM!
> Voting will be open for 14 days (until 16th of Nov).
>
> Consider this mail my +1 vote
>
> Regards,
> Michal
>
> __
> 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] [kolla] Proposal to add Marcin (hrw) to kolla images core team

2017-11-02 Thread Paul Bourke


+1

On 02/11/17 15:58, Michał Jastrzębski wrote:

It's my great pleasure to start another voting for core team addition!

Everyone knows hrw, thanks to him Kolla now runs on both Power and ARM!
Voting will be open for 14 days (until 16th of Nov).

Consider this mail my +1 vote

Regards,
Michal

__
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] [oslo][tripleo][puppet] Logging format: let's discuss a bit about default format, format configuration and so on

2017-11-02 Thread Ben Nemec

Adding tags for the relevant projects. I _think_ this is mostly
directed at Puppet/TripleO, but Oslo is obviously relevant as well.

On 11/01/2017 08:54 AM, Cédric Jeanneret wrote:

Dear Stackers,

While working on my locally deployed Openstack (Pike using TripleO), I
was a bit struggling with the logging part. Currently, all logs are
pushed to per-service files, in the standard format "one line per
entry", plain flat text.

It's nice, but if one is wanting to push and index those logs in an ELK,
the current, default format isn't really good.

After some discussions about oslo.log, it appears it provides a nice
JSONFormatter handler¹ one might want to use for each (python) service
using oslo central library.

That said… to the main purpose of that mail:

For that, one might argue "I'm using plain files on my logger, and
grep-ing -r in them". That's a way to do things, and for that, plain,
flat logs are great.

The major con I see is that we don't require an ELK stack and reading
JSON logs if you don't have one of those is probably worse, although I
will admit I haven't spent much time reading our JSON-formatted logs.
My experience with things that log in JSON has not generally been
positive though. It's just not as human-readable.

The other problem with changing log format defaults is that many people
have already set up filters and processing based on the existing log
format. There are significant user impacts to changing that default.

It would be really cool to get, for each puppet module, the capability
to set the handler so that one can just push some stuff in hiera, and
Voilà, we have JSON logs.

Doing so would allow people to chose between the default (current)
output, and something more "computable".

I think we should do this regardless. There are valid arguments for
people to want both log formats IMHO and we should allow people to use
what they want.

Any thoughts?

Thank you for your attention, feedback and wonderful support for that
monster project :).

Cheers,

Re: [openstack-dev] [kolla] Proposal to add Marcin (hrw) to kolla images core team

2017-11-02 Thread Steven Dake (stdake)

+1

Cheers
-steve

On 11/3/17, 2:59 AM, "Michał Jastrzębski"  wrote:

It's my great pleasure to start another voting for core team addition!

Everyone knows hrw, thanks to him Kolla now runs on both Power and ARM!
Voting will be open for 14 days (until 16th of Nov).

Consider this mail my +1 vote

Regards,
Michal

__
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] [puppet][qa][ubuntu][neutron] Xenial Neutron Timeouts

2017-11-02 Thread Tobias Urdin

I've been staring at this for almost an hour now going through all the logs and 
I can't really pin a point from

where that error message is generated. Cannot find any references for the timed 
out message that the API returns or the unable to associate part.


What I'm currently staring at is why would the instance fixed ip 172.24.5.17 be 
references as a network:router_gateway port in the OVS agent logs.

2017-10-29 
23:19:27.591
 11856 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-7274c6f7-18ef-420d-ad5a-9d0fe4eb35c6 - - - - -] Port 
053a625c-4227-41fb-9a26-45eda7bd2055 updated. Details: {'profile': {}, 
'network_qos_policy_id': None, 'qos_policy_id': None, 'allowed_address_pairs': 
[], 'admin_state_up': True, 'network_id': 
'f9647756-41ad-4ec5-af49-daefe410815e', 'segmentation_id': None, 'fixed_ips': 
[{'subnet_id': 'a31c7115-1f3e-4220-8bdb-981b6df2e18c', 'ip_address': 
'172.24.5.17'}], 'device_owner': u'network:router_gateway', 'physical_network': 
u'external', 'mac_address': 'fa:16:3e:3b:ec:c3', 'device': 
u'053a625c-4227-41fb-9a26-45eda7bd2055', 'port_security_enabled': False, 
'port_id': '053a625c-4227-41fb-9a26-45eda7bd2055', 'network_type': u'flat', 
'security_groups': []}

Anybody else seen anything interesting?

On 10/30/2017 11:08 PM, Brian Haley wrote:

On 10/30/2017 05:46 PM, Matthew Treinish wrote:


 From a quick glance at the logs my guess is that the issue is related
to this stack trace in the l3 agent logs:

http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/neutron/neutron-l3-agent.txt.gz?level=TRACE#_2017-10-29_23_11_15_146

I'm not sure what's causing it to complain there. But, I'm on a plane
right now (which is why this is a top post, sorry) so I can't really dig
much more than that. I'll try to take a deeper look at things later when
I'm on solid ground. (hopefully someone will beat me to it by then though)



I don't think that l3-agent trace is it, as the failure is coming from
the API.  It's actually a trace that's happening due to the async nature
of how the agent runs arping, fix is
https://review.openstack.org/#/c/507914/ but it only removes the log noise.

http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/neutron/neutron-server.txt.gz
has some tracebacks that look config related, possible missing DB table?
  But I haven't looked very closely.

-Brian




On October 31, 2017 1:25:55 AM GMT+04:00, Mohammed Naser
 wrote:

Hi everyone,

I'm looking for some help regarding an issue that we're having with
the Puppet OpenStack modules, we've had very inconsistent failures in
the Xenial with the following error:

 
http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/
 
http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/testr_results.html.gz
 Details: {u'message': u'Unable to associate floating IP
172.24.5.17   to fixed IP10.100.0.8 
  for instance
d265626a-77c1-4d2f-8260-46abe548293e. Error: Request to
https://127.0.0.1:9696/v2.0/floatingips/2e3fa334-d6ac-443c-b5ba-eeb521d6324c
timed out', u'code': 400}

At this point, we're at a bit of a loss.  I've tried my best in order
to find the root cause however we have not been able to do this.  It
was persistent enough that we elected to go non-voting for our Xenial
gates, however, with no fix ahead of us, I feel like this is a waste
of resources and we need to either fix this or drop CI for Ubuntu.  We
don't deploy on Ubuntu and most of the developers working on the
project don't either at this point, so we need a bit of resources.

If you're a user of Puppet on Xenial, we need your help!  Without any
resources going to fix this, we'd unfortunately have to drop support
for Ubuntu because of the lack of resources to maintain it (or
assistance).  We (Puppet OpenStack team) would be more than happy to
work together to fix this so pop-in at #puppet-openstack or reply to
this email and let's get this issue fixed.

Thanks,
Mohammed



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] [ironic] [nova] traits discussion call - moved to Tue!!

2017-11-02 Thread Dmitry Tantsur


On 11/02/2017 04:14 PM, Ed Leafe wrote:

On Nov 2, 2017, at 4:17 AM, Dmitry Tantsur  wrote:


The recording of the call is https://bluejeans.com/s/K3wZZ


Ugh: "To watch the video, you need Adobe Flash Player 10.1 or higher"


I know :( There is a way to download them somewhere there. Look for a small 
download sign appearing when you hover the chapter image below.





-- Ed Leafe






__
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] [puppet][qa][ubuntu][neutron] Xenial Neutron Timeouts

2017-11-02 Thread Mohammed Naser

On Thu, Nov 2, 2017 at 1:02 PM, Tobias Urdin  wrote:
> I've been staring at this for almost an hour now going through all the logs
> and I can't really pin a point from
>
> where that error message is generated. Cannot find any references for the
> timed out message that the API returns or the unable to associate part.
>
>
> What I'm currently staring at is why would the instance fixed ip 172.24.5.17
> be references as a network:router_gateway port in the OVS agent logs.
>
> 2017-10-29 23:19:27.591 11856 INFO
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> [req-7274c6f7-18ef-420d-ad5a-9d0fe4eb35c6 - - - - -] Port
> 053a625c-4227-41fb-9a26-45eda7bd2055 updated. Details: {'profile': {},
> 'network_qos_policy_id': None, 'qos_policy_id': None,
> 'allowed_address_pairs': [], 'admin_state_up': True, 'network_id':
> 'f9647756-41ad-4ec5-af49-daefe410815e', 'segmentation_id': None,
> 'fixed_ips': [{'subnet_id': 'a31c7115-1f3e-4220-8bdb-981b6df2e18c',
> 'ip_address': '172.24.5.17'}], 'device_owner': u'network:router_gateway',
> 'physical_network': u'external', 'mac_address': 'fa:16:3e:3b:ec:c3',
> 'device': u'053a625c-4227-41fb-9a26-45eda7bd2055', 'port_security_enabled':
> False, 'port_id': '053a625c-4227-41fb-9a26-45eda7bd2055', 'network_type':
> u'flat', 'security_groups': []}
>
>
> Anybody else seen anything interesting?

Hi Tobias,

Thanks for looking out.  I've spent a lot of time and I haven't
successfully identified much, I can add the following

- This issue is intermittent in CI
- It does *not* happen on any specific providers, I've seen it fail on
both OVH and Rackspace.
- Not *all* floating iP assignments fail, if you look at the logs, you
can see it attach a few successfully before failing

But yeah, I'm still quite at a loss and not having this coverage isn't fun.

>
>
> On 10/30/2017 11:08 PM, Brian Haley wrote:
>
> On 10/30/2017 05:46 PM, Matthew Treinish wrote:
>
>  From a quick glance at the logs my guess is that the issue is related
> to this stack trace in the l3 agent logs:
>
> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/neutron/neutron-l3-agent.txt.gz?level=TRACE#_2017-10-29_23_11_15_146
>
> I'm not sure what's causing it to complain there. But, I'm on a plane
> right now (which is why this is a top post, sorry) so I can't really dig
> much more than that. I'll try to take a deeper look at things later when
> I'm on solid ground. (hopefully someone will beat me to it by then though)
>
> I don't think that l3-agent trace is it, as the failure is coming from
> the API.  It's actually a trace that's happening due to the async nature
> of how the agent runs arping, fix is
> https://review.openstack.org/#/c/507914/ but it only removes the log noise.
>
> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/neutron/neutron-server.txt.gz
> has some tracebacks that look config related, possible missing DB table?
>   But I haven't looked very closely.
>
> -Brian
>
>
> On October 31, 2017 1:25:55 AM GMT+04:00, Mohammed Naser
>  wrote:
>
> Hi everyone,
>
> I'm looking for some help regarding an issue that we're having with
> the Puppet OpenStack modules, we've had very inconsistent failures in
> the Xenial with the following error:
>
>
> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/
>
> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/testr_results.html.gz
>  Details: {u'message': u'Unable to associate floating IP
> 172.24.5.17   to fixed IP10.100.0.8
>   for instance
> d265626a-77c1-4d2f-8260-46abe548293e. Error: Request to
>
> https://127.0.0.1:9696/v2.0/floatingips/2e3fa334-d6ac-443c-b5ba-eeb521d6324c
> timed out', u'code': 400}
>
> At this point, we're at a bit of a loss.  I've tried my best in order
> to find the root cause however we have not been able to do this.  It
> was persistent enough that we elected to go non-voting for our Xenial
> gates, however, with no fix ahead of us, I feel like this is a waste
> of resources and we need to either fix this or drop CI for Ubuntu.  We
> don't deploy on Ubuntu and most of the developers working on the
> project don't either at this point, so we need a bit of resources.
>
> If you're a user of Puppet on Xenial, we need your help!  Without any
> resources going to fix this, we'd unfortunately have to drop support
> for Ubuntu because of the lack of resources to maintain it (or
> assistance).  We (Puppet OpenStack team) would be more than happy to
> work together to fix this so pop-in at #puppet-openstack or reply to
> this email and let's get this issue fixed.
>
> Thanks,
> Mohammed
>
> -

Re: [openstack-dev] [Openstack-operators] [Forum] Moderators needed!

2017-11-02 Thread Alan Meadows

Apologizes for resurrecting a dead thread but context is important. We had
a great discussion in Boston on this topic especially around health APIs
and everyone was really very understanding of the over-size brain
situation.  We didn't do our best bringing back the output of that to the
mailing list, but we have a chance to try again in Sydney with Part II!

This time we'll make sure the discussion works its way back properly to the
development mailing list.

https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20472/cloud-native-designrefactoring-across-openstack-part-ii

I'd encourage everyone who has an interest in this topic to attend.  See
you in Sydney.

Alan Meadows

On Fri, Apr 28, 2017 at 6:07 AM, Jay Pipes  wrote:

> On 04/28/2017 08:22 AM, Shamail Tahir wrote:
>
>> Hi everyone,
>>
>> Most of the proposed/accepted Forum sessions currently have moderators
>> but there are six sessions that do not have a confirmed moderator yet.
>> Please look at the list below and let us know if you would be willing to
>> help moderate any of these sessions.
>>
>
> 
>
> Cloud-Native Design/Refactoring across OpenStack
>> > e/events/18767/cloud-native-designrefactoring-across-openstack>
>>
>
> Hi Shamail,
>
> The one above looks like Alan (cc'd) is the moderator. :)
>
> Despite him having a awkwardly over-sized brain -- which unfortunately
> will limit the number of other people that can fit in the room -- I do
> think Alan will be a good moderator.
>
> Best,
> -jay
>
__
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] [telemetry] ceilometer-notification restart with no consumers on ceilometer-pipe

2017-11-02 Thread gordon chung



On 17/10/17 11:17 PM, 李田清 wrote:
> Hello,
> I am testing ceilometer workload partition. And find that if we restart
> agent notification, the ceilometer-pip* queue will not have
> consumers any more.
> Does anyone know this? The pipeline.yaml is
> here http://paste.openstack.org/show/623909/
> And i also find the ceilometer-pipe-meter_source:meter_sink-queue
> always has many messages in it.
> Does anyone met this before, or some suggestions can share? Thanks a
> lot...
>

what version of code was this? i just found a pretty big bug that 
basically makes partitioning completely broken. this would affect 
stable/pike and master

cheers.

-- 
gord
__
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] [ironic] [nova] traits discussion call - moved to Tue!!

2017-11-02 Thread Eric Fried

Here's the executive summary of the meeting:

Topic: How does Nova communicate to the Ironic virt driver that the user
wants a particular RAID setup or boot mode or whatever?

o Level set: Traits are an indication of capability, not state.  To be
clear: if a RP (e.g. ironic node) has traits indicating it's capable of
X, Y, Z (mutually exclusive), and you deploy and configure it to do Y,
you should *not* remove traits X and Z from it.  We all agree on this.
Vehemently.  Aggressively.  (But see [1].)

o It would be neat if we could indicate both things from one place,
rather than having to say, "I need a node that is capable of X,"
and also, separately, "Turn X on".

o Proposed: Config Template traits [2]
- A Config Template describes all the complex configuration parameters
  for e.g. a RAID setup.
- It is represented by a name.
- That name can map to a (custom) trait name.
- Now we can decorate any node capable of deploying that config template
  with that trait.
- Specify the trait just like any other in the flavor extra_specs.
- Ironic virt driver sends the trait to Ironic via instance_info.
- Ironic keys off of the trait to look up the Config Template and use it
  to configure the node.

o It was noted that this will wind up being too coarse; eventually
you'll want something more granular.  E.g. you need templates for
"RAID 5 with 4 disks", "RAID 5 with 7 disks", etc.  Ideally we would
pass this info from Nova to Ironic as a separate "thing" (not via a
trait - not even via flavor extra_specs at all).  But for now, Config
Template traits is workable.

o Traits will be set on nodes by Ironic in the same place/way as it sets
up custom per-node resource classes today.

o Specific scenarios were discussed:
  - RAID configurations.  These can be handled by Config Template
traits.
  - Boot modes.  This is tricky because some aspects of boot mode are
capabilities of the node; some are a function of the image; some are
a function of the flavor.  The end result is some combination of all
of these things.

o Note that this trait stuff happens early in the scheduling process.
Placement does the filtering based on traits and resources *first*.
Then stuff gets fed into filters, then weighers.  "Capabilities" will
not be removed short-term.

o Other specs, for reference: [3] [4].

o Action: Jay to propose os-traits for RAID levels and boot modes.

o It was Halloween.  There were costumes.  [5] [6].

[1] (In the future, there may be weigher things, like "preferred" and
"non-preferred".  E.g. my node may have traits RAID5 and
FASTPATH_RAID5 (meaning it can configure itself as RAID-5 faster than some
node that just has RAID5).  I can say
required=RAID5,preferred=FASTPATH_RAID5 and I'll get a node with
RAID5+FASTPATH_RAID5 if available; else just RAID5.

There may also be a "negative trait" concept, so I could say
forbidden=CUSTOM_X,
and the scheduler would *avoid* any node with CUSTOM_X.  This *would* be
a scheduler thing, not a weigher thing.

[2] Config Template traits (ironic-specs):
https://review.openstack.org/#/c/504952/
[3] Support traits in the Ironic driver (nova-specs):
https://review.openstack.org/#/c/507052/
[4] Traits on Ironic Nodes (ironic-specs):
https://review.openstack.org/#/c/504531/
[5] https://leafe.com/tmp/fried.jpg
[6] http://www.taylorbjj.com/wp-content/uploads/2017/11/TheJulia.jpg

On 11/02/2017 12:01 PM, Dmitry Tantsur wrote:
> On 11/02/2017 04:14 PM, Ed Leafe wrote:
>> On Nov 2, 2017, at 4:17 AM, Dmitry Tantsur  wrote:
>>>
>>> The recording of the call is https://bluejeans.com/s/K3wZZ
>>
>> Ugh: "To watch the video, you need Adobe Flash Player 10.1 or higher"
> 
> I know :( There is a way to download them somewhere there. Look for a
> small download sign appearing when you hover the chapter image below.
> 
>>
>>
>> -- Ed Leafe
>>
>>
>>
>>
>>
>>
>> __
>>
>> 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 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] [kolla] Proposal to add Marcin (hrw) to kolla images core team

2017-11-02 Thread Richard Wellum

+1 great contributor

Cheers,

//Rich

On Thu, Nov 2, 2017, 12:55 PM Steven Dake (stdake)  wrote:

> +1
>
> Cheers
> -steve
>
> On 11/3/17, 2:59 AM, "Michał Jastrzębski"  wrote:
>
> It's my great pleasure to start another voting for core team addition!
>
> Everyone knows hrw, thanks to him Kolla now runs on both Power and ARM!
> Voting will be open for 14 days (until 16th of Nov).
>
> Consider this mail my +1 vote
>
> Regards,
> Michal
>
>
> __
> 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 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] legacy-tripleo-ci-centos-7-undercloud-containers job needs attention

2017-11-02 Thread Wesley Hayutin

Greetings,

We noticed the job  legacy-tripleo-ci-centos-7-undercloud-containers
failing in the gate in the following patches [1], [2].  The job was voting
in the review here [3].  ATM the job is non-voting in check and voting in
the gate.  This is a dangerous combination where the job can fail in check
unnoticed and also fail in the gate.  This can cause the gate to reset
often and delay other patches from merging.

We either need the job to become voting in check, or removed from the
gate.  Either action is fine but needs to be taken immediately.

Looking at some stats for the job itself comparing the containerized
undercloud vs. the old non-containerized job via [4].

legacy-tripleo-ci-centos-7-undercloud-containers
pass rate overall: 78%  as of 11/2/2017

legacy-tripleo-ci-centos-7-undercloud-oooq
pass rate overall: 92.6% as of 11/2/2017

Thanks for reading through this and for helping out in advance!

[1] https://review.openstack.org/#/c/514576/
[2] https://review.openstack.org/#/c/517023/
[3] https://review.openstack.org/#/c/513163/
[4] http://cistatus.tripleo.org/
__
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] [kolla] Proposal to add Marcin (hrw) to kolla images core team

2017-11-02 Thread Xinliang Liu

+1, as I know hrw makes great contribution on ARM.

On 2 November 2017 at 23:58, Michał Jastrzębski  wrote:
> It's my great pleasure to start another voting for core team addition!
>
> Everyone knows hrw, thanks to him Kolla now runs on both Power and ARM!
> Voting will be open for 14 days (until 16th of Nov).
>
> Consider this mail my +1 vote
>
> Regards,
> Michal
>
> __
> 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] [Nova] Privsep transition state of play

2017-11-02 Thread Michael Still

Greetings,

I hope everyone travelling to the Sydney Summit is enjoying jet lag just as
much as I normally do. Revenge is sweet! My big advice is that caffeine is
your friend, and to not lick any of the wildlife.

On a more serious note, I want to give a checkpoint for the Nova privsep
transition in the hope that we can discuss it a bit more at the Forum /
Summit / whatever the thing in Sydney with developers is called [1].

As of just now, all rootwrap usage has been removed from the libvirt
driver, if you assume that the outstanding patches from the blueprint are
merged. I think that's a pretty cool milestone. That said, I feel that
https://review.openstack.org/#/c/517516/ needs a short talk to make sure
that people don't think the implementation approach I've taken is confusing
-- basically not all methods in nova/privsep are now escalated, as
sometimes we only sometimes escalate our privs for a call. The review makes
it clearer than I can in an email.

We could stop now for Queens if we wanted -- we originally said we'd land
things early to let them stabilise. That said, we haven't actually caused
any stability problems so far -- just a few out of tree drivers having to
play catchup. So we could also go all in and get this thing done fully in
Queens.

So where to from here?

Michael

1: Its possibly called a pub.
__
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] [forum] Sydney Forum etherpad list

2017-11-02 Thread Michael Still

The privsep session doesn't appear to be in that list. Did it get dropped
or something?

Michael

On Wed, Nov 1, 2017 at 12:04 AM, Thierry Carrez 
wrote:

> Hi everyone,
>
> Etherpads for the Forum sessions in Sydney can be found here:
>
> https://wiki.openstack.org/wiki/Forum/Sydney2017
>
> If you are moderating such a session and the etherpad is missing, please
> add it !
>
> --
> Thierry Carrez (ttx)
>
> __
> 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] [kolla] Proposal to add Marcin (hrw) to kolla images core team

2017-11-02 Thread Jeffrey Zhang

+1

On Fri, Nov 3, 2017 at 9:46 AM, Xinliang Liu 
wrote:

> +1, as I know hrw makes great contribution on ARM.
>
> On 2 November 2017 at 23:58, Michał Jastrzębski  wrote:
> > It's my great pleasure to start another voting for core team addition!
> >
> > Everyone knows hrw, thanks to him Kolla now runs on both Power and ARM!
> > Voting will be open for 14 days (until 16th of Nov).
> >
> > Consider this mail my +1 vote
> >
> > Regards,
> > Michal
> >
> > 
> __
> > 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
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [tricircle]Distinguish the direction of requests

2017-11-02 Thread joehuang

Hello,

As you are talking about how to distinguish the request to local Neutron and 
central Neutron, do you mean how to set the "USER_AGENT" in the request header, 
and how to extract the "USER_AGENT" and stored it in the context? Though it's 
mentioned in 
https://developer.openstack.org/sdks/python/openstacksdk/users/connection.html

This field has not been extracted neither in oslo.context, nor neutron-lib 
context:

https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py
https://github.com/openstack/neutron-lib/blob/master/neutron_lib/context.py

May be we can add it in oslo.context?

Best Regards
Chaoyi Huang (joehuang)

From: XuZhuang [xu_ly...@163.com]
Sent: 01 November 2017 19:49
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [tricircle]Distinguish the direction of requests

Hello,


I have some questions in how to distinguish the direction of requests between 
local neutron and central neutron.


There is the preliminary plan


1. For how to distinguish the requests in central neutron

we can add a filter in neutron/…./etc/api-paste.ini. Using this filter we can 
get some values about the source.

But the question is that the process of loading filter is in Neutron. Without 
changing Neutron how could we add a filter? Could we change Neutron?


2. For how to add a signal in the requests

The module of common.client in Tricircle is responsible for sending requests. 
So we can add a signal in the header of requests. And central plugin will get 
this signal using the filter.


Best Regards

Zhuangzhuang Xu (Lyman Xu)




__
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] [kolla] Proposal to add Marcin (hrw) to kolla images core team

2017-11-02 Thread Surya Prakash Singh

+1 

Good Work !!!  Marcin

---
Thanks
Surya

-Original Message-
From: Michał Jastrzębski [mailto:inc...@gmail.com] 
Sent: Thursday, November 2, 2017 9:29 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [kolla] Proposal to add Marcin (hrw) to kolla images 
core team

It's my great pleasure to start another voting for core team addition!

Everyone knows hrw, thanks to him Kolla now runs on both Power and ARM!
Voting will be open for 14 days (until 16th of Nov).

Consider this mail my +1 vote

Regards,
Michal

__
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] Cancel neutron-fwaas weekly meeting (11/9)

2017-11-02 Thread Furukawa, Yushiro

Hi FWaaS folks,

Because we're in Sydney or on flight, we'll cancel weekly meeting at 9th Nov.

Best regards,


Yushiro Furukawa




__
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] [neutron][fwaas]Cancel neutron-fwaas weekly meeting (11/9)

2017-11-02 Thread Furukawa, Yushiro

Oops, so sorry.  I forgot to insert subject..

Thanks,

Yushiro Furukawa


> -Original Message-
> From: Furukawa, Yushiro [mailto:y.furukaw...@jp.fujitsu.com]
> Sent: Friday, November 3, 2017 2:29 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: [openstack-dev] Cancel neutron-fwaas weekly meeting (11/9)
> 
> Hi FWaaS folks,
> 
> Because we're in Sydney or on flight, we'll cancel weekly meeting at 9th Nov.
> 
> Best regards,
> 
> 
> Yushiro Furukawa
> 
> 
> 
> 
> __
> 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] [kolla] Proposal to add Marcin (hrw) to kolla images core team

2017-11-02 Thread Gema Gomez

+1

On 02/11/17 15:58, Michał Jastrzębski wrote:
> It's my great pleasure to start another voting for core team addition!
> 
> Everyone knows hrw, thanks to him Kolla now runs on both Power and ARM!
> Voting will be open for 14 days (until 16th of Nov).
> 
> Consider this mail my +1 vote
> 
> Regards,
> Michal
> 
> __
> 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] [api][nova] Why we return a redirect (302) when request to 'GET /v2.1'?

2017-11-02 Thread Alex Xu

2017-11-02 20:42 GMT+08:00 Sean Dague :

> On 11/01/2017 11:04 PM, Alex X wrote:
>
>> There is bug complain about the redirect which returned by the 'GET
>> /v2.1' https://launchpad.net/bugs/1728732
>>
>> 'GET /v2.1' will return a redirect to the 'GET /v2.1/'. The response of
>> 'GET /v2.1/' is the API version info. This seems nova API behaviour for a
>> long time.
>>
>> In the keystone catalog, the endpoint should be the version API I think.
>> For nova, it is 'GET /v2.1' which return a redirect instead of version info.
>>
>> Is there anybody knowing that why we return a redirect?
>>
>
> I thought it was an artifact of the way that paste builds pipelines, and
> the way our resources need urls. I was trying to see if we generate it on
> our side, but I'm not seeing it, so I suspect this is just a consequence of
> the resource mapper and paste.


It is generated it on our side
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/routes.py#L410



>
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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] [oslo][tripleo][puppet] Logging format: let's discuss a bit about default format, format configuration and so on

2017-11-02 Thread Cédric Jeanneret

On 11/02/2017 05:18 PM, Ben Nemec wrote:
> Adding tags for the relevant projects.  I _think_ this is mostly
> directed at Puppet/TripleO, but Oslo is obviously relevant as well.

Thank you! First mail in there, wasn't really sure how to do that.

> 
> On 11/01/2017 08:54 AM, Cédric Jeanneret wrote:
>> Dear Stackers,
>>
>> While working on my locally deployed Openstack (Pike using TripleO), I
>> was a bit struggling with the logging part. Currently, all logs are
>> pushed to per-service files, in the standard format "one line per
>> entry", plain flat text.
>>
>> It's nice, but if one is wanting to push and index those logs in an ELK,
>> the current, default format isn't really good.
>>
>> After some discussions about oslo.log, it appears it provides a nice
>> JSONFormatter handler¹ one might want to use for each (python) service
>> using oslo central library.
>>
>> A JSON format is really cool, as it's easy to parse for machines, and it
>> can be on a multi-line without any bit issue - this is especially
>> important for stack traces, as their output is multi-line without real
>> way to have a common delimiter so that we can re-format it and feed it
>> to any log parser (logstash, fluentd, …).
>>
>> After some more talks, olso.log will not provide a unified interface in
>> order to output all received logs as JSON - this makes sens, as that
>> would mean "rewrite almost all the python logging management
>> interface"², and that's pretty useless, since (all?) services have their
>> own "logging.conf" file.
>>
>> That said… to the main purpose of that mail:
>>
>> - Default format for logs
>> A first question would be "are we all OK with the default output format"
>> - I'm pretty sure "humans" are happy with that, as it's really
>> convenient to read and grep. But on a "standard" Openstack deploy, I'm
>> pretty sure one does not have only one controller, one ceph node and one
>> compute. Hence comes the log centralization, and with that, the log
>> indexation and treatments.
>>
>> For that, one might argue "I'm using plain files on my logger, and
>> grep-ing -r in them". That's a way to do things, and for that, plain,
>> flat logs are great.
>>
>> But… I'm pretty sure I'm not the only one wanting to use some kind of
>> ELK cluster for that kind of purpose. So the right question is: what
>> about switching the default log format to JSON? On my part, I don't see
>> "cons", only "pros", but my judgment is of course biased, as I'm "alone
>> in my corner". But what about you, Community?
> 
> The major con I see is that we don't require an ELK stack and reading
> JSON logs if you don't have one of those is probably worse, although I
> will admit I haven't spent much time reading our JSON-formatted logs. My
> experience with things that log in JSON has not generally been positive
> though.  It's just not as human-readable.

We're on the same line on that - hence the following proposal. I was
pretty sure switching the default format was a bad thing, but I had to
submit it in order to be complete ;).
Let's focus on the other one, as it's more friendly for everyone.

> 
> The other problem with changing log format defaults is that many people
> have already set up filters and processing based on the existing log
> format.  There are significant user impacts to changing that default.
> 
>>
>> - Provide a way to configure the output format/handler
>> While poking around in the puppet modules code, I didn't find any way to
>> set the output handler for the logs. For example, in puppet-nova³ we can
>> set a lot of things, but not the useful handler for the output.
>>
>> It would be really cool to get, for each puppet module, the capability
>> to set the handler so that one can just push some stuff in hiera, and
>> Voilà, we have JSON logs.
>>
>> Doing so would allow people to chose between the default  (current)
>> output, and something more "computable".
> 
> I think we should do this regardless.  There are valid arguments for
> people to want both log formats IMHO and we should allow people to use
> what they want.

If I understand the things correctly, that would require a "small"
change in every puppet modules so that it configures the service with
the proper log output. Any way to automate something on that? It might
be worth to do some PoC on a specific module maybe?


> 
>>
>> Of course, either proposal will require a nice code change in all puppet
>> modules (add a new parameter for the foo::logging class, and use that
>> new param in the configuration file, and so on), but at least people
>> will be able to actually chose.
>>
>> So, before opening an issue on each launchpad project (that would be…
>> long), I'd rather open the discussion in here and, eventually, come to
>> some nice, acceptable and accepted solution that would make the
>> Openstack Community happy :).
>>
>> Any thoughts?
>>
>> Thank you for your attention, feedback and wonderful support for that
>> monster project :).
>>
>> Cheers,
>>
>> C.
>>
>>

Re: [openstack-dev] [kolla] Proposal to add Marcin (hrw) to kolla images core team

2017-11-02 Thread Martin André

+1

On Thu, Nov 2, 2017 at 4:58 PM, Michał Jastrzębski  wrote:
> It's my great pleasure to start another voting for core team addition!
>
> Everyone knows hrw, thanks to him Kolla now runs on both Power and ARM!
> Voting will be open for 14 days (until 16th of Nov).
>
> Consider this mail my +1 vote
>
> Regards,
> Michal
>
> __
> 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

41 matches

Mail list logo