[openstack-dev] [neutron][fwaas]Cancel neutron-fwaas weekly meeting (11/9)

[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

[openstack-dev] Cancel neutron-fwaas weekly meeting (11/9)

[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

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

[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

Re: [openstack-dev] [tricircle]Distinguish the direction of requests

[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] Compute Node shutdown how to prevent instance suspend

[Chris]

Hello Tzach,

Agree for a graceful shutdown there should be some steps ahead. Im 
actually asking the question because the hardware we use has a high 
failure rate on RAID controllers. The physical machine reacts with a 
reboot, so its not controlable from our side. We dont want to delete the 
instances at all, its just about the Instance shutdown/process kill.


Got a good answer already:
If you are using CentOS  / Red Hat you can modify this file:
/etc/sysconfig/libvirt-guests
libvirt-guests:#ON_SHUTDOWN=suspend


Thanks for your answer!

Cheers Chris


On 2017-11-02 15:54, Tzach Shefi wrote:

Hi, 

A better Q would be why do you shutdown a compute node to begin with?
I mean if you need you should do so in an orderly fashion basically
excavate instances

or shut instances down manually, put the compute node in maintenance
mode. 
On rebooting compute node remove it from maintenance mode, turn on
instances or migrate them back to this compute node should you need. 
Od delete them if you wish. 

There is this nova option:
resume_guests_state_on_host_boot=true

But it doesn't delete or shutdown instances but rather turns them on
automatically once compute host resumes. 
which might also work for you, probably not just mentioning it any
way.  

I don't know of an option to stop/delete instance on compute node
shutdown. 

Another option check maybe you could shelve suspended instance and
then later delete them. 

Shelving stops the instance and takes a snapshot of it. Then depending
on the value of the shelved_offload_time config option, the instance
is deleted from the hypervisor (0), never deleted (-1), or deleted
after some period of time (> 0). Note that it's just destroying the
backing instance on the hypervisor, the actual instance in the nova
database is not deleted. Then you can later unshelve the instance:

This might help, but do not if you mess with kvm without updating Nova
you might be left haning else where :)
https://ask.fedoraproject.org/en/question/8796/make-libvirt-to-shutdown-my-guests-not-suspend/
[2]

 

On Thu, Nov 2, 2017 at 9:03 AM, Chris  wrote:


Hello,

When we shut down a compute node the instances running on it get
suspended. This generates some difficulties with some applications
like RabbitMQ dont like to be suspended. Is there a way to change
this behavior so that the running instances gets killed or shutdown
instead?

Thanks in advance.

Cheers,
Chris

___
Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]
Post to     : openstack@lists.openstack.org
Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]


--

Tzach Shefi

Senior Quality Engineer, RHCSA

Red Hat

 tsh...@redaht.com    M: +972-54-4701080 [3]     IM: tshefi

 [4]



Links:
--
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[2]
https://ask.fedoraproject.org/en/question/8796/make-libvirt-to-shutdown-my-guests-not-suspend/
[3] tel:+972-54-4701080
[4] https://red.ht/sig


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Compute Node shutdown how to prevent instance suspend

[Chris]

Hello Remo,

Exactly what I was looking for! If I could give you a rating it would be 
the highest :)


Cheers,
Chris

On 2017-11-03 1:27, Remo Mattei wrote:

sorry forgot to paste the file location
/etc/sysconfig/libvirt-guests




On 11/2/17 11:21 AM, Remo Mattei wrote:

If you are using CentOS  / Red Hat you can modify this file:

libvirt-guests:#ON_SHUTDOWN=suspend



# action taken on host shutdown
# - suspend   all running guests are suspended using virsh managedsave
# - shutdown  all running guests are asked to shutdown. Please be
careful with
# this settings since there is no way to distinguish 
between a
# guest which is stuck or ignores shutdown requests and a 
guest

# which just needs a long time to shutdown. When setting
# ON_SHUTDOWN=shutdown, you must also set SHUTDOWN_TIMEOUT 
to a

# value suitable for your guests.
#ON_SHUTDOWN=suspend



Hope this help.

Remo

On 11/2/17 11:08 AM, Chris Friesen wrote:

On 11/02/2017 01:03 AM, Chris wrote:

Hello,

When we shut down a compute node the instances running on it get
suspended. This
generates some difficulties with some applications like RabbitMQ 
dont

like to be
suspended. Is there a way to change this behavior so that the 
running

instances
gets killed or shutdown instead?
This may be done by the libvirtd shutdown scripts rather than 
anything

in nova.

As others have said, you should probably either shut down the VMs in
an orderly fashion or else cold/live migrate the instances off the
compute node before rebooting it.

Chris

___
Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
Mailing list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Post to : openstack@lists.openstack.org
Unsubscribe : 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack



___
Mailing list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Post to : openstack@lists.openstack.org
Unsubscribe : 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

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

[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-operators] [openstack-dev] [forum] Sydney Forum etherpad list

[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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [forum] Sydney Forum etherpad list

[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

[openstack-dev] [Nova] Privsep transition state of play

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

[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] [tripleo] legacy-tripleo-ci-centos-7-undercloud-containers job needs attention

[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] Compute Node shutdown how to prevent instance suspend

[Van Leeuwen, Robert]

>There is this nova option:
>resume_guests_state_on_host_boot=true
>
>But it doesn't delete or shutdown instances but rather turns them on 
>automatically once compute host resumes.
>which might also work for you, probably not just mentioning it any way.

Note that you might want to check some things after a reboot before booting up 
all your instances.
The easiest way would be to set this value to true but to not start the 
nova-compute service on boot.
Now you can check whatever you need and start nova-compute when you know the 
server is in a good state.
Nova will now start the instances that where running when your compute node was 
shutdown.
The nice thing about this is that any instances that where shutdown/suspended 
by users will keep in a shutdown state.
If you do not do this you would need to create a custom script that saves which 
instances where running before the shutdown and then use that list to start 
only the correct instances.

Another thing to consider is if you want to auto-start instances after a 
compute node did an unexpected reboot.
IMHO I would rather have a dead instance then an instance running on flaky 
hard/software but it might depend a bit on your use case.

>I don't know of an option to stop/delete instance on compute node shutdown.
As mentioned by some other people this is actually a libvirt setting not a nova 
setting.


Cheers,
Robert van Leeuwen
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

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

[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

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

[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] [telemetry] ceilometer-notification restart with no consumers on ceilometer-pipe

[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] help - Fuel Community 11 - PXE

[Remo Mattei]

you could upgrade to Tripleo :)

Ciao,


On 11/2/17 11:18 AM, Ken Houle wrote:
>
> Evgeniy L.
>
>  
>
> Thank you for the information. I have rebuilt the Fuel Community 11
> server and left everything default with the exception of setting the
> PXE support to eth1. I am seeing the same issue.
>
> The Silicon Mechanics server with a Supermicro system board as been
> configured in every possible boot configuration that I can think of;
> and I’m still seeing the “PXE-E7B” error.
>
>  
>
>  
>
> I’m about to consign this server to another use.
>
>  
>
>  
>
>  
>
> Regards,
>
>  
>
> /Ken Houle/
> 469-634-4171 :
> kho...@developingsolutions.com
>
>  
>
> *From:* Evgeniy L [mailto:e...@mirantis.com]
> *Sent:* Tuesday, October 31, 2017 9:58 AM
> *To:* Ken Houle 
> *Cc:* Openstack 
> *Subject:* Re: [Openstack] help - Fuel Community 11 - PXE
>
>  
>
> I'm not sure if these options should be set, because they are required
> only if PXE server is on different host from DHCP server, which is not
> the case for Fuel.
>
>  
>
> On Thu, Oct 26, 2017 at 8:25 AM, Ken Houle
>  > wrote:
>
> Evgeniy L:
>
>  
>
> Thank you for the information. I have a few, possible silly/noob,
> question. After your email I reviewed the tcpdump again and
> identified that the “dhcp offer” does not contain options 66 and 67.
>
> You can see from the excerpt of a bootp capture the highlighted
> portions contain the IP address offered, next server, and boot file.
>
>  
>
> However, in the options section there is not an option 66, tftp
> server name, and option 67, bootfile name.
>
>  
>
> SO here is the question, taking cobbler into account which file
> should I be editing to attempt to add these options? Is the
> “/etc/cobbler/dhcp.template” file the correct file; thought
> “template” seems to  indicate that it is not?
>
> If not, again silly/noob, which file should I be editing.
>
>  
>
> Any assistance would be appreciated.
>
>  
>
>  
>
> Frame 4138: 342 bytes on wire (2736 bits), 342 bytes captured
> (2736 bits)
>
> Ethernet II, Src: Dell_b9:6a:02 (d4:ae:52:b9:6a:02), Dst:
> Broadcast (ff:ff:ff:ff:ff:ff)
>
> Internet Protocol Version 4, Src: 10.10.30.10, Dst: 255.255.255.255
>
> User Datagram Protocol, Src Port: 67, Dst Port: 68
>
> Bootstrap Protocol (Offer)
>
>     Message type: Boot Reply (2)
>
>     Hardware type: Ethernet (0x01)
>
>     Hardware address length: 6
>
>     Hops: 0
>
>     Transaction ID: 0x906a77f9
>
>     Seconds elapsed: 18
>
>     Bootp flags: 0x8000, Broadcast flag (Broadcast)
>
>     1...    = Broadcast flag: Broadcast
>
>     .000    = Reserved flags: 0x
>
>     Client IP address: 0.0.0.0
>
>     Your (client) IP address: 10.10.30.21
>
>     Next server IP address: 10.10.30.10
>
>     Relay agent IP address: 0.0.0.0
>
>     Client MAC address: SuperMic_6a:77:f9 (00:25:90:6a:77:f9)
>
>     Client hardware address padding: 
>
>     Server host name: boothost
>
>     Boot file name: pxelinux.0
>
>     Magic cookie: DHCP
>
>     Option: (53) DHCP Message Type (Offer)
>
>     Option: (54) DHCP Server Identifier
>
>     Option: (51) IP Address Lease Time
>
>     Option: (58) Renewal Time Value
>
>     Option: (59) Rebinding Time Value
>
>     Option: (1) Subnet Mask
>
>     Option: (28) Broadcast Address
>
>     Option: (15) Domain Name
>
>     Option: (6) Domain Name Server
>
>     Option: (3) Router
>
>     Option: (255) End
>
>     Padding: 00
>
>  
>
> Regards,
>
>  
>
> /Ken Houle/
> 469-634-4171 : kho...@developingsolutions.com
> 
>
>  
>
> *From:* Evgeniy L [mailto:e...@mirantis.com ]
> *Sent:* Wednesday, October 25, 2017 11:45 AM
> *To:* Ken Houle  >
> *Cc:* Openstack  >
> *Subject:* Re: [Openstack] help - Fuel Community 11 - PXE
>
>  
>
> Hi Ken,
>
>  
>
> Fuel uses Cobbler which uses DNSMasq to provide DHCP and PXE boot,
> if the issue is hardware specific, you can try to search if
> anybody else had such problems with DNSMasq PXE boot and similar
> hardware.
>
>  
>
> Thanks,
>
>  
>
> On Wed, Oct 25, 2017 at 7:12 AM, Ken Houle
>  > wrote:
>
> All:
>
>  
>
> First off not sure I am in the right place so if I am not
> please be kind and point me in 

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

[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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[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] Compute Node shutdown how to prevent instance suspend

[Remo Mattei]

sorry forgot to paste the file location
/etc/sysconfig/libvirt-guests




On 11/2/17 11:21 AM, Remo Mattei wrote:
> If you are using CentOS  / Red Hat you can modify this file:
>
> libvirt-guests:#ON_SHUTDOWN=suspend
>
>
>
> # action taken on host shutdown
> # - suspend   all running guests are suspended using virsh managedsave
> # - shutdown  all running guests are asked to shutdown. Please be
> careful with
> # this settings since there is no way to distinguish between a
> # guest which is stuck or ignores shutdown requests and a guest
> # which just needs a long time to shutdown. When setting
> # ON_SHUTDOWN=shutdown, you must also set SHUTDOWN_TIMEOUT to a
> # value suitable for your guests.
> #ON_SHUTDOWN=suspend
>
>
>
> Hope this help.
>
> Remo
>
> On 11/2/17 11:08 AM, Chris Friesen wrote:
>> On 11/02/2017 01:03 AM, Chris wrote:
>>> Hello,
>>>
>>> When we shut down a compute node the instances running on it get
>>> suspended. This
>>> generates some difficulties with some applications like RabbitMQ dont
>>> like to be
>>> suspended. Is there a way to change this behavior so that the running
>>> instances
>>> gets killed or shutdown instead?
>> This may be done by the libvirtd shutdown scripts rather than anything
>> in nova.
>>
>> As others have said, you should probably either shut down the VMs in
>> an orderly fashion or else cold/live migrate the instances off the
>> compute node before rebooting it.
>>
>> Chris
>>
>> ___
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Compute Node shutdown how to prevent instance suspend

[Remo Mattei]

If you are using CentOS  / Red Hat you can modify this file:

libvirt-guests:#ON_SHUTDOWN=suspend



# action taken on host shutdown
# - suspend   all running guests are suspended using virsh managedsave
# - shutdown  all running guests are asked to shutdown. Please be
careful with
# this settings since there is no way to distinguish between a
# guest which is stuck or ignores shutdown requests and a guest
# which just needs a long time to shutdown. When setting
# ON_SHUTDOWN=shutdown, you must also set SHUTDOWN_TIMEOUT to a
# value suitable for your guests.
#ON_SHUTDOWN=suspend



Hope this help.

Remo

On 11/2/17 11:08 AM, Chris Friesen wrote:
> On 11/02/2017 01:03 AM, Chris wrote:
>> Hello,
>>
>> When we shut down a compute node the instances running on it get
>> suspended. This
>> generates some difficulties with some applications like RabbitMQ dont
>> like to be
>> suspended. Is there a way to change this behavior so that the running
>> instances
>> gets killed or shutdown instead?
>
> This may be done by the libvirtd shutdown scripts rather than anything
> in nova.
>
> As others have said, you should probably either shut down the VMs in
> an orderly fashion or else cold/live migrate the instances off the
> compute node before rebooting it.
>
> Chris
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] Live migration failures

[Mike Lowe]

I did not, it appears to be related to changing libvirt versions.  It’s no 
longer as tolerant of being sloppy with device addresses.  The last change for 
this section of code was a year ago if I read the git blame correctly.

> On Nov 2, 2017, at 2:11 PM, Chris Friesen  wrote:
> 
> On 11/02/2017 08:48 AM, Mike Lowe wrote:
>> After moving from CentOS 7.3 to 7.4, I’ve had trouble getting live migration 
>> to work when a volume is attached.  As it turns out when a live migration 
>> takes place the libvirt driver rewrites portions of the xml definition for 
>> the destination hypervisor and gets it wrong.  Here is an example.
> 
> Did you change versions of OpenStack as well?
> 
> Chris
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack] help - Fuel Community 11 - PXE

[Ken Houle]

Evgeniy L.

 

Thank you for the information. I have rebuilt the Fuel Community 11 server and 
left everything default with the exception of setting the PXE support to eth1. 
I am seeing the same issue.

The Silicon Mechanics server with a Supermicro system board as been configured 
in every possible boot configuration that I can think of; and I’m still seeing 
the “PXE-E7B” error.

 

 

I’m about to consign this server to another use.

 

 

 

Regards, 

 

Ken Houle
469-634-4171 :   
kho...@developingsolutions.com

 

From: Evgeniy L [mailto:e...@mirantis.com] 
Sent: Tuesday, October 31, 2017 9:58 AM
To: Ken Houle 
Cc: Openstack 
Subject: Re: [Openstack] help - Fuel Community 11 - PXE

 

I'm not sure if these options should be set, because they are required only if 
PXE server is on different host from DHCP server, which is not the case for 
Fuel.

 

On Thu, Oct 26, 2017 at 8:25 AM, Ken Houle  > wrote:

Evgeniy L:

 

Thank you for the information. I have a few, possible silly/noob, question. 
After your email I reviewed the tcpdump again and identified that the “dhcp 
offer” does not contain options 66 and 67.

You can see from the excerpt of a bootp capture the highlighted portions 
contain the IP address offered, next server, and boot file.

 

However, in the options section there is not an option 66, tftp server name, 
and option 67, bootfile name.

 

SO here is the question, taking cobbler into account which file should I be 
editing to attempt to add these options? Is the “/etc/cobbler/dhcp.template” 
file the correct file; thought “template” seems to  indicate that it is not?

If not, again silly/noob, which file should I be editing.

 

Any assistance would be appreciated.

 

 

Frame 4138: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits)

Ethernet II, Src: Dell_b9:6a:02 (d4:ae:52:b9:6a:02), Dst: Broadcast 
(ff:ff:ff:ff:ff:ff)

Internet Protocol Version 4, Src: 10.10.30.10, Dst: 255.255.255.255

User Datagram Protocol, Src Port: 67, Dst Port: 68

Bootstrap Protocol (Offer)

Message type: Boot Reply (2)

Hardware type: Ethernet (0x01)

Hardware address length: 6

Hops: 0

Transaction ID: 0x906a77f9

Seconds elapsed: 18

Bootp flags: 0x8000, Broadcast flag (Broadcast)

1...    = Broadcast flag: Broadcast

.000    = Reserved flags: 0x

Client IP address: 0.0.0.0

Your (client) IP address: 10.10.30.21

Next server IP address: 10.10.30.10

Relay agent IP address: 0.0.0.0

Client MAC address: SuperMic_6a:77:f9 (00:25:90:6a:77:f9)

Client hardware address padding: 

Server host name: boothost

Boot file name: pxelinux.0

Magic cookie: DHCP

Option: (53) DHCP Message Type (Offer)

Option: (54) DHCP Server Identifier

Option: (51) IP Address Lease Time

Option: (58) Renewal Time Value

Option: (59) Rebinding Time Value

Option: (1) Subnet Mask

Option: (28) Broadcast Address

Option: (15) Domain Name

Option: (6) Domain Name Server

Option: (3) Router

Option: (255) End

Padding: 00

 

Regards, 

 

Ken Houle
469-634-4171 :   
kho...@developingsolutions.com

 

From: Evgeniy L [mailto:e...@mirantis.com  ] 
Sent: Wednesday, October 25, 2017 11:45 AM
To: Ken Houle  >
Cc: Openstack  >
Subject: Re: [Openstack] help - Fuel Community 11 - PXE

 

Hi Ken,

 

Fuel uses Cobbler which uses DNSMasq to provide DHCP and PXE boot, if the issue 
is hardware specific, you can try to search if anybody else had such problems 
with DNSMasq PXE boot and similar hardware.

 

Thanks,

 

On Wed, Oct 25, 2017 at 7:12 AM, Ken Houle  > wrote:

All:

 

First off not sure I am in the right place so if I am not please be kind and 
point me in the correct direction. I am attempting to build an Openstack system 
with Fuel Community 11 with a mix servers from different manufacturers. I have 
successfully installed Fuel Community 11 on the master node and am attempting 
to add nodes to the Openstack environment. The “Dell” servers pxe boot fine, 
see the master node and can be added to the system. However, I have an older 
“Silicon Mechanics” server that will not pxe boot.

 

I have upgraded the AMI BIOS on the “Supermicro” system board to the latest 
release as well as the IPMI firmware. I have attempted to use both legacy and 
UEFI boot from the BIOS and I always see the same error. Please note that the 
Intel PXE release is 1.5.13.

 

“PXE-E7B: Missing MTFTP server IP address. This message 

Re: [Openstack-operators] Openstack release compatibility

[Chris Friesen]

On 10/31/2017 01:13 AM, haad wrote:

Hi,

We have an OSA installation with 10-12 compute nodes running Mitaka on Ubuntu
16.04. As initially we have not prepared any long term update strategy we would
like to create one now. Plan would be to upgrade it to new OSA
release(Ocata/Pike/Queens) in near future.

Our original plan was to update management/networking/backend at once by using
rolling updates to newer release and then upgrade compute nodes one by one to
new release.. I think that [2] provides a general upgrade manual. Is there any
document describing how are different OSA releases compatible ? Is there any
policy in place about backward compatibility ?


As a general rule, OpenStack only supports an online upgrade of one version at a 
time.  That is, controller nodes running version N can talk to compute nodes 
running version N-1.


If you can tolerate downtime of the API layer, there has been some discussion 
around "skip-level" upgrades.


Chris


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack] Compute Node shutdown how to prevent instance suspend

[Chris Friesen]

On 11/02/2017 01:03 AM, Chris wrote:

Hello,

When we shut down a compute node the instances running on it get suspended. This
generates some difficulties with some applications like RabbitMQ dont like to be
suspended. Is there a way to change this behavior so that the running instances
gets killed or shutdown instead?


This may be done by the libvirtd shutdown scripts rather than anything in nova.

As others have said, you should probably either shut down the VMs in an orderly 
fashion or else cold/live migrate the instances off the compute node before 
rebooting it.


Chris

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] Live migration failures

[Chris Friesen]

On 11/02/2017 08:48 AM, Mike Lowe wrote:

After moving from CentOS 7.3 to 7.4, I’ve had trouble getting live migration to 
work when a volume is attached.  As it turns out when a live migration takes 
place the libvirt driver rewrites portions of the xml definition for the 
destination hypervisor and gets it wrong.  Here is an example.


Did you change versions of OpenStack as well?

Chris


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Clear Linux guest issues (maybe UEFI boot issues?)

[Jonathan Proulx]

Hi All,

This is low priority poking but I have a sort of puzzling situation.

Wanted to play with Clear linux (which is uefi only) to see what it
was about  so grabbed some images and obviously tried to throw them on
my OpenStack cloud.

After learning how to enable EUFI booting (hw_firmware_type='uefi' in
image metadata and ovfm package on hypervisors) it still just hangs
trying to boot, no serial out, uninialized VNC console, no ping.

Running manually under KVM on my workstation (same Ubuntu 16.04 as
hypervisors) I can get it to go.

Nova generated qemu command: https://pastebin.com/VarvB6Cs
Simpler manual command (works): https://pastebin.com/BfJpXYRm

any clues?

thanks,
-Jon
-- 

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [puppet][qa][ubuntu][neutron] Xenial Neutron Timeouts

[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,
>   

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

[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

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

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

[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.

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.


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.




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.


¹
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




__
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] Devstack with OpenStack's local repo

[Sean Dague]

On 11/02/2017 04:32 AM, Ramu, MohanX wrote:

Hi All,

Whenever I run devstack set up scripts it always download the latest 
minor version of OpenStack.


I want to control that by connecting my local OpenStack repo is it 
possible?


Please let me know.

Thanks & regards,

Mohan Ramu


It is, we document it a bit here (though patches are welcome if you have 
ideas on making it more clear) - 
https://docs.openstack.org/devstack/latest/development.html#testing-a-patch-series


-Sean

--
Sean Dague
http://dague.net

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] Live migration failures

[Mike Lowe]

Look at comment #2, it’s me.

> On Nov 2, 2017, at 11:34 AM, Sergio Cuellar Valdes 
>  wrote:
> 
> Hi Mike,
> 
> Which version of OpenStack are you using ? Do the normal migrations work ? 
> 
> I found a bug that looks like your problem [1]
> 
> [1] https://bugs.launchpad.net/nova/+bug/1715569 
> 
> 
> Cheers,
> Sergio
> 
> On 2 November 2017 at 08:48, Mike Lowe  > wrote:
> After moving from CentOS 7.3 to 7.4, I’ve had trouble getting live migration 
> to work when a volume is attached.  As it turns out when a live migration 
> takes place the libvirt driver rewrites portions of the xml definition for 
> the destination hypervisor and gets it wrong.  Here is an example.
> 
> It turns this:
> 
> disk device="disk" type="network">
> 
> 
>  uuid="1a790a26-dd49-4825-8d16-3dd627cf05a9"/>
> 
>  name="cinder-volumes/volume-de400476-b68a-45a2-b04f-739313f42bef" 
> protocol="rbd">
> 
> 
> 
> 
> 
> de400476-b68a-45a2-b04f-739313f42bef
> 
> 
> 
> Into this:
> 
> 
> 
> 
>  uuid="1a790a26-dd49-4825-8d16-3dd627cf05a9"/>
> 
>  name="cinder-volumes/volume-de400476-b68a-45a2-b04f-739313f42bef" 
> protocol="rbd">
> 
> 
> 
> 
> 
> de400476-b68a-45a2-b04f-739313f42bef
> 
> 
> 
> Note the address change, libvirt will attempt to put this undefined disk at 
> 0:0:0 which conflicts with the root disk and causes the migration to fail.  
> While this may be a libvirt bug I can’t imagine anything good would come from 
> changing the scsi address of your disks mid flight so steps should be taken 
> in nova if rewriting the definition to preserve the address.
> 
> Here is my question, when exactly would you want to change the definition of 
> an attached volume?
> 
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
> 
> 
> 
> 
> -- 
>  Sergio Cuéllar │DevOps Engineer
>  KIO NETWORKS
>  Mexico City Phone (52) 55 8503 2600 ext. 4335
>  Mobile: 5544844298
>  www.kionetworks.com 
> 
> 
> ***
> “Este mensaje es confidencial.  Si usted no es el destinatario de este 
> mensaje, le suplicamos se lo notifique al remitente mediante un correo 
> electrónico y que borre el presente mensaje y sus anexos de su computadora 
> sin retener una copia de los mismos. No debe copiar este mensaje o usarlo 
> para cualquier propósito ni divulgar su contenido. KIO Networks se reserva el 
> derecho de monitorear todas las comunicaciones de correo electrónico 
> (relacionadas o no con KIO Networks) que se transmitan a través de su 
> sistema. Muchas gracias.
> This email is confidential and may also be privileged.  If you are not the 
> intended recipient please immediately advise the sender by reply e-mail and 
> delete this message and its attachments from your computer without retaining 
> a copy. You should not copy it or use it for any purpose nor disclose its 
> contents to any other person. KIO Networks reserves the right to monitor all 
> email communications (whether related to the business of KIO Networks or not) 
> through its networks. Thank you.”
> 
> ***___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

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

[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

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

[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-operators] Live migration failures

[Sergio Cuellar Valdes]

Hi Mike,

Which version of OpenStack are you using ? Do the normal migrations work ?

I found a bug that looks like your problem [1]

[1] https://bugs.launchpad.net/nova/+bug/1715569

Cheers,
Sergio

On 2 November 2017 at 08:48, Mike Lowe  wrote:

> After moving from CentOS 7.3 to 7.4, I’ve had trouble getting live
> migration to work when a volume is attached.  As it turns out when a live
> migration takes place the libvirt driver rewrites portions of the xml
> definition for the destination hypervisor and gets it wrong.  Here is an
> example.
>
> It turns this:
>
> disk device="disk" type="network">
> 
> 
> 
> 
>  name="cinder-volumes/volume-de400476-b68a-45a2-b04f-739313f42bef"
> protocol="rbd">
> 
> 
> 
> 
> 
> de400476-b68a-45a2-b04f-739313f42bef
> 
> 
>
> Into this:
>
> 
> 
> 
> 
> 
>  name="cinder-volumes/volume-de400476-b68a-45a2-b04f-739313f42bef"
> protocol="rbd">
> 
> 
> 
> 
> 
> de400476-b68a-45a2-b04f-739313f42bef
> 
> 
>
> Note the address change, libvirt will attempt to put this undefined disk
> at 0:0:0 which conflicts with the root disk and causes the migration to
> fail.  While this may be a libvirt bug I can’t imagine anything good would
> come from changing the scsi address of your disks mid flight so steps
> should be taken in nova if rewriting the definition to preserve the address.
>
> Here is my question, when exactly would you want to change the definition
> of an attached volume?
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
* Sergio Cuéllar │DevOps Engineer*
 KIO NETWORKS
 Mexico City Phone (52) 55 8503 2600 ext. 4335
 Mobile: 5544844298
 www.kionetworks.com

-- 


*

*“Este mensaje es confidencial.  Si usted no es el destinatario de este 
mensaje, le suplicamos se lo notifique al remitente mediante un correo 
electrónico y que borre el presente mensaje y sus anexos de su computadora 
sin retener una copia de los mismos. No debe copiar este mensaje o usarlo 
para cualquier propósito ni divulgar su contenido. KIO Networks se reserva 
el derecho de monitorear todas las comunicaciones de correo electrónico 
(relacionadas o no con KIO Networks) que se transmitan a través de su 
sistema. **Muchas gracias.*

*This email is confidential and may also be privileged.  If you are not the 
intended recipient please immediately advise the sender by reply e-mail and 
delete this message and its attachments from your computer without 
retaining a copy. You should not copy it or use it for any purpose nor 
disclose its contents to any other person. KIO Networks reserves the right 
to monitor all email communications (whether related to the business of KIO 
Networks or not) through its networks. Thank you.”*
*
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[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-operators] Live migration failures

[Mike Lowe]

After moving from CentOS 7.3 to 7.4, I’ve had trouble getting live migration to 
work when a volume is attached.  As it turns out when a live migration takes 
place the libvirt driver rewrites portions of the xml definition for the 
destination hypervisor and gets it wrong.  Here is an example.

It turns this:

disk device="disk" type="network">










de400476-b68a-45a2-b04f-739313f42bef



Into this:












de400476-b68a-45a2-b04f-739313f42bef



Note the address change, libvirt will attempt to put this undefined disk at 
0:0:0 which conflicts with the root disk and causes the migration to fail.  
While this may be a libvirt bug I can’t imagine anything good would come from 
changing the scsi address of your disks mid flight so steps should be taken in 
nova if rewriting the definition to preserve the address.

Here is my question, when exactly would you want to change the definition of an 
attached volume?



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[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: 

Re: [openstack-dev] Logging format: let's discuss a bit about default format, format configuration and so on

[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
>> 

Re: [openstack-dev] [api][nova] Why we return a redirect (302) when request to 'GET /v2.1'?

[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] Devstack with OpenStack's local repo

[Dean Troyer]

On Thu, Nov 2, 2017 at 6:32 AM, Ramu, MohanX  wrote:
> I want to control that by connecting my local OpenStack repo is it possible?

In stackrc you will find a number of environment variable pairs of the
form XXX_REPO and XXX_BRANCH.  Those can be used to get very specific
about the repo and branch to check out for each project and many
sub-projects and libraries.  Also, the GIT_BASE variable may be
sufficient to point at your own collection of repos.

dt

-- 

Dean Troyer
dtro...@gmail.com

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] Devstack with OpenStack's local repo

[Ramu, MohanX]

Hi All,

Whenever I run devstack set up scripts it always download the latest minor 
version of OpenStack.

I want to control that by connecting my local OpenStack repo is it possible?

Please let me know.

Thanks & regards,

Mohan Ramu

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [octavia] how to recreate amphora instances

[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] [os-vif] [nova] Changes to os-vif cores

[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

Re: [Openstack] Fuel-9.2 - Broken deployment on one node stops all other nodes too

[Raja T Nair]

Hi Evgeniy,

apt-cache policy fuel-ha-utils says that the package is not to be found.

Now I re-installed fuel on another node(as there was a lot of issues faced
on the old one), and created local repo using these commands:

fuel-mirror create -P ubuntu -G ubuntu
fuel-mirror apply -G ubuntu -I /usr/share/fuel-mirror/ubuntu.yaml --replace
--default
fuel-mirror apply -G mos -I /usr/share/fuel-mirror/ubuntu.yaml --default

my /usr/share/fuel-mirror directory looks like this:

[root@fuel92 nginx]# ll /usr/share/fuel-mirror/
total 12
-rwxr-xr-x. 1 root root 1344 May 24 07:47 centos.yaml
-rwxr-xr-x. 1 root root 4288 May 24 07:47 ubuntu.yaml
[root@fuel92 nginx]#

While doing the ``connectivity check'', it failed with following error
lines:
Verification failed.
Repo availability verification failed on following nodes Fuel master node,
Untitled (0b:34), Untitled (71:28), Untitled (2b:52), Untitled (ae:40),
Untitled (a8:73).
Following repos are not available -
http://172.22.66.11:8080/mirrors/mos-repos/ubuntu/9.0,
http://172.22.66.11:8080/mirrors/mos-repos/ubuntu/9.2.

nginx logs say this:
2017/11/02 10:22:47 [error] 1188#1188: *12256 open()
"/var/www/nailgun/mirrors/mos-repos/ubuntu/9.0" failed (2: No such file or
directory), client
: 172.22.66.24, server: localhost, request: "GET
/mirrors/mos-repos/ubuntu/9.0 HTTP/1.1", host: "172.22.66.11:8080"

And the directory mos-repos actually does not exist:
[root@fuel92 nginx]# ls /var/www/nailgun/mirrors/
ubuntu

I suppose I need to build the mos-repos repo also locally. If yes, how do I
do this? I thought it would have built it with the above
"fuel-mirror create -P ubuntu -G ubuntu" command.

Attaching screenshot of settings page, which shows currently configured
repos.

Please help me with this one.

Regards,
Raja.



On 31 October 2017 at 19:29, Evgeniy L  wrote:

> Run "apt-cache policy fuel-ha-utils" and see from which repository does it
> come from, if your mirrors configured correctly, the package should come
> from your mirror.
> It also shows what command it failed to run, "/usr/bin/apt-get -q -y -o
> DPkg::Options::=--force-confold -o APT::Get::AllowUnauthenticated=1
> install fuel-ha-utils" you can run it manually on the node and see what the
> error is.
>
> Thanks,
>
> On Tue, Oct 31, 2017 at 12:27 AM, Raja T Nair  wrote:
>
>> Hi,
>>
>> I built the repos locally, using the instructions in this page:
>> https://docs.openstack.org/fuel-docs/latest/userdocs/fuel-
>> install-guide/local-repo.html
>>
>> Now, while trying to deploy to 2 newly added nodes, it fails with this
>> error:
>>
>> 2017-10-31 06:45:11ERR(/Stage[main]/Osnailyfacter::Fuel_pkgs::Fuel_
>> pkgs/Package[fuel-ha-utils]/ensure) E: Unable to locate package
>> fuel-ha-utils
>> 2017-10-31 06:45:11ERR(/Stage[main]/Osnailyfacter::Fuel_pkgs::Fuel_
>> pkgs/Package[fuel-ha-utils]/ensure) Reading state information...
>> 2017-10-31 06:45:11ERR(/Stage[main]/Osnailyfacter::Fuel_pkgs::Fuel_
>> pkgs/Package[fuel-ha-utils]/ensure) Building dependency tree...
>> 2017-10-31 06:45:11ERR(/Stage[main]/Osnailyfacter::Fuel_pkgs::Fuel_
>> pkgs/Package[fuel-ha-utils]/ensure) change from purged to present
>> failed: Execution of '/usr/bin/apt-get -q -y -o
>> DPkg::Options::=--force-confold -o APT::Get::AllowUnauthenticated=1
>> install fuel-ha-utils' returned 100: Reading package lists...
>> 2017-10-31 06:45:11ERR/usr/bin/puppet:8:in `'2017-10-31
>> 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:92:in
>> `execute'
>> 2017-10-31 
>> 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:146:in
>> `run'2017-10-31 06:45:11ERR/usr/lib/ruby/vendo
>> r_ruby/puppet/application.rb:381:in `run'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/util.rb:496:in
>> `exit_on_fail'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/application.rb:381:in
>> `block in run'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/application.rb:507:in
>> `plugin_hook'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/application.rb:381:in
>> `block (2 levels) in run'
>> 2017-10-31 
>> 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/application/apply.rb:159:in
>> `run_command'
>> 2017-10-31 
>> 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/application/apply.rb:198:in
>> `main'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet.rb:246:in
>> `override'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/context.rb:64:in
>> `override'
>> 2017-10-31 
>> 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/application/apply.rb:236:in
>> `block in main'
>> 2017-10-31 
>> 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/application/apply.rb:302:in
>> `apply_catalog'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/configurer.rb:133:in
>> `run'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet.rb:246:in
>> `override'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/context.rb:64:in
>> `override'
>> 2017-10-31 

[Openstack-operators] [QA] Sydney Summit

[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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [QA] Sydney Summit

[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

[Openstack-operators] [openstack-ansible] Sydney summit -- We'll be there!

[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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [openstack-ansible] Sydney summit -- We'll be there!

[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

Re: [Openstack-operators] Openstack release compatibility

[Jean-Philippe Evrard]

On 31 October 2017 at 07:13, haad  wrote:
> Hi,
>
> We have an OSA installation with 10-12 compute nodes running Mitaka on
> Ubuntu 16.04. As initially we have not prepared any long term update
> strategy we would like to create one now. Plan would be to upgrade it to new
> OSA release(Ocata/Pike/Queens) in near future.
>
> Our original plan was to update management/networking/backend at once by
> using rolling updates to newer release and then upgrade compute nodes one by
> one to new release.. I think that [2] provides a general upgrade manual. Is
> there any document describing how are different OSA releases compatible ? Is
> there any policy in place about backward compatibility ?
>
>
>
> [1] https://etherpad.openstack.org/p/osa-newton-xenial-upgrade
> [2] https://wiki.openstack.org/wiki/Upgrade-with-minimal-downtime
>
> --
>
>
> Regards.
>
> Adam
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

Hello,

I'd advise you to follow the standard OpenStack-Ansible path, which is
upgrading from Mitaka to Newton, then do your ubuntu upgrade to
xenial.
From Newton onwards, we have code taking care of the rolling part of
the upgrade, which should help you getting to Pike, after a series of
upgrades (N->O->P) under ubuntu 16.04.

Best regards,
Jean-Philippe Evrard (evrardjp)

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack] Compute Node shutdown how to prevent instance suspend

[Tomáš Vondra]

Hi!

When I need to reboot a compute node (because of some driver lock-up or such 
problems), I first stop nova-compute so that it does not report the shutoff 
state of VMs to the database and resume_guests_state_on_host_boot=true does 
actually start them. Then I press the power switch on the VMs using virsh 
shutdown, one by one, and only after that I reboot the node. This is a script I 
scrounged somewhere and modified so that it does not take too much time:

Tomas

 

root@cmp03:~# cat vm-shutdown

#!/bin/bash

# file: /usr/local/sbin/vm-shutdown

# Description: shutdown active virtual machines

debug=1

#fake=1

 

# Get list of active virtual machines

vmList="`virsh list | (

while read vmID vmName vmStatus

do

  if [ -n "$vmName" -a "$vmName" != "Name" -a "$vmName" != "Domain-0" ]

  then

[ -z "$vmList" ] && vmList="$vmName" || vmList="$vmList $vmName"

  fi

done

echo $vmList )`"

 

# check there are some active VM's

if [ -n "$vmList" ]; then

  # Shutdown VM's with verification

  for vmName in $vmList

  do

# send initial request

[ -n "$debug" ] && echo -n "Attempting to shutdown $vmName "

[ -z "$fake" ] && virsh shutdown $vmName

# wait a limited time for the VM to be not running

count=30

while $( virsh list | grep $vmName >/dev/null ) && [ $count -gt 0 ]

do

  sleep 1

  let count=count-1

  [ -n "$debug" ] && echo -n "."

done

# report current status

( virsh list | grep $vmName >/dev/null ) && echo " failed!" || echo "down."

# if still running, destroy it

if ( virsh list | grep $vmName >/dev/null )

then

  [ -n "$debug" ] && echo -n "Attempting to destroy $vmName "

  [ -z "$fake" ] && virsh destroy $vmName

  # wait a limited time for the VM to be not running

  count=30

  while $( virsh list | grep $vmName >/dev/null ) && [ $count -gt 0 ]

  do

sleep 1

let count=count-1

[ -n "$debug" ] && echo -n "."

  done

  # report current status

  ( virsh list | grep $vmName >/dev/null ) && echo " failed!" || echo 
"down."

fi

  done

 

From: Tzach Shefi [mailto:tsh...@redhat.com] 
Sent: Thursday, November 02, 2017 9:55 AM
To: Chris
Cc: openstack@lists.openstack.org
Subject: Re: [Openstack] Compute Node shutdown how to prevent instance suspend

 

Hi, 

 

A better Q would be why do you shutdown a compute node to begin with?

I mean if you need you should do so in an orderly fashion basically excavate 
instances

or shut instances down manually, put the compute node in maintenance mode. 

On rebooting compute node remove it from maintenance mode, turn on instances or 
migrate them back to this compute node should you need. 

Od delete them if you wish. 

 

There is this nova option:

resume_guests_state_on_host_boot=true

 

But it doesn't delete or shutdown instances but rather turns them on 
automatically once compute host resumes. 

which might also work for you, probably not just mentioning it any way.  

 

I don't know of an option to stop/delete instance on compute node shutdown. 

 

Another option check maybe you could shelve suspended instance and then later 
delete them. 

 

Shelving stops the instance and takes a snapshot of it. Then depending on the 
value of the shelved_offload_time config option, the instance is deleted from 
the hypervisor (0), never deleted (-1), or deleted after some period of time (> 
0). Note that it's just destroying the backing instance on the hypervisor, the 
actual instance in the nova database is not deleted. Then you can later 
unshelve the instance:

 

 

This might help, but do not if you mess with kvm without updating Nova you 
might be left haning else where :)

https://ask.fedoraproject.org/en/question/8796/make-libvirt-to-shutdown-my-guests-not-suspend/

 

 

 

 

On Thu, Nov 2, 2017 at 9:03 AM, Chris  wrote:

Hello,

When we shut down a compute node the instances running on it get suspended. 
This generates some difficulties with some applications like RabbitMQ dont like 
to be suspended. Is there a way to change this behavior so that the running 
instances gets killed or shutdown instead?

Thanks in advance.

Cheers,
Chris

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack





 

-- 

Tzach Shefi

Senior Quality Engineer, RHCSA

  Red Hat 



  tsh...@redaht.comM:   
+972-54-4701080 IM: tshefi


  Obrázek byl odebrán odesílatelem.

 

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [tripleo][containers] Please always do mirrored hiera changes for (non)containerized cases

[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] [Blazar] No meeting next week

[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

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

[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=37=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
    >> 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
 

Re: [openstack-dev] [Openstack][Ceilometer] interface statistics for SRIO-V based VM

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

[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,

C.


¹
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] Compute Node shutdown how to prevent instance suspend

[Tzach Shefi]

Hi,

A better Q would be why do you shutdown a compute node to begin with?
I mean if you need you should do so in an orderly fashion basically
excavate instances
or shut instances down manually, put the compute node in maintenance mode.
On rebooting compute node remove it from maintenance mode, turn on
instances or migrate them back to this compute node should you need.
Od delete them if you wish.

There is this nova option:
resume_guests_state_on_host_boot=true

But it doesn't delete or shutdown instances but rather turns them on
automatically once compute host resumes.
which might also work for you, probably not just mentioning it any way.

I don't know of an option to stop/delete instance on compute node shutdown.

Another option check maybe you could shelve suspended instance and then
later delete them.

Shelving stops the instance and takes a snapshot of it. Then depending on
the value of the shelved_offload_time config option, the instance is
deleted from the hypervisor (0), never deleted (-1), or deleted after some
period of time (> 0). Note that it's just destroying the backing instance
on the hypervisor, the actual instance in the nova database is not deleted.
Then you can later unshelve the instance:


This might help, but do not if you mess with kvm without updating Nova you
might be left haning else where :)
https://ask.fedoraproject.org/en/question/8796/make-libvirt-to-shutdown-my-guests-not-suspend/




On Thu, Nov 2, 2017 at 9:03 AM, Chris  wrote:

> Hello,
>
> When we shut down a compute node the instances running on it get
> suspended. This generates some difficulties with some applications like
> RabbitMQ dont like to be suspended. Is there a way to change this behavior
> so that the running instances gets killed or shutdown instead?
>
> Thanks in advance.
>
> Cheers,
> Chris
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
>



-- 

Tzach Shefi

Senior Quality Engineer, RHCSA

Red Hat



tsh...@redaht.comM: +972-54-4701080 IM: tshefi

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [TripleO][containers]ironic-inspector

[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

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] [Magnum] Docker Swarm Mode Support

[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] [nova][neutron] How do you use the instance IP filter?

[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

[Openstack] Compute Node shutdown how to prevent instance suspend

[Chris]

Hello,

When we shut down a compute node the instances running on it get 
suspended. This generates some difficulties with some applications like 
RabbitMQ dont like to be suspended. Is there a way to change this 
behavior so that the running instances gets killed or shutdown instead?


Thanks in advance.

Cheers,
Chris

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack-operators] [openstack-operators][openstack-dev][heat][all] Sydney for all Heat Users, Operators, and Developers

[Rico Lin]

Hi all

Next week is our big week! Hope to see you all there, here are some heat
sessions/forums for you in Sydney Summit.

For any users and operators who use heat directly or indirectly(like people
who use Magnum/Sahara/Tacker) are welcome to join us for ops and users
feedback forum, we really appreciated for any kind of help and feedbacks.
So heat and other projects that relative to heat can know any issues or
required for improvement exists.

For anyone who would like to see if you could help on contributing in any
way, or you're looking for better knowledge of developing heat, please join
us in our Onboarding session.

And last but not least, please join our project update session for some key
information about what we done for pike and what's plan for queens.

All detail information:

Heat - Project Onboarding
Mon 6, 11:35am - 12:15pm Sydney Convention and Exhibition Centre - Level 4
- C4.7 

Heat - Project Update
Tue 7, 5:00pm - 5:20pm Sydney Convention and Exhibition Centre - Level 3
Convention Center - C3.2


Heat ops and users feedback
Wed 8, 4:30pm - 5:10pm Sydney Convention and Exhibition Centre - Level 4 -
C4.10 


There also a lot of Orchestration relative sessions, so feel free to pick
your favorites.
-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [openstack-operators][heat][all] Sydney for all Heat Users, Operators, and Developers

[Rico Lin]

Hi all

Next week is our big week! Hope to see you all there, here are some heat
sessions/forums for you in Sydney Summit.

For any users and operators who use heat directly or indirectly(like people
who use Magnum/Sahara/Tacker) are welcome to join us for ops and users
feedback forum, we really appreciated for any kind of help and feedbacks.
So heat and other projects that relative to heat can know any issues or
required for improvement exists.

For anyone who would like to see if you could help on contributing in any
way, or you're looking for better knowledge of developing heat, please join
us in our Onboarding session.

And last but not least, please join our project update session for some key
information about what we done for pike and what's plan for queens.

All detail information:

Heat - Project Onboarding
Mon 6, 11:35am - 12:15pm Sydney Convention and Exhibition Centre - Level 4
- C4.7 

Heat - Project Update
Tue 7, 5:00pm - 5:20pm Sydney Convention and Exhibition Centre - Level 3
Convention Center - C3.2


Heat ops and users feedback
Wed 8, 4:30pm - 5:10pm Sydney Convention and Exhibition Centre - Level 4 -
C4.10 


There also a lot of Orchestration relative sessions, so feel free to pick
your favorites.
-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
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] [api][nova] Why we return a redirect (302) when request to 'GET /v2.1'?

[Alex Xu]

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?

Thanks
Alex
__
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