[Openstack-operators] sporadic missing vxlan-tunnel-port assignment

[Fabian Zimmermann]

Hi,

we currently see sporadic communication problems.

After some research we found out, that this is caused by missing 
tunnel-port assignments in table 21 of openvswitch.


Today we had the issue again and here the logs of the add_fdb_entries 
calls at the affected system:


neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent.OVSNeutronAgent 
method add_fdb_entries called with arguments (object at 0x7f7264509810>,) {u'fdb_entries': 
{u'cd2baf3d-427c-41be-be56-7cbb8176067f': {u'segment_id': 96, u'ports': 
{u'10.78.23.12': [[u'00:00:00:00:00:00', u'0.0.0.0'], 
[u'fa:16:3e:d0:a0:77', u'192.168.0.2']]}, u'network_type': u'vxlan'}}}


neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent.OVSNeutronAgent 
method add_fdb_entries called with arguments (object at 0x7f7264509bd0>,) {u'fdb_entries': 
{u'cd2baf3d-427c-41be-be56-7cbb8176067f': {u'segment_id': 96, u'ports': 
{u'10.78.23.11': [[u'00:00:00:00:00:00', u'0.0.0.0'], 
[u'fa:16:3e:29:0c:d5', u'192.168.0.3']]}, u'network_type': u'vxlan'}}}


neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent.OVSNeutronAgent 
method add_fdb_entries called with arguments (object at 0x7f7264509d90>,) {u'fdb_entries': 
{u'cd2baf3d-427c-41be-be56-7cbb8176067f': {u'segment_id': 96, u'ports': 
{u'10.78.12.101': []}, u'network_type': u'vxlan'}}}


neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent.OVSNeutronAgent 
method add_fdb_entries called with arguments (object at 0x7f7264627190>,) {u'fdb_entries': 
{u'cd2baf3d-427c-41be-be56-7cbb8176067f': {u'segment_id': 96, u'ports': 
{u'10.79.20.102': [[u'00:00:00:00:00:00', u'0.0.0.0']]}, 
u'network_type': u'vxlan'}}}


The missing tunnel-port is the connection to 10.78.12.101, it looks like 
the empty array/dict may cause this issue.


Any hints how to further debug the situation?

What may cause an empty dict in add_fdb_entries?

Thanks a lot,


 Fabian Zimmermann

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

Re: [Openstack] [Pike] [Nova] Error : ERROR : MissingRequiredOptions: Auth plugin requires parameters which were not given: auth_url

[Eugen Block]

Hi,

could you provide more verbose output from nova-api.log (maybe other  
logs, too)?



Zitat von Guru Desai :


Oh my god !!! thank Navdeep..  With this, i m getting below error. Is this
known ?   this command was executed on compute node where

# openstack compute service list --service nova-compute
Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/
and attach the Nova API log if possible.
 (HTTP 500) (Request-ID:
req-3993191e-46ac-4f38-bda9-9b003e6aab1b)



On Tue, Mar 6, 2018 at 10:24 PM, Navdeep Uniyal <
navdeep.uni...@bristol.ac.uk> wrote:


Hi Guru,



It should be auth_url. Please see the highlighted error below.



Regards,

Navdeep



*From:* Guru Desai 
*Sent:* 06 March 2018 16:41
*To:* OpenStack Mailing List 
*Subject:* [Openstack] [Pike] [Nova] Error : ERROR :
MissingRequiredOptions: Auth plugin requires parameters which were not
given: auth_url



Hello,



I am setting up pike version and facing an issue with nova on controller.
I see below errors continouolsy in nova-api.log. But i have given the auth
parameters in the /etc/nova/nova.conf. I

am done installing keystone and glance, stuck here with nova. Modified the
nova.conf as per the install guide. Please suggest as to what could be the
issue..









[keystone_authtoken]





auth_uri = http://test_controller:5000

auth_uri = http://test_controller:35357

memcached_servers = test_controller:11211

auth_type = password

project_domain_name = default

user_domain_name = default

project_name = service

username = nova

password = NOVA_PASS







Log











--
Eugen Block voice   : +49-40-559 51 75
NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
Postfach 61 03 15
D-22423 Hamburg e-mail  : ebl...@nde.ag

Vorsitzende des Aufsichtsrates: Angelika Mozdzen
  Sitz und Registergericht: Hamburg, HRB 90934
  Vorstand: Jens-U. Mozdzen
   USt-IdNr. DE 814 013 983


___
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] Fwd: [Release-job-failures] Release of openstack/paunch failed

[Sean McGinnis]

This appears to have been a network related glitch.

'ReadTimeoutError("HTTPConnectionPool(host='mirror.gra1.ovh.openstack.org', 
port=80): Read timed out. (read timeout=60.0)",)’

I would guess it could just be rerun. When someone from infra gets a chance, 
would you be able to reenqueue this job?

Thanks,
Sean


> Begin forwarded message:
> 
> From: z...@openstack.org
> Subject: [Release-job-failures] Release of openstack/paunch failed
> Date: March 7, 2018 at 00:05:56 CST
> To: release-job-failu...@lists.openstack.org
> Reply-To: openstack-dev@lists.openstack.org
> 
> Build failed.
> 
> - release-openstack-python 
> http://logs.openstack.org/34/34e767fbcc4dd488c94023b5ee682dd2369db7bd/release/release-openstack-python/5edd302/
>  : FAILURE in 16m 43s
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED
> 
> ___
> Release-job-failures mailing list
> release-job-failu...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

__
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] [Release-job-failures] Release of openstack/paunch failed

[Tony Breeds]

On Wed, Mar 07, 2018 at 06:05:56AM +, z...@openstack.org wrote:
> Build failed.
> 
> - release-openstack-python 
> http://logs.openstack.org/34/34e767fbcc4dd488c94023b5ee682dd2369db7bd/release/release-openstack-python/5edd302/
>  : FAILURE in 16m 43s
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED

Looks like this was a generic timeout:

http://logs.openstack.org/34/34e767fbcc4dd488c94023b5ee682dd2369db7bd/release/release-openstack-python/5edd302/job-output.txt.gz#_2018-03-07_06_05_03_388522

Can we re-run these jobs, if they haven't been done already.

Yours Tony.


signature.asc
Description: PGP 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] [mistral] Retiring the Mistral Wiki pages

[Renat Akhmerov]

IMO, these sections should be moved to the official docs in some form:

• FAQ - https://wiki.openstack.org/w/index.php?title=Mistral=99745#FAQ
• Actions design - 
https://wiki.openstack.org/wiki/Mistral/Blueprints/ActionsDesign
• Description of use cases:

• https://wiki.openstack.org/wiki/Mistral/Long_Running_Business_Process
• https://wiki.openstack.org/wiki/Mistral/Cloud_Cron_details



All of these pages are outdated to some degree (terms etc.) and need to be 
refreshed but I think they contain a lot of interesting info that could help 
people understand Mistral better.

There's also a page (very much outdated!) containing info about the Mistral 
team: https://wiki.openstack.org/wiki/Mistral/Team

Of course, it can't be reused but I think it would be nice to have something 
link in the official doc, may be pointing directly to a stackalytics relevant 
info.


Thanks

Renat Akhmerov
@Nokia

On 7 Mar 2018, 12:33 +0700, Renat Akhmerov , wrote:
> Thanks Dougal, I’ll also look at it to see what’s still relevant.
>
>
> Renat Akhmerov
> @Nokia
>
> On 6 Mar 2018, 21:24 +0700, Dougal Matthews , wrote:
> > Hey folks,
> >
> > Mistral has several Wiki pages that rank highly in Google searches. 
> > However, most of them have not been updated in months (or years in many 
> > cases). I am therefore starting to remove these and direct people to the 
> > Mistral documentation. Where possible I will link them to the relevant 
> > documentation pages.
> >
> > I have taken the plunge and removed the main wiki [0] page. The old content 
> > is still accessible [1], just click on "Page" at the top left and then go 
> > to history.
> >
> > Over the next week or so I am going to read through the old wiki pages and 
> > see if there is any information that is still relevant and move it to the 
> > Mistral documentation. If you are aware of anything that is in the wiki, 
> > but not in the docs (and should be) then please submit a patch or open a 
> > bug.
> >
> > After we consolidate all of the information into the Mistral docs I hope to 
> > coordinate an effort to improve the documentation.
> >
> > Cheers,
> > Dougal
> >
> > [0]: https://wiki.openstack.org/wiki/Mistral
> > [1]: https://wiki.openstack.org/w/index.php?title=Mistral=152120
> > __
> > 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] [mistral] Retiring the Mistral Wiki pages

[Renat Akhmerov]

Thanks Dougal, I’ll also look at it to see what’s still relevant.


Renat Akhmerov
@Nokia

On 6 Mar 2018, 21:24 +0700, Dougal Matthews , wrote:
> Hey folks,
>
> Mistral has several Wiki pages that rank highly in Google searches. However, 
> most of them have not been updated in months (or years in many cases). I am 
> therefore starting to remove these and direct people to the Mistral 
> documentation. Where possible I will link them to the relevant documentation 
> pages.
>
> I have taken the plunge and removed the main wiki [0] page. The old content 
> is still accessible [1], just click on "Page" at the top left and then go to 
> history.
>
> Over the next week or so I am going to read through the old wiki pages and 
> see if there is any information that is still relevant and move it to the 
> Mistral documentation. If you are aware of anything that is in the wiki, but 
> not in the docs (and should be) then please submit a patch or open a bug.
>
> After we consolidate all of the information into the Mistral docs I hope to 
> coordinate an effort to improve the documentation.
>
> Cheers,
> Dougal
>
> [0]: https://wiki.openstack.org/wiki/Mistral
> [1]: https://wiki.openstack.org/w/index.php?title=Mistral=152120
> __
> 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-operators] Stable Branch EOL and "Extended Maintenance" Resolution

[Chris Morgan]

Thanks for pointing this one out!

Chris

On Tue, Mar 6, 2018 at 9:53 PM, Melvin Hillsman 
wrote:

> Hi everyone,
>
> If you are interested in the items in the subject please be sure to take
> time to review and comment on the following patch -
> https://review.openstack.org/#/c/548916/
>
> --
> Kind regards,
>
> Melvin Hillsman
> mrhills...@gmail.com
> mobile: (832) 264-2646
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


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

Re: [openstack-dev] [Nova] [Cyborg] Tracking multiple functions

[Alex Xu]

2018-03-07 10:21 GMT+08:00 Alex Xu :

>
>
> 2018-03-06 22:45 GMT+08:00 Mooney, Sean K :
>
>>
>>
>>
>>
>> *From:* Matthew Booth [mailto:mbo...@redhat.com]
>> *Sent:* Saturday, March 3, 2018 4:15 PM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Subject:* Re: [openstack-dev] [Nova] [Cyborg] Tracking multiple
>> functions
>>
>>
>>
>> On 2 March 2018 at 14:31, Jay Pipes  wrote:
>>
>> On 03/02/2018 02:00 PM, Nadathur, Sundar wrote:
>>
>> Hello Nova team,
>>
>>  During the Cyborg discussion at Rocky PTG, we proposed a flow for
>> FPGAs wherein the request spec asks for a device type as a resource class,
>> and optionally a function (such as encryption) in the extra specs. This
>> does not seem to work well for the usage model that I’ll describe below.
>>
>> An FPGA device may implement more than one function. For example, it may
>> implement both compression and encryption. Say a cluster has 10 devices of
>> device type X, and each of them is programmed to offer 2 instances of
>> function A and 4 instances of function B. More specifically, the device may
>> implement 6 PCI functions, with 2 of them tied to function A, and the other
>> 4 tied to function B. So, we could have 6 separate instances accessing
>> functions on the same device.
>>
>>
>>
>> Does this imply that Cyborg can't reprogram the FPGA at all?
>>
>> *[Mooney, Sean K] cyborg is intended to support fixed function
>> acclerators also so it will not always be able to program the accelerator.
>> In this case where an fpga is preprogramed with a multi function bitstream
>> that is statically provisioned cyborge will not be able to reprogram the
>> slot if any of the fuctions from that slot are already allocated to an
>> instance. In this case it will have to treat it like a fixed function
>> device and simply allocate a unused  vf  of the corret type if available. *
>>
>>
>>
>>
>>
>> In the current flow, the device type X is modeled as a resource class, so
>> Placement will count how many of them are in use. A flavor for ‘RC
>> device-type-X + function A’ will consume one instance of the RC
>> device-type-X.  But this is not right because this precludes other
>> functions on the same device instance from getting used.
>>
>> One way to solve this is to declare functions A and B as resource classes
>> themselves and have the flavor request the function RC. Placement will then
>> correctly count the function instances. However, there is still a problem:
>> if the requested function A is not available, Placement will return an
>> empty list of RPs, but we need some way to reprogram some device to create
>> an instance of function A.
>>
>>
>> Clearly, nova is not going to be reprogramming devices with an instance
>> of a particular function.
>>
>> Cyborg might need to have a separate agent that listens to the nova
>> notifications queue and upon seeing an event that indicates a failed build
>> due to lack of resources, then Cyborg can try and reprogram a device and
>> then try rebuilding the original request.
>>
>>
>>
>> It was my understanding from that discussion that we intend to insert
>> Cyborg into the spawn workflow for device configuration in the same way
>> that we currently insert resources provided by Cinder and Neutron. So while
>> Nova won't be reprogramming a device, it will be calling out to Cyborg to
>> reprogram a device, and waiting while that happens.
>>
>> My understanding is (and I concede some areas are a little hazy):
>>
>> * The flavors says device type X with function Y
>>
>> * Placement tells us everywhere with device type X
>>
>> * A weigher orders these by devices which already have an available
>> function Y (where is this metadata stored?)
>>
>> * Nova schedules to host Z
>>
>> * Nova host Z asks cyborg for a local function Y and blocks
>>
>>   * Cyborg hopefully returns function Y which is already available
>>
>>   * If not, Cyborg reprograms a function Y, then returns it
>>
>> Can anybody correct me/fill in the gaps?
>>
>> *[Mooney, Sean K] that correlates closely to my recollection also. As for
>> the metadata I think the weigher may need to call to cyborg to retrieve
>> this as it will not be available in the host state object.*
>>
> Is it the nova scheduler weigher or we want to support weigh on placement?
> Function is traits as I think, so can we have preferred_traits? I remember
> we talk about that parameter in the past, but we don't have good use-case
> at that time. This is good use-case.
>

If we call the Cyborg from the nova scheduler weigher, that will slow down
the scheduling a lot also.

>
>
>> Matt
>>
>>
>>
>> --
>>
>> Matthew Booth
>>
>> Red Hat OpenStack Engineer, Compute DFG
>>
>>
>>
>> Phone: +442070094448 <+44%2020%207009%204448> (UK)
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for 

Re: [openstack-dev] [Nova] [Cyborg] Tracking multiple functions

[Alex Xu]

2018-03-06 22:45 GMT+08:00 Mooney, Sean K :

>
>
>
>
> *From:* Matthew Booth [mailto:mbo...@redhat.com]
> *Sent:* Saturday, March 3, 2018 4:15 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Nova] [Cyborg] Tracking multiple functions
>
>
>
> On 2 March 2018 at 14:31, Jay Pipes  wrote:
>
> On 03/02/2018 02:00 PM, Nadathur, Sundar wrote:
>
> Hello Nova team,
>
>  During the Cyborg discussion at Rocky PTG, we proposed a flow for
> FPGAs wherein the request spec asks for a device type as a resource class,
> and optionally a function (such as encryption) in the extra specs. This
> does not seem to work well for the usage model that I’ll describe below.
>
> An FPGA device may implement more than one function. For example, it may
> implement both compression and encryption. Say a cluster has 10 devices of
> device type X, and each of them is programmed to offer 2 instances of
> function A and 4 instances of function B. More specifically, the device may
> implement 6 PCI functions, with 2 of them tied to function A, and the other
> 4 tied to function B. So, we could have 6 separate instances accessing
> functions on the same device.
>
>
>
> Does this imply that Cyborg can't reprogram the FPGA at all?
>
> *[Mooney, Sean K] cyborg is intended to support fixed function acclerators
> also so it will not always be able to program the accelerator. In this case
> where an fpga is preprogramed with a multi function bitstream that is
> statically provisioned cyborge will not be able to reprogram the slot if
> any of the fuctions from that slot are already allocated to an instance. In
> this case it will have to treat it like a fixed function device and simply
> allocate a unused  vf  of the corret type if available. *
>
>
>
>
>
> In the current flow, the device type X is modeled as a resource class, so
> Placement will count how many of them are in use. A flavor for ‘RC
> device-type-X + function A’ will consume one instance of the RC
> device-type-X.  But this is not right because this precludes other
> functions on the same device instance from getting used.
>
> One way to solve this is to declare functions A and B as resource classes
> themselves and have the flavor request the function RC. Placement will then
> correctly count the function instances. However, there is still a problem:
> if the requested function A is not available, Placement will return an
> empty list of RPs, but we need some way to reprogram some device to create
> an instance of function A.
>
>
> Clearly, nova is not going to be reprogramming devices with an instance of
> a particular function.
>
> Cyborg might need to have a separate agent that listens to the nova
> notifications queue and upon seeing an event that indicates a failed build
> due to lack of resources, then Cyborg can try and reprogram a device and
> then try rebuilding the original request.
>
>
>
> It was my understanding from that discussion that we intend to insert
> Cyborg into the spawn workflow for device configuration in the same way
> that we currently insert resources provided by Cinder and Neutron. So while
> Nova won't be reprogramming a device, it will be calling out to Cyborg to
> reprogram a device, and waiting while that happens.
>
> My understanding is (and I concede some areas are a little hazy):
>
> * The flavors says device type X with function Y
>
> * Placement tells us everywhere with device type X
>
> * A weigher orders these by devices which already have an available
> function Y (where is this metadata stored?)
>
> * Nova schedules to host Z
>
> * Nova host Z asks cyborg for a local function Y and blocks
>
>   * Cyborg hopefully returns function Y which is already available
>
>   * If not, Cyborg reprograms a function Y, then returns it
>
> Can anybody correct me/fill in the gaps?
>
> *[Mooney, Sean K] that correlates closely to my recollection also. As for
> the metadata I think the weigher may need to call to cyborg to retrieve
> this as it will not be available in the host state object.*
>
Is it the nova scheduler weigher or we want to support weigh on placement?
Function is traits as I think, so can we have preferred_traits? I remember
we talk about that parameter in the past, but we don't have good use-case
at that time. This is good use-case.


> Matt
>
>
>
> --
>
> Matthew Booth
>
> Red Hat OpenStack Engineer, Compute DFG
>
>
>
> Phone: +442070094448 <+44%2020%207009%204448> (UK)
>
>
>
> __
> 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)

[openstack-dev] [heat] tracking the mox removal work

[Zane Bitter]

I know how eager you all are to start replacing mox with mock, so I 
created a spreadsheet to help us avoid tripping over each other in our 
enthusiasm to get it done:


https://ethercalc.openstack.org/heat-mox-removal

Please add links to your patches in there as you create them. This will 
help us to ensure that we only convert each file once :) It's also a 
useful resource for seeing what needs reviews. Alternatively, so is this 
Gerrit query:


https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+intopic:%22%255Emox%255B-_%255Dremoval%22

Happy mocking.

cheers,
Zane.

__
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] [horizon][ptg] Horizon PTG Highlights

[Julia Kreger]

On Tue, Mar 6, 2018 at 2:08 PM, Ivan Kolodyazhny  wrote:

> Horizon needs to fix integration tests
>
> Ironic UI team wants to have their integration tests based on Horizon tests

Not exactly. There are multiple goals, with the central end goal of
preventing breaking changes in horizon from breaking ironic-ui
horribly. This gives Horizon improved feedback as to if major changes
are good or not, and reduces our overall cost to maintain. What we
want and intend is to get a working integration test job in the
ironic-ui repository that is triggered when a change is proposed in
the horizon repository.

Thanks!

-Julia

__
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] [horizon][ptg] Horizon PTG Highlights

[Thomas Goirand]

On 03/06/2018 11:08 PM, Ivan Kolodyazhny wrote:
>   * Angular and XStatic packages versions
>   o testing and updating were done mostly manually by Radomir and Rob
>   o we agreed to update XStatic packages in Rocky if they have
> suitable for Horizon versions and we've got capacity for this

Just a quick input here.

Having JS libs which I don't maintain in Debian to upgrade can be a
long, and painful process, especially for high profile packages like
libjs-jquery. I'd appreciate a lot if I can get a ping before/when this
happen, and this has to happen as early as possible in the cycle.

Also, you don't *HAVE* to upgrade them *ALL* in a single cycle and give
downstream package maintainers so much work! :)

Cheers,

Thomas Goirand (zigo)

__
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] [horizon][ptg] Horizon PTG Highlights

[Ivan Kolodyazhny]

Hi team,

First of all, I would like to say a thank you to all who was able to attend
PTG this time. We'd got very productive discussions with a great team.

Below is my short summary related on the etherpad [1]:

   - Current blueprints and features proposals:
   - we agreed to allow new blueprints and feature proposals due to the dev
  cycle before Feature Freeze milestone [2]
  - it should help contributors who are interested in feature
  development propose and implement new features for Horizon
   - Bugs and reviews list maintaining:
  - we did a good progress on Launchpad bugs list cleanup in Queens
  - it would be good to have a Bug triage days
 - I'll start to do it on a weekly basis
  - we created an etherpad for review priorities [3]
 - I'll review this list before weekly meeting
 - feel free to add anything you think is important to merge it soon
 - we can discuss this list on IRC meeting if needed
  - Should we stop rewriting existing panels with Angular?
   - there are a lot of concerns about re-writing current features with
  Angular JS
  - we've got a lot of not implemented features but do
  re-implementation of the current
  - It would be great to have new features implemented with Angular JS
  but it's not a requirement at the moment
  - seems that we're OK to not block current patches with features
  re-implementation with Angular JS but do not want to start new
patches with
  re-implementation - there is no final decision on this topic yet
   - Fetch resources in parallel
   - we agreed to make go forward with Eventlet by default and make it
  configurable to allow native Python threads which are used now
  - let's ask the community about their experience with Eventlet
  - Eventlet is not the best option for Python 3 at the moment
   - An interaction between Horizon and other projects
   - project teams have troubles with Horizon integration
  - we've got features gap between Horizon and other projects
  - Horizon would like to use project capabilities
  - we need to be more active in cross-project communications
  - Horizon needs to fix integration tests
 - Ironic UI team wants to have their integration tests based on
 Horizon tests
  - it would be good to have Horizon plugins jobs per each Horizon
  commit to being sure that we don't break anything
  - Heat team asked for a help with new XStatic packages
   - Current state in Horizon testing
   - we want to fix our Selenium and Integration tests
  - there is some progress on this
  - once general integration tests framework will be ready, we can
  start fix tests one by one
  - need to figure out why tempest job is not stable enough
  - translations are not enabled in unit-tests
  - having test cases with some non-default locale seems to be good
 - add an option to enable localization in unit-tests
 - Angular and XStatic packages versions
   - testing and updating were done mostly manually by Radomir and Rob
  - we agreed to update XStatic packages in Rocky if they have suitable
  for Horizon versions and we've got capacity for this
   - Horizon accessibility
   - This initiative was started some time ago but isn't maintained now
   - Error handling
  - We need better user-facing error messages
  - We don't log every exception, so it makes hard for operators to
  investigate what went wrong
   - Bandit [3]
  - we're OK to get bandit job like some other projects do


My general feeling is: we're trying to balance between
bug-fixing/stabilization and new features development with a limited number
of resources.

And last, but not least, I want to say thank you to everybody who attends
PTG, does review or proposes patches.



[1] https://etherpad.openstack.org/p/horizon-ptg-rocky
[2] https://releases.openstack.org/rocky/schedule.html#r-ff
[3] https://etherpad.openstack.org/p/horizon-reviews-priority
[4] https://github.com/openstack/bandit


Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
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] [keystone] [infra] Post PTG performance testing needs

[Matthew Treinish]

On Tue, Mar 06, 2018 at 03:28:57PM -0600, Lance Bragstad wrote:
> Hey all,
> 
> Last week during the PTG the keystone team sat down with a few of the
> infra folks to discuss performance testing. The major hurdle here has
> always been having dedicated hosts to use for performance testing,
> regardless of that being rally, tempest, or a home-grown script.
> Otherwise results vary wildly from run to run in the gate due to
> differences from providers or noisy neighbor problems.
> 
> Opening up the discussion here because it sounded like some providers
> (mnaser, mtreinish) had some thoughts on how we can reserve specific
> hardware for these cases.

While I like being called a provider, I'm not really one. I was more trying to
find a use case for my closet cloud [1], and was volunteering to open that up
to external/infra use to provide dedicated hardware for consistent performance
testing. That's still an option, (I mean the boxes are just sitting there not
doing anything) and I'd gladly work with infra and keystone to get that
working. But, if mnaser and vexxhost have an alternative route with their real
capacity and modern hardware, that's probably a better route to go.

-Matt Treinish

[1] https://blog.kortar.org/?p=380
> 


signature.asc
Description: PGP 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

[openstack-dev] [api] [heat] microversion_parse.middleware.MicroversionMiddleware

[Chris Dent]

Last week at the PTG, during the API-SIG session, there was
discussion of extracting the microversion handling middleware that
is used in the placement service into the relatively small
microversion-parse library. This is so people who want to adopt
microversions (or change their implementation) can share some code.

This evening I've got a working version of that, and would like some
feedback (and a few other things as well).

The code is in a stack starting with https://review.openstack.org/#/c/495356/

In total that stack of patches moves most of the microversion
handling code out of placement and adapts it (with some caveats) to
general use.

As a sort of proof, there's also a nova patchset which shows the
removed code. If you install the above stack into the checked out
nova patchset, it works as expected. That nova change is at
https://review.openstack.org/#/c/550265/

Right now the microversion-parse changes are pretty rough but I
don't want to go too far down the road of cleaning them up if the
approach is not going to work for people. Looking at the two
different patchsets will make some of the current limitations more
clear, but some that I'm aware of:

* It wants to use webob, because that's how it started out. This is
  pretty easy to fix with one challenge being managing error
  formatting.

* At the moment it is not yet set up to align with deployment
  strategies such as paste (it uses old school wsgi initialization
  and wrapping). Also pretty easy to fix.

There are some weird boundaries between version info used by the
application, and version info used by the middleware. In the case of
placement, there's some code left in placement for managing
different methods for different versions of requests to the same
URL. This kind of thing would be pretty nice to have in a library,
but the current implementation is very tied to the way placement
does dispatch. For services that already have their own routing
dispatch system, that's kind of a non-starter.

Anyway, if this is a topic of interest to you the code linked above
is available for review and experimentation. If it turns out to be
something people like I'll start the process of making a new release
and getting that release into global requirements.

The other things I'm thinking about are:

* microversion-parse needs more cores. Right now there are only
  three and two of those are unable to be super active in the
  community any more. If you are someone who has knowledge of
  microversions and WSGI middleware, look at the code, and let me
  know.

* If this code is going to be used outside of placement, it may make
  sense for it to go under the umbrella of oslo. I think we may have
  discussed that when the microversion-parse library was initially
  created and at the time I took a wait and see attitude. Is now the
  time? I don't know.

Thanks for your attention and feedback.

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
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] [keystone] [infra] Post PTG performance testing needs

[Clark Boylan]

On Tue, Mar 6, 2018, at 1:28 PM, Lance Bragstad wrote:
> Hey all,
> 
> Last week during the PTG the keystone team sat down with a few of the
> infra folks to discuss performance testing. The major hurdle here has
> always been having dedicated hosts to use for performance testing,
> regardless of that being rally, tempest, or a home-grown script.
> Otherwise results vary wildly from run to run in the gate due to
> differences from providers or noisy neighbor problems.
> 
> Opening up the discussion here because it sounded like some providers
> (mnaser, mtreinish) had some thoughts on how we can reserve specific
> hardware for these cases.
> 
> Thoughts?

Currently the Infra team has access to a variety of clouds, but due to how 
scheduling works we can't rule out noisy neighbors (or even being our own noisy 
neighbor). mtreinish also has data showing that runtimes are too noisy to do 
statistical analysis on, even within a single cloud region. So this is indeed 
an issue in the current setup.

One approach that has been talked about in the past is to measure performance 
impacting operations using metrics other than execution time. For example 
number of sql queries or rabbit requests. I think this would also be valuable 
but won't give you proper performance measurements.

That brought us back to the idea of possibly working with some cloud providers 
like mnaser and/or mtreinish to have a small number of dedicated instances to 
run performance tests on. We could then avoid the noisy neighbor problem as 
well.

For the infra team we would likely need to have at least two providers 
providing these resources so that we could handle the loss of one without 
backing up job queues. I don't think the hardware needs to have an other 
special properties as we don't care about performance on specific hardware as 
much as comparing performance of the project over time on known hardware.

Curious to hear what others may have to say.

Thanks,
Clark

__
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] [cinder][ptg] PTG Summary Now Available ...

[Ivan Kolodyazhny]

Jay, thanks a lot for this great summary!

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Tue, Mar 6, 2018 at 10:02 PM, Jay S Bryant  wrote:

> Team,
>
> I have collected all of our actions and agreements out of the three days
> of etherpads into the following summary page:  [1] . The etherpad includes
> links to the original etherpads and video clips.
>
> I am planning to use the wiki to help guide our development during Rocky.
>
> Let me know if you have any questions or concerns over the content.
>
> Thanks!
>
> Jay
>
> (jungleboyj)
>
> [1] https://wiki.openstack.org/wiki/CinderRockyPTGSummary
>
>
> __
> 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] [keystone] [infra] Post PTG performance testing needs

[Lance Bragstad]

Hey all,

Last week during the PTG the keystone team sat down with a few of the
infra folks to discuss performance testing. The major hurdle here has
always been having dedicated hosts to use for performance testing,
regardless of that being rally, tempest, or a home-grown script.
Otherwise results vary wildly from run to run in the gate due to
differences from providers or noisy neighbor problems.

Opening up the discussion here because it sounded like some providers
(mnaser, mtreinish) had some thoughts on how we can reserve specific
hardware for these cases.

Thoughts?





signature.asc
Description: OpenPGP digital 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

[openstack-dev] [keystone] [policy] No meeting 2018-03-07

[Lance Bragstad]

Just a reminder that we won't be holding a policy meeting tomorrow [0],
since the PTG was last week and people are either still traveling or
recovering. We'll plan to pick things back up next week.

Thanks,

Lance

[0] http://eavesdrop.openstack.org/#Keystone_Policy_Meeting




signature.asc
Description: OpenPGP digital 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

[openstack-dev] [keystone] changing meeting time

[Lance Bragstad]

Hey all,

Per one of the outcomes from the PTG, I've proposed a new time slot for
the keystone weekly meeting [0]. Note that it requires us to move
meeting rooms as well. I'd like to get +1/-1s on the review from people
looking to attend before asking a core to review.

Let's discuss in review.

Thanks,

Lance

[0] https://review.openstack.org/#/c/550260/




signature.asc
Description: OpenPGP digital 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] [docs] Permissions to upload a PNG for my new project page

[Pino de Candia]

Hi Jeremy, that worked (succeeded in uploading and no more capthca). Thanks!

On Tue, Mar 6, 2018 at 8:21 AM, Jeremy Stanley  wrote:

> On 2018-03-05 10:35:00 -0600 (-0600), Pino de Candia wrote:
> [...]
> > But when I try to upload the file I get this error:
> >
> > "You do not have permission to upload this file, for the following
> > reason:
> >
> > The action you have requested is limited to users in one of the
> > groups: Administrators, Autopatrolled users."
> [...]
>
> I have a feeling PTG attendance and associated travel challenges
> have delayed the rate at which the volunteers patrolling recent
> edits in the wiki are verifying validity of edits made by new users.
> As such, your account wasn't marked as verified by anyone until I
> did so just now. Please try again.
>
> Unfortunately we've found that without careful control over
> operations like file uploading or page renames we quickly get
> overrun with spam, so we limit that exposure by vetting accounts
> first. You'll also hopefully find that you no longer get presented
> with a captcha challenge when making page edits now that you're
> verified.
> --
> Jeremy Stanley
>
> __
> 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] [cinder][ptg] PTG Summary Now Available ...

[Jay S Bryant]

Team,

I have collected all of our actions and agreements out of the three days 
of etherpads into the following summary page:  [1] . The etherpad 
includes links to the original etherpads and video clips.


I am planning to use the wiki to help guide our development during Rocky.

Let me know if you have any questions or concerns over the content.

Thanks!

Jay

(jungleboyj)

[1] https://wiki.openstack.org/wiki/CinderRockyPTGSummary


__
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] [Pike][Neutron] ERROR neutron.plugins.ml2.drivers.agent._common_agent - AgentNotFoundByTypeHost

[Torin Woltjer]

My virtual machines do not get their IP addresses, the dashboard does show the 
address they should have, but when using the console to access the virtual 
machine, it shows that no address is assigned to its interface. What kind of 
misconfiguration could've occured?

The following two line repeat in /var/log/nova/nova-compute.log on the compute 
node:

2018-03-06 13:34:15.051 32084 WARNING nova.compute.manager 
[req-cc5ee519-111f-4b70-b77f-b6607c5e611e ffe5adfe1f7c40a5b5d0a8f89e65a452 
358008d2e1a6428ab2abcf51b10d0a50 - default default] [instance: 
7249d430-743e-4463-8d28-d13cdb8cfddc] Received unexpected event 
network-vif-plugged-87e7138e-9e29-4e67-a181-077b3f6ea09b for instance
2018-03-06 13:34:17.563 32084 WARNING nova.compute.manager 
[req-512ef7b6-0936-4dd6-a7e0-0044cee7e9cf ffe5adfe1f7c40a5b5d0a8f89e65a452 
358008d2e1a6428ab2abcf51b10d0a50 - default default] [instance: 
7249d430-743e-4463-8d28-d13cdb8cfddc] Received unexpected event 
network-vif-unplugged-87e7138e-9e29-4e67-a181-077b3f6ea09b for instance

These errors repeat in /var/log/neutron/neutron-linuxbridge-agent.log

2018-03-06 13:38:49.403 1978 INFO neutron.agent.securitygroups_rpc 
[req-262cb010-9068-4ad9-b93d-bd0875fc66e1 - - - - -] Preparing filters for 
devices set(['tap87e7138e-9e'])
2018-03-06 13:38:52.286 1978 INFO neutron.agent.securitygroups_rpc 
[req-262cb010-9068-4ad9-b93d-bd0875fc66e1 - - - - -] Security group member 
updated [u'04a877fe-f6bc-445c-9e03-204a0cae9d32']
2018-03-06 13:38:52.289 1978 INFO 
neutron.plugins.ml2.drivers.agent._common_agent 
[req-262cb010-9068-4ad9-b93d-bd0875fc66e1 - - - - -] Port tap87e7138e-9e 
updated. Details: {u'profile': {}, u'network_qos_policy_id': None, 
u'qos_policy_id': None, u'allowed_address_pairs': [], u'admin_state_up': True, 
u'network_id': u'a06ac367-fe14-4bcd-96f3-8c8081a874ad', u'segmentation_id': 
None, u'mtu': 1500, u'device_owner': u'compute:nova', u'physical_network': 
u'provider', u'mac_address': u'fa:16:3e:23:49:97', u'device': 
u'tap87e7138e-9e', u'port_security_enabled': True, u'port_id': 
u'87e7138e-9e29-4e67-a181-077b3f6ea09b', u'fixed_ips': [{u'subnet_id': 
u'4dc26826-49f3-4cb9-8490-e4cc5e82853d', u'ip_address': u'216.109.195.245'}], 
u'network_type': u'flat'}
2018-03-06 13:38:55.392 1978 INFO neutron.agent.securitygroups_rpc 
[req-262cb010-9068-4ad9-b93d-bd0875fc66e1 - - - - -] Security group member 
updated [u'04a877fe-f6bc-445c-9e03-204a0cae9d32']
2018-03-06 13:38:55.810 1978 INFO neutron.agent.securitygroups_rpc 
[req-262cb010-9068-4ad9-b93d-bd0875fc66e1 - - - - -] Remove device filter for 
set(['tap87e7138e-9e'])
2018-03-06 13:38:57.468 1978 INFO 
neutron.plugins.ml2.drivers.agent._common_agent 
[req-262cb010-9068-4ad9-b93d-bd0875fc66e1 - - - - -] Attachment tap87e7138e-9e 
removed
2018-03-06 13:38:57.909 1978 INFO neutron.agent.securitygroups_rpc 
[req-262cb010-9068-4ad9-b93d-bd0875fc66e1 - - - - -] Security group member 
updated [u'04a877fe-f6bc-445c-9e03-204a0cae9d32']
2018-03-06 13:38:58.199 1978 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent 
[req-262cb010-9068-4ad9-b93d-bd0875fc66e1 - - - - -] Error occurred while 
removing port tap87e7138e-9e: RemoteError: Remote error: 
AgentNotFoundByTypeHost Agent with agent_type=L3 agent and 
host=UBNTU-OSTACK-COMPUTE1 could not be found
[u'Traceback (most recent call last):\n', u'  File 
"/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 160, in 
_process_incoming\nres = self.dispatcher.dispatch(message)\n', u'  File 
"/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 213, 
in dispatch\nreturn self._do_dispatch(endpoint, method, ctxt, args)\n', u'  
File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 
183, in _do_dispatch\nresult = func(ctxt, **new_args)\n', u'  File 
"/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/rpc.py", line 234, in 
update_device_down\nn_const.PORT_STATUS_DOWN, host)\n', u'  File 
"/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/rpc.py", line 331, in 
notify_l2pop_port_wiring\n
l2pop_driver.obj.update_port_down(port_context)\n', u'  File 
"/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/l2pop/mech_driver.py",
 line 253, in update_port_down\nadmin_context, agent_host, 
[port[\'device_id\']]):\n', u'  File 
"/usr/lib/python2.7/dist-packages/neutron/db/l3_agentschedulers_db.py", line 
303, in list_router_ids_on_host\ncontext, constants.AGENT_TYPE_L3, 
host)\n', u'  File "/usr/lib/python2.7/dist-packages/neutron/db/agents_db.py", 
line 291, in _get_agent_by_type_and_host\nhost=host)\n', 
u'AgentNotFoundByTypeHost: Agent with agent_type=L3 agent and 
host=UBNTU-OSTACK-COMPUTE1 could not be found\n'].
2018-03-06 13:38:58.199 1978 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent Traceback (most recent call 
last):
2018-03-06 13:38:58.199 1978 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent   File 

Re: [openstack-dev] [TripleO][CI][QA][HA] Validating HA on upstream

[Raoul Scarazzini]

On 06/03/2018 13:27, Adam Spiers wrote:
> Hi Raoul and all,
> Sorry for joining this discussion late!
[...]
> I do not work on TripleO, but I'm part of the wider OpenStack
> sub-communities which focus on HA[0] and more recently,
> self-healing[1].  With that hat on, I'd like to suggest that maybe
> it's possible to collaborate on this in a manner which is agnostic to
> the deployment mechanism.  There is an open spec on this>    
> https://review.openstack.org/#/c/443504/
> which was mentioned in the Denver PTG session on destructive testing
> which you referenced[2].
[...]
>    https://www.opnfv.org/community/projects/yardstick
[...]
> Currently each sub-community and vendor seems to be reinventing HA
> testing by itself to some extent, which is easier to accomplish in the
> short-term, but obviously less efficient in the long-term.  It would
> be awesome if we could break these silos down and join efforts! :-)

Hi Adam,
First of all thanks for your detailed answer. Then let me be honest
while saying that I didn't know yardstick. I need to start from scratch
here to understand what this project is. In any case, the exact meaning
of this thread is to involve people and have a more comprehensive look
at what's around.
The point here is that, as you can see from the tripleo-ha-utils spec
[1] I've created, the project is meant for TripleO specifically. On one
side this is a significant limitation, but on the other one, due to the
pluggable nature of the project, I think that integrations with other
software like you are proposing is not impossible.
Feel free to add your comments to the review. In the meantime, I'll
check yardstick to see which kind of bridge we can build to avoid
reinventing the wheel.

Thanks a lot again for your involvement,

[1] https://review.openstack.org/#/c/548874/

-- 
Raoul Scarazzini
ra...@redhat.com

__
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] The Weekly Owl - 11th Edition

[Emilien Macchi]

Note: this is the eleventh edition of a weekly update of what happens in
TripleO.
The goal is to provide a short reading (less than 5 minutes) to learn where
we are and what we're doing.
Any contributions and feedback are welcome.
Link to the previous version:
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127583.html

+-+
| General announcements |
+-+

+--> Tripleo Queens RC1 was released last Friday! Congrats to everyone!
+--> PTG was last week, we expect some updates during the following
days/weeks about the topics we covered.

+--+
| Continuous Integration |
+--+

+--> Rover is John and ruck is Matt. Please let them know any new CI issue.
+--> Master promotion is 1 day, Queens is 1 day, Pike is 14 days and Ocata
is 14 days.
+--> Focus is on TripleO CI infrastructure hardening, see
https://trello.com/c/abar9eup/542-tripleo-ci-infrastructure-hardening
+--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting and
https://goo.gl/D4WuBP

+-+
| Upgrades |
+-+

+--> Work in progress: FFU, Queens update/upgrade workflows, need reviews!
see etherpad!
+--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status

+---+
| Containers |
+---+

+--> Containerized undercloud is the major ongoing effort in the squad.
Focus is on making OVB working and also upgrades. Target is rocky-m1.
+--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status

+--+
| config-download |
+--+

+--> Don't miss the deep-dive session to learn more about this awesome
feature! https://www.youtube.com/watch?v=-6ojHT8P4RE
+--> More:
https://etherpad.openstack.org/p/tripleo-config-download-squad-status

+--+
| Integration |
+--+

+--> Team is working on config-download integration and multi-cluster
support.
+--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status

+-+
| UI/CLI |
+-+

+--> Topics discussed during PTG: Network management, GUI/CLI
compatibility, Config download, Root device hints.
+--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status

+---+
| Validations |
+---+

+--> Custom validations spec: https://review.openstack.org/#/c/393775/
+--> Evaluate testing playbooks with containers.
+--> Evaluate OpenShift on OpenStack validations.
+--> Need reviews! (see etherpad)
+--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status

+---+
| Networking |
+---+

+--> No updates this week.
+--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status

+--+
| Workflows |
+--+

+--> No updates this week.
+--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status

+---+
| Security |
+---+

+--> New squad, who will focus improving the overall security of TripleO.
+--> First meeting on IRC tomorrow! (See etherpad).
+--> More: https://etherpad.openstack.org/p/tripleo-security-squad

++
| Owl fact |
++

The tiniest owl in the world is the Elf Owl, which is 5 - 6 inches tall and
weighs about 1 ½ ounces. The largest North American owl, in appearance, is
the Great Gray Owl, which is up to 32 inches tall.
Source: http://www.audubon.org/news/11-fun-facts-about-owls

Stay tuned!
--
Your fellow reporter, Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack] [Pike] [Nova] Error : ERROR : MissingRequiredOptions: Auth plugin requires parameters which were not given: auth_url

[Guru Desai]

Oh my god !!! thank Navdeep..  With this, i m getting below error. Is this
known ?   this command was executed on compute node where

# openstack compute service list --service nova-compute
Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/
and attach the Nova API log if possible.
 (HTTP 500) (Request-ID:
req-3993191e-46ac-4f38-bda9-9b003e6aab1b)



On Tue, Mar 6, 2018 at 10:24 PM, Navdeep Uniyal <
navdeep.uni...@bristol.ac.uk> wrote:

> Hi Guru,
>
>
>
> It should be auth_url. Please see the highlighted error below.
>
>
>
> Regards,
>
> Navdeep
>
>
>
> *From:* Guru Desai 
> *Sent:* 06 March 2018 16:41
> *To:* OpenStack Mailing List 
> *Subject:* [Openstack] [Pike] [Nova] Error : ERROR :
> MissingRequiredOptions: Auth plugin requires parameters which were not
> given: auth_url
>
>
>
> Hello,
>
>
>
> I am setting up pike version and facing an issue with nova on controller.
> I see below errors continouolsy in nova-api.log. But i have given the auth
> parameters in the /etc/nova/nova.conf. I
>
> am done installing keystone and glance, stuck here with nova. Modified the
> nova.conf as per the install guide. Please suggest as to what could be the
> issue..
>
>
>
>
>
>
>
>
>
> [keystone_authtoken]
>
>
>
>
>
> auth_uri = http://test_controller:5000
>
> auth_uri = http://test_controller:35357
>
> memcached_servers = test_controller:11211
>
> auth_type = password
>
> project_domain_name = default
>
> user_domain_name = default
>
> project_name = service
>
> username = nova
>
> password = NOVA_PASS
>
>
>
>
>
>
>
> Log
>
> 
>
>
>
>
>
___
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] [Pike] [Nova] Error : ERROR : MissingRequiredOptions: Auth plugin requires parameters which were not given: auth_url

[Navdeep Uniyal]

Hi Guru,

It should be auth_url. Please see the highlighted error below.

Regards,
Navdeep

From: Guru Desai 
Sent: 06 March 2018 16:41
To: OpenStack Mailing List 
Subject: [Openstack] [Pike] [Nova] Error : ERROR : MissingRequiredOptions: Auth 
plugin requires parameters which were not given: auth_url

Hello,

I am setting up pike version and facing an issue with nova on controller. I see 
below errors continouolsy in nova-api.log. But i have given the auth parameters 
in the /etc/nova/nova.conf. I
am done installing keystone and glance, stuck here with nova. Modified the 
nova.conf as per the install guide. Please suggest as to what could be the 
issue..




[keystone_authtoken]


auth_uri = http://test_controller:5000
auth_uri = http://test_controller:35357
memcached_servers = test_controller:11211
auth_type = password
project_domain_name = default
user_domain_name = default
project_name = service
username = nova
password = NOVA_PASS



Log



___
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] [Pike] [Nova] Error : ERROR : MissingRequiredOptions: Auth plugin requires parameters which were not given: auth_url

[Guru Desai]

Hello,

I am setting up pike version and facing an issue with nova on controller. I
see below errors continouolsy in nova-api.log. But i have given the auth
parameters in the /etc/nova/nova.conf. I
am done installing keystone and glance, stuck here with nova. Modified the
nova.conf as per the install guide. Please suggest as to what could be the
issue..




[keystone_authtoken]


auth_uri = http://test_controller:5000
auth_uri = http://test_controller:35357
memcached_servers = test_controller:11211
auth_type = password
project_domain_name = default
user_domain_name = default
project_name = service
username = nova
password = NOVA_PASS



Log

___
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] [openstack-ansible] Meetings change (PTG discussion follow-up)

[Amy Marrich]

JP,

When the Community meeting was moved to once a month there was a lot of
resulting miscommunication as a result. If a weekly review is going to be
sent to the mailing list with channel discussions is going to be sent out,
I think that's a good alternative but the conversations still need to take
place and as many people involved as possible. What about having office
hours?

Amy (spotz)

On Tue, Mar 6, 2018 at 9:51 AM, Jean-Philippe Evrard <
jean-phili...@evrard.me> wrote:

> Hello,
>
> During the PTG, we've discussed about changing our meetings.
> I'd like to have a written evidence in our mailing lists, showing what
> we discussed, and what we proposed to change. I propose we validate
> those changes if they get no opposition in the next 7 days (deadline:
> 13 March).
>
> What we discussed was:
> - Should the meetings be rescheduled, and at what time;
> - Should the meetings be happening in alternance for US/Europe
> friendly timezones;
> - What is the purpose/expected outcome of those meetings;
> - What is the reason the attendance is low.
>
> The summary is the following:
> - The expected outcome of bug triage is currently (drumroll)
> actively triaging bugs which produces better deliverables (what a
> surprise!).
> - The expected outcome of the community meeting is to discuss about
> what we actively need to work on together, but we are doing these kind
> of conversations, ad-hoc, in the channel. So if we summarize things on
> a regular basis to make sure everyone is aware of the conversations,
> we should be good.
> - The timezone friendly things won't impact the attendance positively.
> - Right now, the Europe meetings can be postponed of one hour, but
> decision should be re-discussed with daylight saving.
> - A lot of ppl have meetings at 4PM UTC right now.
>
> As such, here is the PTG proposed change:
> - Moving the bug triage meeting to 5PM UTC until next daylight saving
> change.
> - Keep the "Focus of the week" section of the bug triage, to list what
> we discussed in the week (if more conversations have to happen, they
> can happen just after the bug triage)
> - Removing the community meeting.
>
> Any opposition there? If we are all okay, I will update our procedures
> next week.
>
> Best regards,
> JP
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-ansible] Meetings change (PTG discussion follow-up)

[Jean-Philippe Evrard]

Hello,

During the PTG, we've discussed about changing our meetings.
I'd like to have a written evidence in our mailing lists, showing what
we discussed, and what we proposed to change. I propose we validate
those changes if they get no opposition in the next 7 days (deadline:
13 March).

What we discussed was:
- Should the meetings be rescheduled, and at what time;
- Should the meetings be happening in alternance for US/Europe
friendly timezones;
- What is the purpose/expected outcome of those meetings;
- What is the reason the attendance is low.

The summary is the following:
- The expected outcome of bug triage is currently (drumroll)
actively triaging bugs which produces better deliverables (what a
surprise!).
- The expected outcome of the community meeting is to discuss about
what we actively need to work on together, but we are doing these kind
of conversations, ad-hoc, in the channel. So if we summarize things on
a regular basis to make sure everyone is aware of the conversations,
we should be good.
- The timezone friendly things won't impact the attendance positively.
- Right now, the Europe meetings can be postponed of one hour, but
decision should be re-discussed with daylight saving.
- A lot of ppl have meetings at 4PM UTC right now.

As such, here is the PTG proposed change:
- Moving the bug triage meeting to 5PM UTC until next daylight saving change.
- Keep the "Focus of the week" section of the bug triage, to list what
we discussed in the week (if more conversations have to happen, they
can happen just after the bug triage)
- Removing the community meeting.

Any opposition there? If we are all okay, I will update our procedures
next week.

Best regards,
JP

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

[Openstack-operators] [glance] proposal to deprecate owner_is_tenant option

[Brian Rosmaita]

Hello Operators,

There's a spec-lite up to deprecate the owner_is_tenant option, with
the goal being to eliminate the option so that the owner of an image
is always the project (tenant).  Based on a survey of operators in
March 2017, no one is using the option in its non-default
configuration, so no migration path is proposed.

Please leave comments on the gerrit review before 12:00 UTC on Tuesday 13 March:
https://review.openstack.org/#/c/550096/

Thanks!

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

Re: [openstack-dev] [Nova] [Cyborg] Tracking multiple functions

[Mooney, Sean K]

From: Matthew Booth [mailto:mbo...@redhat.com]
Sent: Saturday, March 3, 2018 4:15 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Nova] [Cyborg] Tracking multiple functions

On 2 March 2018 at 14:31, Jay Pipes 
> wrote:
On 03/02/2018 02:00 PM, Nadathur, Sundar wrote:
Hello Nova team,

 During the Cyborg discussion at Rocky PTG, we proposed a flow for FPGAs 
wherein the request spec asks for a device type as a resource class, and 
optionally a function (such as encryption) in the extra specs. This does not 
seem to work well for the usage model that I’ll describe below.

An FPGA device may implement more than one function. For example, it may 
implement both compression and encryption. Say a cluster has 10 devices of 
device type X, and each of them is programmed to offer 2 instances of function 
A and 4 instances of function B. More specifically, the device may implement 6 
PCI functions, with 2 of them tied to function A, and the other 4 tied to 
function B. So, we could have 6 separate instances accessing functions on the 
same device.

Does this imply that Cyborg can't reprogram the FPGA at all?
[Mooney, Sean K] cyborg is intended to support fixed function acclerators also 
so it will not always be able to program the accelerator. In this case where an 
fpga is preprogramed with a multi function bitstream that is statically 
provisioned cyborge will not be able to reprogram the slot if any of the 
fuctions from that slot are already allocated to an instance. In this case it 
will have to treat it like a fixed function device and simply allocate a unused 
 vf  of the corret type if available.



In the current flow, the device type X is modeled as a resource class, so 
Placement will count how many of them are in use. A flavor for ‘RC 
device-type-X + function A’ will consume one instance of the RC device-type-X.  
But this is not right because this precludes other functions on the same device 
instance from getting used.

One way to solve this is to declare functions A and B as resource classes 
themselves and have the flavor request the function RC. Placement will then 
correctly count the function instances. However, there is still a problem: if 
the requested function A is not available, Placement will return an empty list 
of RPs, but we need some way to reprogram some device to create an instance of 
function A.

Clearly, nova is not going to be reprogramming devices with an instance of a 
particular function.

Cyborg might need to have a separate agent that listens to the nova 
notifications queue and upon seeing an event that indicates a failed build due 
to lack of resources, then Cyborg can try and reprogram a device and then try 
rebuilding the original request.

It was my understanding from that discussion that we intend to insert Cyborg 
into the spawn workflow for device configuration in the same way that we 
currently insert resources provided by Cinder and Neutron. So while Nova won't 
be reprogramming a device, it will be calling out to Cyborg to reprogram a 
device, and waiting while that happens.
My understanding is (and I concede some areas are a little hazy):
* The flavors says device type X with function Y
* Placement tells us everywhere with device type X
* A weigher orders these by devices which already have an available function Y 
(where is this metadata stored?)
* Nova schedules to host Z
* Nova host Z asks cyborg for a local function Y and blocks
  * Cyborg hopefully returns function Y which is already available
  * If not, Cyborg reprograms a function Y, then returns it
Can anybody correct me/fill in the gaps?
[Mooney, Sean K] that correlates closely to my recollection also. As for the 
metadata I think the weigher may need to call to cyborg to retrieve this as it 
will not be available in the host state object.
Matt


--
Matthew Booth
Red Hat OpenStack Engineer, Compute DFG

Phone: +442070094448 (UK)

__
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] [mistral] What's new in latest CloudFlow?

[Dougal Matthews]

I checked with one of the tripleo-ui developers. They are using redux
thunks to execute the API calls and they pointed me to this part of the
code.

https://github.com/openstack/tripleo-ui/blob/master/src/js/services/KeystoneApiService.js

Hopefully that is useful - it looks like the custom code required is fairly
small.

Cheers,
Dougal


On 1 March 2018 at 16:37, Shaanan, Guy (Nokia - IL/Kfar Sava) <
guy.shaa...@nokia.com> wrote:

> Hi Dougal,
>
> Yes, it probably does help.
>
> I haven’t found any proper Keystone JavaScript library (if anyone knows
> about one let me know).
>
>
>
> *From:* Dougal Matthews [mailto:dou...@redhat.com]
> *Sent:* Thursday, March 1, 2018 17:43
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [mistral] What's new in latest CloudFlow?
>
>
>
> Hey Guy,
>
> Thanks for sharing this update. I need to find time to try it out. The
> biggest issue for me is the lack of keystone support.
>
>
>
> I wonder if any of the code in tripleo-ui could be used to help with
> KeyStone support. It is a front-end JavaScript GUI.
> https://github.com/openstack/tripleo-ui
>
>
>
> Cheers,
>
> Dougal
>
>
>
> On 26 February 2018 at 09:10, Shaanan, Guy (Nokia - IL/Kfar Sava) <
> guy.shaa...@nokia.com> wrote:
>
> CloudFlow [1] is an open-source web-based GUI tool that helps visualize
> and debug Mistral workflows.
>
>
>
> With the latest release [2] of CloudFlow (v0.5.0) you can:
>
> * Visualize the flow of workflow executions
>
> * Identify the execution path of a single task in huge workflows
>
> * Search Mistral by any entity ID
>
> * Identify long-running tasks at a glance
>
> * Easily distinguish between simple task (an action) and a sub workflow
> execution
>
> * Follow tasks with a `retry` and/or `with-items`
>
> * 1-click to copy task's input/output/publish/params values
>
> * See complete workflow definition and per task definition YAML
>
> * And more...
>
>
>
> CloudFlow is easy to install and run (and even easier to upgrade), and we
> appreciate any feedback and contribution.
>
>
>
> CloudFlow currently supports unauthenticated Mistral or authentication
> with KeyCloak (openid-connect implementation). A support for Keystone will
> be added in the near future.
>
>
>
> You can try CloudFlow now on your Mistral Pike/Queens, or try it on the
> online demo [3].
>
>
>
> [1] https://github.com/nokia/CloudFlow
>
> [2] https://github.com/nokia/CloudFlow/releases/latest
>
> [3] http://yaqluator.com:8000
>
>
>
>
>
> Thanks,
>
> *-*
>
> *Guy Shaanan*
>
> Full Stack Web Developer, CI & Internal Tools
>
> CloudBand @ Nokia Software, Nokia, ISRAEL
>
> guy.shaa...@nokia.com
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [mistral] Retiring the Mistral Wiki pages

[Dougal Matthews]

Hey folks,

Mistral has several Wiki pages that rank highly in Google searches.
However, most of them have not been updated in months (or years in many
cases). I am therefore starting to remove these and direct people to the
Mistral documentation. Where possible I will link them to the relevant
documentation pages.

I have taken the plunge and removed the main wiki [0] page. The old content
is still accessible [1], just click on "Page" at the top left and then go
to history.

Over the next week or so I am going to read through the old wiki pages and
see if there is any information that is still relevant and move it to the
Mistral documentation. If you are aware of anything that is in the wiki,
but not in the docs (and should be) then please submit a patch or open a
bug.

After we consolidate all of the information into the Mistral docs I hope to
coordinate an effort to improve the documentation.

Cheers,
Dougal

[0]: https://wiki.openstack.org/wiki/Mistral
[1]: https://wiki.openstack.org/w/index.php?title=Mistral=152120
__
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] [docs] Permissions to upload a PNG for my new project page

[Jeremy Stanley]

On 2018-03-05 10:35:00 -0600 (-0600), Pino de Candia wrote:
[...]
> But when I try to upload the file I get this error:
> 
> "You do not have permission to upload this file, for the following
> reason:
> 
> The action you have requested is limited to users in one of the
> groups: Administrators, Autopatrolled users."
[...]

I have a feeling PTG attendance and associated travel challenges
have delayed the rate at which the volunteers patrolling recent
edits in the wiki are verifying validity of edits made by new users.
As such, your account wasn't marked as verified by anyone until I
did so just now. Please try again.

Unfortunately we've found that without careful control over
operations like file uploading or page renames we quickly get
overrun with spam, so we limit that exposure by vetting accounts
first. You'll also hopefully find that you no longer get presented
with a captcha challenge when making page edits now that you're
verified.
-- 
Jeremy Stanley


signature.asc
Description: PGP 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] [tripleo] [security] Proposing Security Squad

[Luke Hinds]

On Tue, Mar 6, 2018 at 1:37 PM, Jeremy Stanley  wrote:

> On 2018-03-06 14:40:53 +0200 (+0200), Juan Antonio Osorio wrote:
> > As mentioned in the PTG, I would like to start a Security Squad
> > for TripleO, with the goal of working with the security aspects
> > and challenges in a more public manner.
> [...]
>
> I would also strongly encourage you all to get involved with the
> OpenStack Security SIG. We're always looking for help/input with
> regard to information security concerns and ideas. The weekly
> meeting has recently been rescheduled to 15:00 UTC on Thursdays if
> you're available, and we have a #openstack-security IRC channel on
> Freenode where many of us can be found.
> --
> Jeremy Stanley
>
>
Hi Jeremy, Good call - and I made a note in the squad planning pad ("General
OpenStack security topics should go to the Security SIG."



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

Re: [openstack-dev] [tripleo] [security] Proposing Security Squad

[Jeremy Stanley]

On 2018-03-06 14:40:53 +0200 (+0200), Juan Antonio Osorio wrote:
> As mentioned in the PTG, I would like to start a Security Squad
> for TripleO, with the goal of working with the security aspects
> and challenges in a more public manner.
[...]

I would also strongly encourage you all to get involved with the
OpenStack Security SIG. We're always looking for help/input with
regard to information security concerns and ideas. The weekly
meeting has recently been rescheduled to 15:00 UTC on Thursdays if
you're available, and we have a #openstack-security IRC channel on
Freenode where many of us can be found.
-- 
Jeremy Stanley


signature.asc
Description: PGP 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] [kolla] Ubuntu jobs failed on pike branch due to package dependency

[Jeffrey Zhang]

Here is what i tried[0].

- pin ceph version in ceph-* container to Jewel.
- the clients (nova/gnocchi/cinder) container use ceph Luminous.

I made some test locally with a env: nova + glance + gnocchi + ceph, seems
it works.


[0] https://review.openstack.org/549466

On Tue, Feb 27, 2018 at 12:53 AM, Michał Jastrzębski 
wrote:

> I'm for option 1 definitely. accidental ceph upgrade during routine
> minor version upgrade is something we don't want. We will need big
> warning about this version mismatch in release notes.
>
> On 26 February 2018 at 07:01, Eduardo Gonzalez  wrote:
> > I prefer option 1, breaking stable policy is not good for users. They
> will
> > be forced to upgrade a major ceph version during a minor upgrade, which
> is
> > not good and not excepted to be done ever.
> >
> > Regards
> >
> >
> > 2018-02-26 9:51 GMT+01:00 Shake Chen :
> >>
> >> I prefer to the option 2.
> >>
> >> On Mon, Feb 26, 2018 at 4:39 PM, Jeffrey Zhang  >
> >> wrote:
> >>>
> >>> Recently, the Ubuntu jobs on pike branch are red[0]. With some
> debugging,
> >>> i found it is caused by
> >>> package dependency.
> >>>
> >>>
> >>> *Background*
> >>>
> >>> Since we have no time to upgrade ceph from Jewel to Luminous at the end
> >>> of pike cycle, we pinned
> >>> Ceph to Jewel on pike branch. This works on CentOS, because ceph jewel
> >>> and ceph luminous are on
> >>> the different repos.
> >>>
> >>> But in Ubuntu Cloud Archive repo, it bump ceph to Luminous. Even though
> >>> ceph luminous still exists
> >>> on UCA. But since qemu 2.10 depends on ceph luminous, we have to ping
> >>> qemu to 2.5 to use ceph Jewel[1].
> >>> And this works since then.
> >>>
> >>>
> >>> *Now Issue*
> >>>
> >>> But recently, UCA changed the libvirt-daemon package dependency, and
> >>> added following,
> >>>
> >>> Package: libvirt-daemon
> >>> Version: 3.6.0-1ubuntu6.2~cloud0
> >>> ...
> >>> Breaks: qemu (<< 1:2.10+dfsg-0ubuntu3.4~), qemu-kvm (<<
> >>> 1:2.10+dfsg-0ubuntu3.4~)
> >>>
> >>> It requires qemu 2.10 now. So dependency is broken and nova-libvirt
> >>> container is failed to build.
> >>>
> >>>
> >>> *Possible Solution*
> >>>
> >>> I think there two possible ways now, but none of them is good.
> >>>
> >>> 1. install ceph Luminuous on nova-libvirt container and ceph Jewel in
> >>> ceph-* container
> >>> 2. Bump ceph from jewel to luminous. But this breaks the backport
> policy,
> >>> obviously.
> >>>
> >>> So any idea on this?
> >>>
> >>> [0] https://review.openstack.org/534149
> >>> [1] https://review.openstack.org/#/c/526931/
> >>>
> >>> --
> >>> 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
> >>>
> >>
> >>
> >>
> >> --
> >> Shake Chen
> >>
> >>
> >> 
> __
> >> 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
>



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

[Openstack-operators] Stable Branch EOL and "Extended Maintenance" Resolution

[Melvin Hillsman]

Hi everyone,

If you are interested in the items in the subject please be sure to take
time to review and comment on the following patch -
https://review.openstack.org/#/c/548916/

-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [TripleO][CI][QA][HA] Validating HA on upstream

[Adam Spiers]

Hi Raoul and all,

Sorry for joining this discussion late!

Raoul Scarazzini  wrote:

TL;DR: we would like to change the way HA is tested upstream to avoid
being hitten by evitable bugs that the CI process should discover.

Long version:

Today HA testing in upstream consist only in verifying that a three
controllers setup comes up correctly and can spawn an instance. That's
something, but it’s far from being enough since we continuously see "day
two" bugs.
We started covering this more than a year ago in internal CI and today
also on rdocloud using a project named tripleo-quickstart-utils [1].
Apart from his name, the project is not limited to tripleo-quickstart,
it covers three principal roles:

1 - stonith-config: a playbook that can be used to automate the creation
of fencing devices in the overcloud;
2 - instance-ha: a playbook that automates the seventeen manual steps
needed to configure instance HA in the overcloud, test them via rally
and verify that instance HA works;
3 - validate-ha: a playbook that runs a series of disruptive actions in
the overcloud and verifies it always behaves correctly by deploying a
heat-template that involves all the overcloud components;


Yes, a more rigorous approach to HA testing obviously has huge value,
not just for TripleO deployments, but also for any type of OpenStack
deployment.


To make this usable upstream, we need to understand where to put this
code. Here some choices:


[snipped]

I do not work on TripleO, but I'm part of the wider OpenStack
sub-communities which focus on HA[0] and more recently,
self-healing[1].  With that hat on, I'd like to suggest that maybe
it's possible to collaborate on this in a manner which is agnostic to
the deployment mechanism.  There is an open spec on this:

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

which was mentioned in the Denver PTG session on destructive testing
which you referenced[2].

As mentioned in the self-healing SIG's session in Dublin[3], the OPNFV
community has already put a lot of effort into testing HA scenarios,
and it would be great if this work was shared across the whole
OpenStack community.  In particular they have a project called
Yardstick:

   https://www.opnfv.org/community/projects/yardstick

which contains a bunch of HA test cases:

   
http://docs.opnfv.org/en/latest/submodules/yardstick/docs/testing/user/userguide/15-list-of-tcs.html#h-a

Currently each sub-community and vendor seems to be reinventing HA
testing by itself to some extent, which is easier to accomplish in the
short-term, but obviously less efficient in the long-term.  It would
be awesome if we could break these silos down and join efforts! :-)

Cheers,
Adam

[0] #openstack-ha on Freenode IRC
[1] https://wiki.openstack.org/wiki/Self-healing_SIG
[2] https://etherpad.openstack.org/p/qa-queens-ptg-destructive-testing
[3] https://etherpad.openstack.org/p/self-healing-ptg-rocky

__
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] Proposing Security Squad

[Juan Antonio Osorio]

Hello!

As mentioned in the PTG, I would like to start a Security Squad for
TripleO, with the goal of working with the security aspects and challenges
in a more public manner.

We'll have our first meeting tomorrow. With weekly meetings every wednesday
at 1pm UTC.

We started an etherpad already
https://etherpad.openstack.org/p/tripleo-security-squad

And here's the patch adding the Security Squad to the list
https://review.openstack.org/#/c/550001/

Feel free to join if you're interested.

BR

-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][l2gw] Rocky goals for Networking L2GW

[Ricardo Noriega De Soto]

Hi L2GWers,

Eventhough this is a project with few active contributors, these are our
goals for Rocky release:


   - OpenStack client migration
   - Out-of-sync DB common effort (together with networking-odl,
   networking-ovn, etc.)
   - Broad CI jobs scenarios (adding a HWVTEP emultator)
   - Add Grenade support for upgrade testing.
   - Rocky community goals (removing mox and changing configuration without
   restarting services)

Please, if you have any other proposal, just let us know via mailing list,
or reply to this very same email.

Cheers


-- 
Ricardo Noriega

Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
Red Hat
irc: rnoriega @freenode
__
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] [glance] fixing OSSN-0075

[Brian Rosmaita]

Hello Operators,

The spec for a fix of OSSN-0075, "Deleted Glance image IDs may be
reassigned", has been revised after discussions at the PTG last week
and is ready for your comments.  As you may be aware, the spec has
been held up over disagreement about the proper way to fix the issue,
but the Glance team has agreed on a way forward in which the
interoperability and backward compatibility aspects win out.

Please read through the spec and leave comments before Tuesday 13
March at 12:00 UTC:
https://review.openstack.org/#/c/468179/

Thanks!

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

[Openstack-operators] [ironic] heads-up: classic drivers deprecation and future removal

[Dmitry Tantsur]

Hi all,

As you may already know, we have deprecated classic drivers in the Queens 
release. We don't have specific removal plans yet. But according to the 
deprecation policy we may remove them at any time after May 1st, which will be 
half way to Rocky milestone 2. Personally, I'd like to do it around then.


The `online_data_migrations` script will handle migrating nodes, if all required 
hardware interfaces and types are enabled before the upgrade to Queens. 
Otherwise, check the documentation [1] on how to update your nodes.


Dmitry

[1] 
https://docs.openstack.org/ironic/latest/admin/upgrade-to-hardware-types.html

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

[openstack-dev] [ironic] heads-up: classic drivers deprecation and future removal

[Dmitry Tantsur]

Hi all,

As you may already know, we have deprecated classic drivers in the Queens 
release. We don't have specific removal plans yet. But according to the 
deprecation policy we may remove them at any time after May 1st, which will be 
half way to Rocky milestone 2. Personally, I'd like to do it around then.


The `online_data_migrations` script will handle migrating nodes, if all required 
hardware interfaces and types are enabled before the upgrade to Queens. 
Otherwise, check the documentation [1] on how to update your nodes.


Dmitry

[1] 
https://docs.openstack.org/ironic/latest/admin/upgrade-to-hardware-types.html

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

[openstack-dev] [openstack-helm]Re: Question about API endpoints

[渥美 慶彦]

Hi Hyunsun,

Thank you for your help!!
My　questions has been solved.

On 2018/03/05 16:42, Hyunsun Moon wrote:

Hi Yoshihiko,

If you have physical LB in your environment, you might want to make use of 
NodePort for distributing the access to multiple controller nodes. In that 
case, it is recommended to set Values.network.external_policy_local to true so 
that you could eliminate unnecessary hops.
Ingress backed by nginx could be used of course, but as you pointed, IP address 
of the node where ingress pod resides will be the address you’re accessing, 
which might not be desirable in many use cases.
If you plan to try it on GCP/GKE, where the ingress controller is backed by 
GCP’s load-balancer service, NodePort + ingress seems valid option for exposing 
your service to external.
FYI, https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer 


Hope this helps.

Hyunsun



On 5 Mar 2018, at 2:34 PM, 渥美 慶彦  wrote:

Hi all,
# Resend with openstack-helm tag

I try to deploy multinode OpenStack by openstack-helm
and want to access OpenStack API endpoints from out of k8s nodes.
To avoid service failure by node down, I think I need one virtual IP for the 
endpoints.(like Pacemaker)
Could you show me how to realize that if you have any information?

A. Deploy OpenStack services for NodePort, and distribute the access to nodes 
using physical Load Balancer.
B. Using Ingress?
   I think Ingress is for L7 routing, so it can't be used to create VIP for the 
endpoints.
C. Any other ideas?

And when I try this on GCP/GKE, is there any difference from on-premises?

best regards

--

Yoshihiko Atsumi
E-mail：atsumi.yoshih...@po.ntt-tx.co.jp




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




__
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


--

Yoshihiko Atsumi
E-mail：atsumi.yoshih...@po.ntt-tx.co.jp


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

Re: [Openstack] Some questions about "Cinder Multi-Attach" in Openstack Queens

[Arne Wiebalck]

Multi-attach will not allow you to have a block device with a local file-system 
to be concurrently
accessed from multiple nodes. It is intended for HA scenarios where a second 
server can take
over a block device from another server. So, if you unmount on your first 
server, you can mount
on the second and you will see your file.

Arne

On 06 Mar 2018, at 09:53, 谭 明宵 
> wrote:

I  installed the openstack queens use devstack. I want to test the "Cinder 
Multi-Attach" function

1. create a  multiattach volume
```
# cinder type-create multiattach
# cinder type-key multiattach set multiattach=" True"
#  cinder create 10 --name multiattach-volume --volume-type 
```
2. attache the volume to two instances
```
# nova volume-attach test01 
# nova volume-attach test02 
```
<7B194ED4-5D18-4FFA-9FF3-E54DB425E7E4.png>
3. mount the volume , create some file，but the file don't sync between the two 
instance，It seems that they are two independent volumes
<4DFCCC80-5132-4383-B986-726664E45EAF.png>

then test02 create a file，but i cannot find it in test01,The reverse is the 
same.



I think i have something wrong，the test like the "share storage"
What should the correct effect be like? thanks

___
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

--
Arne Wiebalck
CERN IT

___
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] Some questions about "Cinder Multi-Attach" in Openstack Queens

[谭 明宵]

thanks a lot for your help

On 3/6/2018 17:47，Arne 
Wiebalck wrote：
Multi-attach will not allow you to have a block device with a local file-system 
to be concurrently
accessed from multiple nodes. It is intended for HA scenarios where a second 
server can take
over a block device from another server. So, if you unmount on your first 
server, you can mount
on the second and you will see your file.

Arne

On 06 Mar 2018, at 09:53, 谭 明宵 
> wrote:

I  installed the openstack queens use devstack. I want to test the "Cinder 
Multi-Attach" function

1. create a  multiattach volume
```
# cinder type-create multiattach
# cinder type-key multiattach set multiattach=" True"
#  cinder create 10 --name multiattach-volume --volume-type 
```
2. attache the volume to two instances
```
# nova volume-attach test01 
# nova volume-attach test02 
```
<7B194ED4-5D18-4FFA-9FF3-E54DB425E7E4.png>
3. mount the volume , create some file，but the file don't sync between the two 
instance，It seems that they are two independent volumes
<4DFCCC80-5132-4383-B986-726664E45EAF.png>

then test02 create a file，but i cannot find it in test01,The reverse is the 
same.



I think i have something wrong，the test like the "share storage"
What should the correct effect be like? thanks

___
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

--
Arne Wiebalck
CERN IT

___
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] Queens packages for openSUSE and SLES available

[Thomas Bechtold]

Hi,

Queens packages for openSUSE and SLES are now available at:

http://download.opensuse.org/repositories/Cloud:/OpenStack:/Queens/

We maintain + test the packages for SLES 12SP3 and openSUSE Leap 42.3.

If you find issues, please do not hesitate to report them to
opensuse-cloud at opensuse.org or to https://bugzilla.opensuse.org/

Thanks and have a lot of fun,

Tom

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

Re: [Openstack] Some questions about "Cinder Multi-Attach" in Openstack Queens

[Van Leeuwen, Robert]

# I  installed the openstack queens use devstack. I want to test the "Cinder 
Multi-Attach" function
# 3. mount the volume , create some file，but the file don't sync between the 
two instance，It seems that they are two independent volumes

Did you unmount the filesystem on the first node before mounting it on the 
second node?
You cannot mount a filesystem on 2 nodes at the same time unless you are using 
a shared-disk filesystem. (e.g. something like gfs2 ).

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

[openstack-dev] Queens packages for openSUSE and SLES available

[Thomas Bechtold]

Hi,

Queens packages for openSUSE and SLES are now available at:

http://download.opensuse.org/repositories/Cloud:/OpenStack:/Queens/

We maintain + test the packages for SLES 12SP3 and openSUSE Leap 42.3.

If you find issues, please do not hesitate to report them to
opensuse-cloud at opensuse.org or to https://bugzilla.opensuse.org/

Thanks and have a lot of fun,

Tom

__
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] [I18n] Translation plan & priorities for Rocky

[Frank Kloeker]

Good morning,

welcome to the Rocky translation release cycle! We merged today on our 
translation platform the stable-queens translations back to master and 
created a new translation dashboard on [1]. There are 19 projects 
identified for translation in Rocky. Please check your own project, if 
it meets your expectations.


Furthermore we have 5 documentation projects still on the list [2]. 
There is a very good progress and only deltas are required to translate.


Additional we have the translation for the Edge Computing Whitepaper 
still online [3]. If you are interested to have this in your language, 
please go ahead. New language version will be accepted.


Early April we want to start with a new User Survey Translation. There 
will be very few changes. Due the upcoming Summit in Berlin we want to 
translate the results of the survey also, at least to German.


Last but not least, as Petr mentioned yesterday evening on 
openstack-dev, our big goal for Rocky is project doc translation. We 
already talked to some project teams in Dublin and we're still in 
preparation before we can start. If you have any questions or hints, let 
me know.


kind regards

Frank
PTL I18n

[1] 
https://translate.openstack.org/version-group/view/Rocky-dashboard-translation

[2] https://translate.openstack.org/version-group/view/doc-resources
[3] 
https://translate.openstack.org/iteration/view/edge-computing/master/documents


__
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] Some questions about "Cinder Multi-Attach" in Openstack Queens

[谭 明宵]

I  installed the openstack queens use devstack. I want to test the "Cinder 
Multi-Attach" function

1. create a  multiattach volume
```
# cinder type-create multiattach
# cinder type-key multiattach set multiattach=" True"
#  cinder create 10 --name multiattach-volume --volume-type 
```
2. attache the volume to two instances
```
# nova volume-attach test01 
# nova volume-attach test02 
```
[cid:DCD455A4-5EDA-44C0-9DA9-877CCF9C679E@mailmaster]
3. mount the volume , create some file，but the file don't sync between the two 
instance，It seems that they are two independent volumes
[cid:99ABEDC0-DE62-497F-931B-8F5276ADD2E1@mailmaster]

then test02 create a file，but i cannot find it in test01,The reverse is the 
same.

[cid:C2C7FD23-2B2B-4060-9155-C9AC30953580@mailmaster]

I think i have something wrong，the test like the "share storage"
What should the correct effect be like? thanks

___
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] [cinder] Cinder volume revert to snapshot with Ceph

[李杰]

Hi,all


  This is the patch [0] about volume revert to snapshot with Ceph.Is anyone 
working on this patchset or maybe new patchset was proposed to implement RBD 
specific functionality?Can you tell me more about this ?Thank you very much.
  The link is here.
  Re:https://review.openstack.org/#/c/481566/














Best Regards
Lijie__
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