[openstack-dev] [neutron] Metering can't count traffic for floating ip, or internal ip.

[wenran xiao]

hi all，
neutron metering can only count traffic that we send to
*remote_ip*(egress), and *remote_ip* send to us(ingress), I think we should
add method to count the traffic for floating ip or internal ip.
Any suggestions is welcome.


Best regards
Ran
__
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] Metering can't count traffic for floating ip, or internal ip.

[wenran xiao]

hi all，
neutron metering can only count traffic that we send to
*remote_ip*(egress), and *remote_ip* send to us(ingress), I think we should
add method to count the traffic for floating ip or internal ip.
Any suggestions is welcome.


Best regards
Ran
__
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] zuulv3 log structure and format grumblings

[Andrea Frittoli]

On Thu, 4 Jan 2018, 11:15 pm Matt Riedemann,  wrote:

> On 1/4/2018 12:20 PM, Clark Boylan wrote:
> > I've pushed uphttps://review.openstack.org/531208  as a quick check
> that this is indeed the general problem, but for longer term fix I think we
> want to update our log publishing ansible roles to compress everything that
> isn't already compressed.
>
> Yup this fixes the log formatting/color/linking stuff, thanks!
>
> I noted that the config files still have to be downloaded, and dmsimard
> pointed out that conf/ini/filters files will have to be mapped here:
>
>
> http://git.openstack.org/cgit/openstack-infra/puppet-openstackci/tree/templates/logs.vhost.erb#n24



The ansible role that stages files supports renaming files with specified
extensions to .txt, but it looks like something is not going right.

I'm on PTO until the 9th, if it's an issue still I'll look into it as soon
as I'm back.

Andrea (andreaf)

>
>
> I don't know if we can just convert everything under etc/ or not? That
> seems better to me, but I don't know anything about modifying vhost files.
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][CI] Which network templates to use in CI (with and without net isolation)?

[James Slagle]

On Thu, Jan 4, 2018 at 5:26 PM, Sagi Shnaidman  wrote:
> Hi, all
>
> we have now network templates in tripleo-ci repo[1] and we'd like to move
> them to tht repo[2] and to use them from there.

They've already been moved from tripleo-ci to tripleo-heat-templates:
https://review.openstack.org/#/c/476708/

> We have also default
> templates defined in overcloud-deploy role[3].
> So the question is - which templates should we use and how to configure
> them?

We should use the ones for ci, not the examples under
tripleo-heat-templates/network/config. Those examples (especially for
multiple-nics) are meant to be clear and orderly so that users can
easily understand how to adapt them to their own environments.
Especially for multiple-nics, there isn't really a sane default, and I
don't think we should make our examples match what we use in ci.

It may be possible to update ovb so that it deploys virt environments
such that the examples work. That feels like a lot of unecessary churn
though. But even then ci is using mtu:1350, which we don't want in the
examples.

> One option for configuration is set network args (incl. isolation) in
> overcloud-deploy role[3] depending on other features (like docker, ipv6,
> etc).
> The other is to set them in featureset[4] files for each job.
> The question is also which network templates we want to gate in CI and
> should it be the same we have by default in tripleo-quickstart-extras?
>
> We have a few patches from James (@slagle) to address this topic[5]

What I'm trying to do in these patches is just use the templates and
environments from tripleo-heat-templates that were copied from
tripleo-ci in 476708. I gathered that was the intent since they were
copied into tripleo-heat-templates. Otherwise, why do we need them
there are at all?

-- 
-- James Slagle
--

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

[openstack-dev] [TripleO][CI] Which network templates to use in CI (with and without net isolation)?

[Sagi Shnaidman]

Hi, all

we have now network templates in tripleo-ci repo[1] and we'd like to move
them to tht repo[2] and to use them from there. We have also default
templates defined in overcloud-deploy role[3].
So the question is - which templates should we use and how to configure
them?
One option for configuration is set network args (incl. isolation) in
overcloud-deploy role[3] depending on other features (like docker, ipv6,
etc).
The other is to set them in featureset[4] files for each job.
The question is also which network templates we want to gate in CI and
should it be the same we have by default in tripleo-quickstart-extras?

We have a few patches from James (@slagle) to address this topic[5] and
from Arx for this issue[6].

Please feel free to share your thoughts what and where should be tested in
CI from network templates.

Thanks

[1]
https://github.com/openstack-infra/tripleo-ci/tree/821d84f34c851a79495f0205ad3c8dac928c286f/test-environments

[2]
https://github.com/openstack/tripleo-heat-templates/tree/master/ci/environments/network

[3]
https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/overcloud-deploy/tasks/pre-deploy.yml#L21-L51

[4]
https://github.com/openstack/tripleo-quickstart/blob/cf793bbb8368f89cd28214fe21adca2df48ef7f3/config/general_config/featureset001.yml#L26-L28

[5] https://review.openstack.org/#/c/531224/
https://review.openstack.org/#/c/525331
https://review.openstack.org/#/c/531221

[6] https://review.openstack.org/#/c/512225/

-- 
Best regards
Sagi Shnaidman
__
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] zuulv3 log structure and format grumblings

[Matt Riedemann]

On 1/4/2018 12:20 PM, Clark Boylan wrote:

I've pushed uphttps://review.openstack.org/531208  as a quick check that this 
is indeed the general problem, but for longer term fix I think we want to 
update our log publishing ansible roles to compress everything that isn't 
already compressed.


Yup this fixes the log formatting/color/linking stuff, thanks!

I noted that the config files still have to be downloaded, and dmsimard 
pointed out that conf/ini/filters files will have to be mapped here:


http://git.openstack.org/cgit/openstack-infra/puppet-openstackci/tree/templates/logs.vhost.erb#n24

I don't know if we can just convert everything under etc/ or not? That 
seems better to me, but I don't know anything about modifying vhost files.


--

Thanks,

Matt

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

Re: [openstack-dev] [all] propose to upgrade python kubernetes (the k8s python client) to 4.0.0 which breaks oslo.service

[Lingxian Kong]

On Tue, Jan 2, 2018 at 1:56 AM, Eyal Leshem  wrote:

> Hi ,
>
> According to https://github.com/eventlet/eventlet/issues/147 - it's looks
> that eventlet
> has issue with "multiprocessing.pool".
>
> The ThreadPool used in code that auto-generated by swagger.
>
> Possible workaround for that is to monky-patch the client library ,
> and replace the pool with greenpool.
>

Hi, leyal, I'm not very familar with eventlet, but how can I monkey patch
kubernetes python lib?
The only way I can see now is to replace oslo.service with something else,
e.g. cotyledon, avoid to use eventlet, that's a signaficant change though.
I also found this bug https://bugs.launchpad.net/taskflow/+bug/1225275 in
taskflow, they chose to not use multiprocessing module.

Any other suggestions are welcomed!


>
> If someone has better workaround, please share that with us :)
>
> btw , I don't think that should be treated as compatibility issue
> in the client python as it's an eventlet issue..
>
> Thanks ,
> leyal
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Working toward Queens feature freeze and RC1

[Eric Fried]

Folks-

>> - NRP affordance in GET /allocation_candidates
>>    . PATCHES: -
>>    . STATUS: Not proposed
>>    . PRIORITY: Critical
>>    . OWNER: jaypipes
>>    . DESCRIPTION: In the current master branch, the placement API will
>> report allocation candidates from [(a single non-sharing provider) and
>> (sharing providers associated via aggregate with that non-sharing
>> provider)].  It needs to be enhanced to report allocation candidates
>> from [(non-sharing providers in a tree) and (sharing providers
>> associated via aggregate with any of those non-sharing providers)].
>> This is critical for two reasons: 1) Without it, NRP doesn't provide any
>> interesting use cases; and 2) It is prerequisite to the remainder of the
>> Queens NRP work, listed below.
>>    . ACTION: Jay to sling some code
> 
> Just as an aside... while I'm currently starting this work, until the
> virt drivers and eventually the generic device manager or PCI device
> manager is populating parent/child information for resource providers,
> there's nothing that will be returned in the GET /allocation_candidates
> response w.r.t. nested providers.
> 
> So, yes, it's kind of a prerequisite, but until inventory records are
> being populated from the compute nodes, the allocation candidates work
> is going to be all academic/tests.
> 
> Best,
> -jay

Agree it's more of a tangled web than a linear sequence.  My thought was
that it doesn't make sense for virt drivers to expose their inventory in
tree form until it's going to afford them some benefit.

But to that point, I did forget to mention that Xen is trying to do just
that in Queens for VGPU support.  They already have a WIP [1] which
would consume the WIPs at the top of the
ComputeDriver.update_provider_tree() series [2].

[1] https://review.openstack.org/#/c/521041/
[2] https://review.openstack.org/#/c/521685/

I also don't necessarily agree that we need PCI manager changes or a
generic device manager for this to work.  As long as the virt driver
knows how to a) expose the resources in its provider tree, b) consume
the allocation candidate coming from the scheduler, and c) create/attach
resources based on that info, those other pieces would just get in the
way.  I'm hoping the Xen VGPU use case proves that.

E
.

__
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] [castellan] Transferring ownership of secrets to another user

[Alan Bishop]

Has there been any previous discussion on providing a mechanism for
transferring ownership of a secret from one user to another?

Cinder supports the notion of transferring volume ownership to another
user, who may be in another tenant/project. However, if the volume is
encrypted it's possible (even likely) that the new owner will not be
able to access the encryption secret. The new user will have the
encryption key ID (secret ref), but may not have permission to access
the secret, let alone delete the secret should the volume be deleted
later. This issue is currently flagged as a cinder bug [1].

This is a use case where the ownership of the encryption secret should
be transferred to the new volume owner.

Alan

[1] https://bugs.launchpad.net/cinder/+bug/1735285

__
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] TripleO CI end of sprint status

[Arx Cruz]

Hello,

On January 03 we came the end of sprint using our new team structure, and
here’s the highlights.

Sprint Review:

This was a tech debt sprint, and due the holidays and mostly of the team
out, we haven't set a goal for this sprint, leaving the team free to work
on the tech debt cards, as much as the time permits.

One can see the results of the sprint via https://trello.com/c/fvLpZMF6/

Tripleo CI community meeting


   - Promotion issues due mistral
   -


  
http://lists.openstack.org/pipermail/openstack-dev/2018-January/125935.html
  

  -

  The plan (from Emilien's email)
  -

 Carry Steve's patch in Mistral distgit:
 -

https://review.rdoproject.org/r/#/c/11140/ - DONE
-

 Remove featureset010 from promotion requirements - DONE
 -

 Once we have a promotion, we'll be able to land
 https://review.openstack.org/#/c/530783/ - IN PROGRESS
 -

 Once https://review.openstack.org/#/c/530783/ is landed, and the
 upstream patch is landed, revert
 https://review.rdoproject.org/r/#/c/11140/ (otherwise RDO will
 become inconsistent) and failing to build on master)
 -

 Re-add featureset010 in promotion requirements (revert
 https://review.rdoproject.org/r/#/c/11142) so we'll catch the
 issue next time.
 -

 Landed in current-tripleo because we don't have voting in
 multinode job and scenario 001, 002 and 003 were non voting
 -

   Scenario jobs not voting due timeouts
   -


  
http://lists.openstack.org/pipermail/openstack-dev/2018-January/125935.html
  -

   Which scenario / services we care about
   -

  We need an investigation to determine what we want to test in our
  scenario jobs, and what we don't, in order to release resources and focus
  our work on
  -

   Graphite report status
   -

  Working on grafana
  -

  Initially focused on OVB jobs


Ruck and Rover

What is Ruck and Rover

One person in our team is designated Ruck and another Rover, one is
responsible to monitoring the CI, checking for failures, opening bugs,
participate on meetings, and this is your focal point to any CI issues. The
other person, is responsible to work on these bugs, fix problems and the
rest of the team are focused on the sprint. For more information about our
structure, check [1]

List of bugs that Ruck and Rover were working on:


   -

   https://bugs.launchpad.net/tripleo/+bug/1736113
   CI: newton promotion fails because no stable/newton branch in aodh
   -

   https://bugs.launchpad.net/tripleo/+bug/1740940
   Tempest test on Ocata failing with Error: No valid Host was found
   -

   https://bugs.launchpad.net/tripleo/+bug/1740934 Tracker Bug: Tempest
   fails with packaging error - python-oslo-db-tests
   -

   https://bugs.launchpad.net/tripleo/+bug/1739661 Tracker Bug:
   Intermittent failures creating OVB stacks on RDO Cloud since upgrade  (**
   would like to close this bug - tenant has been cleaned up and is working)
   -

   https://bugs.launchpad.net/tripleo/+bug/1739639 ci.centos gate are
   failing with THT default change


We also have our new Ruck and Rover for this week:


   -

   Ruck
   -

  Arx Cruz - arxcruz|ruck
  -

   Rover
   -

  Gabrielle Cerami - panda|rover


If you have any questions and/or suggestions, please contact us

[1] https://review.openstack.org/#/c/509280/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Working toward Queens feature freeze and RC1

[Jay Pipes]

On 01/04/2018 01:38 PM, Eric Fried wrote:

Matt, et al-


* Nested resource providers: I'm going to need someone closer to this
work like Jay or Eric to provide an update on where things are at in the
series of changes and what absolutely needs to get done. I have
personally found it hard to track what the main focus items are for the
nested resource providers / traits / granular resource provider request
changes so I need someone to summarize and lay out the review goals for
the next two weeks.



Overall goals for nested resource providers in Queens:
(A) Virt drivers should be able to start expressing resource inventory
as a hierarchy, including traits, and have that understood by the
resource tracker and scheduler.
(B) Ops should be able to create flavors requesting resources with
traits, including e.g. same-class resources with different traits.

Whereas many big pieces of the framework are merged:

- Placement-side API changes giving providers parents/roots, allowing
tree representation and querying.
- A rudimentary ProviderTree class on the compute side for
representation of tree structure and inventory; and basic usage thereof
by the report client.
- Traits affordance in the placement API.

...we're still missing the following pieces that actually enable those
goals:

- NRP affordance in GET /allocation_candidates
   . PATCHES: -
   . STATUS: Not proposed
   . PRIORITY: Critical
   . OWNER: jaypipes
   . DESCRIPTION: In the current master branch, the placement API will
report allocation candidates from [(a single non-sharing provider) and
(sharing providers associated via aggregate with that non-sharing
provider)].  It needs to be enhanced to report allocation candidates
from [(non-sharing providers in a tree) and (sharing providers
associated via aggregate with any of those non-sharing providers)].
This is critical for two reasons: 1) Without it, NRP doesn't provide any
interesting use cases; and 2) It is prerequisite to the remainder of the
Queens NRP work, listed below.
   . ACTION: Jay to sling some code


Just as an aside... while I'm currently starting this work, until the 
virt drivers and eventually the generic device manager or PCI device 
manager is populating parent/child information for resource providers, 
there's nothing that will be returned in the GET /allocation_candidates 
response w.r.t. nested providers.


So, yes, it's kind of a prerequisite, but until inventory records are 
being populated from the compute nodes, the allocation candidates work 
is going to be all academic/tests.


Best,
-jay


- Granular Resource Requests
   . PATCHES:
Placement side: https://review.openstack.org/#/c/517757/
Report client side: https://review.openstack.org/#/c/515811/
   . STATUS: WIP, blocked on the above
   . PRIORITY: High
   . OWNER: efried
   . DESCRIPTION: Ability to request separate groupings of resources from
GET /allocation_candidates via flavor extra specs.  The groundwork
(ability to parse flavors, construct querystrings, parse querystrings,
etc.) has already merged.  The remaining patches need to do the
appropriate join-fu in a new placement microversion; and flip the switch
to send flavor-parsed request groupings from report client.  The former
needs to be able to make use of NRP affordance in GET
/allocation_candidates, so is blocked on the above work item.  The
latter subsumes parsing of traits from flavors (the non-granular part of
which actually got a separate blueprint, request-traits-in-nova).
   . ACTION: Wait for the above

- ComputeDriver.update_provider_tree()
   . PATCHES: Series starting at https://review.openstack.org/#/c/521685/
   . STATUS: Bottom ready for core reviews; top WIP.
   . PRIORITY: ?
   . OWNER: efried
   . DESCRIPTION: This is the next phase in the evolution of compute
driver inventory reporting (get_available_resource => get_inventory =>
update_provider_tree).  The series includes a bunch of enabling
groundwork in SchedulerReportClient and ProviderTree.
   . ACTION: Reviews on the bottom (core reviewers); address
comments/issues in the middle (efried); finish WIPs on top (efried).
Also write up a mini-spec describing this piece in more detail (efried).

Thanks,
Eric (efried)
.

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



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

Re: [openstack-dev] [Ironic] Removal of tempest plugin code from openstack/ironic & openstack/ironic-inspector

[John Villalovos]

Note: I am proposing in the next Ironic meeting (
https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting )
that we move forward on removing the tempest plugin code from
openstack/ironic and openstack/ironic-inspector. It will have been over
three weeks since the initial email in this thread (15-Dec-2017) about
removing the code.

Thanks,
John

On Fri, Dec 15, 2017 at 7:27 AM, John Villalovos  wrote:

> I wanted to send out a note to any 3rd Party CI or other users of the
> tempest plugin code inside either openstack/ironic or
> openstack/ironic-inspector. That code has been migrated to the
> openstack/ironic-inspector-plugin repository. We have been busily (
> https://review.openstack.org/#/q/topic:ironic-tempest-plugin ) migrating
> all of the projects to use this new repository.
>
> If you have a 3rd Party CI or something else that is depending on the
> tempest plugin code please migrate it to use openstack/ironic-tempest-
> plugin.
>
> We plan to remove the tempest plugin code on Tuesday 19-Dec-2017 from
> openstack/ironic and openstack/ironic-tempest-plugin. And then after that
> doing backports of those changes to the stable branches.
>
> openstack/ironic Removal patch
> https://review.openstack.org/527733
>
> openstack/ironic-inspector Removal patch
> https://review.openstack.org/527743
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Working toward Queens feature freeze and RC1

[Eric Fried]

Matt, et al-

> * Nested resource providers: I'm going to need someone closer to this
> work like Jay or Eric to provide an update on where things are at in the
> series of changes and what absolutely needs to get done. I have
> personally found it hard to track what the main focus items are for the
> nested resource providers / traits / granular resource provider request
> changes so I need someone to summarize and lay out the review goals for
> the next two weeks.


Overall goals for nested resource providers in Queens:
(A) Virt drivers should be able to start expressing resource inventory
as a hierarchy, including traits, and have that understood by the
resource tracker and scheduler.
(B) Ops should be able to create flavors requesting resources with
traits, including e.g. same-class resources with different traits.

Whereas many big pieces of the framework are merged:

- Placement-side API changes giving providers parents/roots, allowing
tree representation and querying.
- A rudimentary ProviderTree class on the compute side for
representation of tree structure and inventory; and basic usage thereof
by the report client.
- Traits affordance in the placement API.

...we're still missing the following pieces that actually enable those
goals:

- NRP affordance in GET /allocation_candidates
  . PATCHES: -
  . STATUS: Not proposed
  . PRIORITY: Critical
  . OWNER: jaypipes
  . DESCRIPTION: In the current master branch, the placement API will
report allocation candidates from [(a single non-sharing provider) and
(sharing providers associated via aggregate with that non-sharing
provider)].  It needs to be enhanced to report allocation candidates
from [(non-sharing providers in a tree) and (sharing providers
associated via aggregate with any of those non-sharing providers)].
This is critical for two reasons: 1) Without it, NRP doesn't provide any
interesting use cases; and 2) It is prerequisite to the remainder of the
Queens NRP work, listed below.
  . ACTION: Jay to sling some code

- Granular Resource Requests
  . PATCHES:
Placement side: https://review.openstack.org/#/c/517757/
Report client side: https://review.openstack.org/#/c/515811/
  . STATUS: WIP, blocked on the above
  . PRIORITY: High
  . OWNER: efried
  . DESCRIPTION: Ability to request separate groupings of resources from
GET /allocation_candidates via flavor extra specs.  The groundwork
(ability to parse flavors, construct querystrings, parse querystrings,
etc.) has already merged.  The remaining patches need to do the
appropriate join-fu in a new placement microversion; and flip the switch
to send flavor-parsed request groupings from report client.  The former
needs to be able to make use of NRP affordance in GET
/allocation_candidates, so is blocked on the above work item.  The
latter subsumes parsing of traits from flavors (the non-granular part of
which actually got a separate blueprint, request-traits-in-nova).
  . ACTION: Wait for the above

- ComputeDriver.update_provider_tree()
  . PATCHES: Series starting at https://review.openstack.org/#/c/521685/
  . STATUS: Bottom ready for core reviews; top WIP.
  . PRIORITY: ?
  . OWNER: efried
  . DESCRIPTION: This is the next phase in the evolution of compute
driver inventory reporting (get_available_resource => get_inventory =>
update_provider_tree).  The series includes a bunch of enabling
groundwork in SchedulerReportClient and ProviderTree.
  . ACTION: Reviews on the bottom (core reviewers); address
comments/issues in the middle (efried); finish WIPs on top (efried).
Also write up a mini-spec describing this piece in more detail (efried).

Thanks,
Eric (efried)
.

__
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] zuulv3 log structure and format grumblings

[Clark Boylan]

On Thu, Jan 4, 2018, at 6:46 AM, Matt Riedemann wrote:
> I've talked to a few people on the infra team about this but I'm not 
> sure what is temporary and transitional and what is permanent and needs 
> to be fixed, and how to fix it.
> 
> The main issue is for newer jobs like tempest-full, the logs are under 
> controller/logs/ and we lose the log analyze formatting for color, being 
> able to filter on log level, and being able to link directly to a line 
> in the logs.
> 
> Should things be like logs/controller/* instead? If not, can someone 
> point me to where the log analyze stuff runs so I can see if we need to 
> adjust a path regex for the new structure?

I don't think that is necessary, instead the next item you noticed is related 
to the issue.

> 
> The other thing is zipped up files further down the directory structure 
> now have to be downloaded, like the config files:
> 
> http://logs.openstack.org/69/530969/1/check/tempest-full/223c175/controller/logs/etc/nova/

The issue is that the wsgi os-loganalyze application is only applied to .txt 
log files if they are also gzipped:
https://git.openstack.org/cgit/openstack-infra/puppet-openstackci/tree/templates/logs.vhost.erb#n95

As you've noticed the new job processes log files differently. In the case of 
etc contents they are now zipped when they weren't before and in the case of 
the service logs themselves are no longer gzipped when they were gzipped before.

So if we want os-loganalyze to annotate these log files they should be gzipped 
by the job before getting copied to the log server (this also helps quite a bit 
with disk usage on the log server itself so is a good idea regardless).

> 
> I think that's part of devstack-gate's post-test host cleanup routine 
> where it modifies gz files so they can be viewed in the browser.

It was, but this new job does not use devstack-gate at all, there is only 
devstack + job config. Fixes for this will need to be applied to the new job 
itself rather than to devstack-gate.

I've pushed up https://review.openstack.org/531208 as a quick check that this 
is indeed the general problem, but for longer term fix I think we want to 
update our log publishing ansible roles to compress everything that isn't 
already compressed.

> 
> Please let me know if there is something I can help with here because I 
> really want to get the formatting back to help with debugging CI issues 
> and I've taken for granted how nice things were for oh these many years.

Please check that the above change results in the os-loganalyze behavior that 
you expect and if adventurous you can help us updating the generic publishing 
role.

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] [openstack-ansible] problems with bringing up openstack in AIO flavor with OVS

[Markos Chandras]

Hello,

On 04/01/18 10:29, Periyasamy Palanisamy wrote:
> Hi OSA Experts,
> 
>  
> 
> I’m trying to bring up openstack using openstack-ansible in AIO flavor
> by having neutron ml2 plugin set to ovs.
> 
> OSA is being executed from OPNFV XCI deployer with attached
> openstack_user_config and user_variables*.yml files.
> 

Would it be possible to try and reproduce it with the openstack-ansible
master branch? That will make our lives easier since we could eliminate
all the XCI specific layers.

-- 
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

__
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] [all][api] POST /api-sig/news

[michael mccune]

Greetings OpenStack community,

Happy new year to all and welcome to the first API-SIG meeting of 2018. 
As the SIG is ramping back up after the holiday break we had a few 
topics to kick off the new year and get the ball rolling.


The SIG is working to complete our year in review report that will be 
collected and distributed by the OpenStack foundation. Without spoiling 
the report, 2017 was a year of steady progress for the SIG with several 
efforts aimed at improving interoperability and expanding the 
inclusiveness of the group.


Graham Hayes(mugsie) shared his in-progress work[7][8] towards 
generating machine readable output for API schemas. This is a topic that 
the SIG has studied in the past and that continues to generate interest 
from the community. At the core of this issue is the idea that if a 
project can provide API schemas in a common format with their 
documentation then the job of SDK implementors and other integrators 
will be greatly eased. If you have thoughts or opinions on this topic, 
please review mugsie's proposals and add your input.


Monty Taylor(mordred) has been investigating how pagination is 
implemented across the OpenStack ecosystem. It appears that there are 
several differing implementations that exist and this is causing some 
friction in the SDK development process. Although there is already a 
guideline about pagination, the SIG is examining how best they can help 
projects move towards consistency in this area and will continue to 
discuss solutions in the next meeting.



* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for 
changes over time. If you find something that's not quite right, submit 
a patch [6] to fix it.
* Have you done something for which you think guidance would have made 
things easier but couldn't find any? Submit a patch and help others [6].


# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and 
service discovery

  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready 
for review)

  https://review.openstack.org/444892

* WIP: Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that 
you are developing or changing, please address your concerns in an email 
to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, 
and comments to help guide the discussion of the specific challenge you 
are facing.


To learn more about the API SIG mission and the work we do, see our wiki 
page [4] and guidelines [2].


Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://review.openstack.org/#/c/524467/
[8] https://review.openstack.org/#/c/528801/


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
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] Re: About maridb 10.1 on kolla

[Marcin Juszkiewicz]

W dniu 29.12.2017 o 07:58, Jeffrey Zhang pisze:
> recently, a series patches about mariadb is pushed. Current issue is
> 
> - using different mariadb binary from different repo ( from percona,
> Mariadb official, linux distro )
> - using different version number of mariadb ( 10.0 and 10.1 )
> 
> To make life easier, some patches are pushed to unify all of these. Here
> is my thought about this
> 
> - try to bump to 10.1, which is released long time ago
> - use mariadb binary provided by linux disto as much as possible
> 
> So here is plan
> 
> - trying to upgrade to mariadb 10.1 [0][1]
> - use mariadb 10.1 provided by RDO on redhat family distro [2]
> - use mariadb 10.0 provided by UCA on ubuntu 
>   - it is told that, it not work as excepted [3]
>   - if this does not work. we can upgrade to mariadb 10.1 provides by
>     mariadb official on ubuntu.
> - use mariadb 10.1 provided by os repo on Debian.

How we are with testing/merging?

For Debian to be deployable we need 529199 in images as rest of changes
are kolla-ansible and can be cherry-picked before deployment.


> [0] https://review.openstack.org/#/c/529505/ - fix kolla-ansible for
> mariadb 10.1

merged

> [1] https://review.openstack.org/#/c/529199/ - Fix MariaDB bootstrap for 10.1 
> version
> [2] https://review.openstack.org/#/c/468632/ - Consume RDO packaged mariadb 
> version

> [3] https://review.openstack.org/#/c/426953/ - Revert "Removed percona
> from ubuntu repos"

merged

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

Re: [openstack-dev] [api] APIs schema consumption discussion

[Graham Hayes]

On 22/11/17 20:04, Graham Hayes wrote:



> When I was talking to Gil about it, I suggested writing a new sphinx /
> docutils formatter. I am not sure how feasible it would be, but it could
> be possible (as sphinx has the whole page tree in memory when writing it
> out, we may be able to output it in some sort of structured format.
> 
> I would be hesitant to change how we write docs - this change took long
> enough to get in place, and the ability to add / remove bits to suit
> different projects is a good thing. Pages like [1] would be hard to do
> in a standard machine readable format, and I think they definitely make
> the docs better.
> 
> - Graham
> 
> 1 - https://developer.openstack.org/api-ref/compute/#servers-servers
> 
> 

Ok, I have done a quick (read: very rough and hacky) prototype of the
formatter here [1]

It uses the sphinx formatter plugin system, and reads from what we
already have in the api-ref/* folder.

It outputs [2] yaml that describes each endpoint, and the fields in the
request / response.

If there is interest, I can clean up the patch, and look at supporting
microversions.

1 - https://review.openstack.org/#/c/528801/
2 - http://paste.openstack.org/show/629241/

- Graham

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



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] [QA] No QA meetings until next year

[Andrea Frittoli]

Dear all,

The first QA meeting of the year will be next week.

Andrea Frittoli

On Wed, 20 Dec 2017, 3:56 pm Andrea Frittoli, 
wrote:

> Dear all,
>
> due to the holiday season, there will be no QA meetings until 2018.
>
> Andrea Frittoli (andreaf)
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [os-api-ref][doc] Adding openstack-doc-core to os-api-ref

[Graham Hayes]

On 04/01/18 15:39, Stephen Finucane wrote:
> I'm not sure what the procedure for this is but here goes.
> 
> I've noticed that the 'os-api-ref' project seems to have its own group
> of cores [1], many of whom are no longer working on OpenStack (at
> least, not full-time), and has a handful of open patches against it
> [2]. Since the doc team has recently changed its scope from writing
> documentation to enabling individual projects to maintain their own
> docs, we've become mainly responsible for projects like 'openstack-doc-
> theme'. Given that the 'os-api-ref' project is a Sphinx thing required
> for multiple OpenStack projects, it seems like something that
> could/should fall into the doc team's remit.
> 
> I'd like to move this project into the remit of the 'openstack-doc-
> core' team, by way of removing the 'os-api-ref-core' group or adding
> 'openstack-doc-core' to the list of included groups. In both cases,
> existing active cores will be retained. Do any of the existing 'os-api-
> ref' cores have any objections to this?

No objection from me

> Stephen
> 
> PS: I'm not sure how this affects things from a release management
> perspective. Are there PTLs for these sorts of projects?

It does seem like a docs tooling thing, so maybe moving it to the docs
project umbrella might be an idea?

> [1] https://review.openstack.org/#/admin/groups/1391,members
> [2] https://review.openstack.org/#/q/project:openstack/os-api-ref+statu
> s:open
> 
> __
> 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
> 



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] [os-api-ref][doc] Adding openstack-doc-core to os-api-ref

[Stephen Finucane]

I'm not sure what the procedure for this is but here goes.

I've noticed that the 'os-api-ref' project seems to have its own group
of cores [1], many of whom are no longer working on OpenStack (at
least, not full-time), and has a handful of open patches against it
[2]. Since the doc team has recently changed its scope from writing
documentation to enabling individual projects to maintain their own
docs, we've become mainly responsible for projects like 'openstack-doc-
theme'. Given that the 'os-api-ref' project is a Sphinx thing required
for multiple OpenStack projects, it seems like something that
could/should fall into the doc team's remit.

I'd like to move this project into the remit of the 'openstack-doc-
core' team, by way of removing the 'os-api-ref-core' group or adding
'openstack-doc-core' to the list of included groups. In both cases,
existing active cores will be retained. Do any of the existing 'os-api-
ref' cores have any objections to this?

Stephen

PS: I'm not sure how this affects things from a release management
perspective. Are there PTLs for these sorts of projects?

[1] https://review.openstack.org/#/admin/groups/1391,members
[2] https://review.openstack.org/#/q/project:openstack/os-api-ref+statu
s:open

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

Re: [openstack-dev] [tripleo] containers-multinode is broken, what's our plan

[Ben Nemec]

This is a situation where having temprevert/pin/cherrypick functionality 
again would have been really helpful.  I realize that doesn't help in 
the immediate circumstance, but it's something to consider for the future.


On 01/02/2018 10:05 PM, Emilien Macchi wrote:

Mistral broke us with https://review.openstack.org/#/c/506185/ and we
had a promotion yesterday so now our CI deploy Mistral with this
patch.
It breaks some Mistral actions, including the ones needed by
config-download (in featureset010).

Steve has a fix: https://review.openstack.org/#/c/530781 but there is
no core review yet so we decided to proceed this way:

1) Carry Steve's patch in Mistral distgit:
https://review.rdoproject.org/r/#/c/11140/ - DONE
2) Remove featureset010 from promotion requirements - DONE
3) Once we have a promotion, we'll be able to land
https://review.openstack.org/#/c/530783/ - IN PROGRESS
4) Once https://review.openstack.org/#/c/530783/ is landed, and the
upstream patch is landed, revert
https://review.rdoproject.org/r/#/c/11140/ (otherwise RDO will become
inconsistent) and failing to build on master)
5) Re-add featureset010 in promotion requirements (revert
https://review.rdoproject.org/r/#/c/11142) so we'll catch the issue
next time.

Thanks,



__
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] zuulv3 log structure and format grumblings

[Matt Riedemann]

I've talked to a few people on the infra team about this but I'm not 
sure what is temporary and transitional and what is permanent and needs 
to be fixed, and how to fix it.


The main issue is for newer jobs like tempest-full, the logs are under 
controller/logs/ and we lose the log analyze formatting for color, being 
able to filter on log level, and being able to link directly to a line 
in the logs.


Should things be like logs/controller/* instead? If not, can someone 
point me to where the log analyze stuff runs so I can see if we need to 
adjust a path regex for the new structure?


The other thing is zipped up files further down the directory structure 
now have to be downloaded, like the config files:


http://logs.openstack.org/69/530969/1/check/tempest-full/223c175/controller/logs/etc/nova/

I think that's part of devstack-gate's post-test host cleanup routine 
where it modifies gz files so they can be viewed in the browser.


Please let me know if there is something I can help with here because I 
really want to get the formatting back to help with debugging CI issues 
and I've taken for granted how nice things were for oh these many years.


--

Thanks,

Matt

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

Re: [openstack-dev] [oslo][oslo.log]Error will be occurred if watch_log_file option is true

[Doug Hellmann]

Excerpts from Rikimaru Honjo's message of 2018-01-04 18:22:26 +0900:
> Hello,
> 
> The below bug was reported in Masakari's Launchpad.
> I think that this bug was caused by oslo.log.
> (And, the root cause is a bug of pyinotify using by oslo.log. The detail is
> written in the bug report.)
> 
> * masakari-api failed to launch due to setting of watch_log_file and log_file
>https://bugs.launchpad.net/masakari/+bug/1740111
> 
> There is a possibility that this bug will affects all openstack components 
> using oslo.log.
> (But, the processes working with uwsgi[1] wasn't affected when I tried to 
> reproduce.
> I haven't solved the reason of this yet...)
> 
> Could you help us?
> And, what should we do...?
> 
> [1]
> e.g. nova-api, cinder-api, keystone...
> 
> Best regards,

The bug is in pyinotify. According to the git repo [1] that project
was last updated in June of 2015.  I recommend we move off of
pyinotify entirely, since it appears to be unmaintained.

If there is another library to do the same thing we should switch
to it (there seem to be lots of options [2]). If there is no viable
replacement or fork, we should deprecate that log watching feature
(and anything else for which we use pyinotify) and remove it ASAP.

We'll need a volunteer to do the evaluation and update oslo.log.

Doug

[1] https://github.com/seb-m/pyinotify
[2] https://pypi.python.org/pypi?%3Aaction=search&term=inotify&submit=search

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

[openstack-dev] [qa] [api] [all] use gabbi and tempest with just YAML

[Chris Dent]

(this is a request for assistance and verification)

Back in July[1] I wrote about some experiments with using gabbi[2]
with tempest. In that message I said:

At some point it may be interesting to explore the option of
"put a gabbit in dir X" and tempest will run it for you.

I've finally started working on that, and have a pull request to
gabbi-tempest[3] with a WIP that allows you to do this:

GABBI_TEMPEST_PATH=/path/one:/path/two tempest run --regex gabbi

Within /path/one and /path/two (or whatever, or however many, paths
you want) are yaml files containg tests in the gabbi format. If the
env variable is not set a 'gabbits' directory in the current working
dir is checked.

This makes it possible for projects to make purely api-driven (and
"clientless"[4]) integration tests by requiring the gabbi-tempest
plugin and writing some YAML.

The gabbi-tempest plugin is responsible for getting authentication
and service catalog information (using standard tempest calls) from
keystone and creating a suite of environment variables (such as
PLACEMENT_SERVICE and COMPUTE_BASE).

I have a sample file[5] that confirms resource provider and
allocation handling across the process of booting a single server.
It demonstrates some of the potential. Don't be too scared by the
noisy YAML anchors at the top, that's just an experiment to see what
can be done to manage URLs without having to know URLs.

I'm pretty sure this can be useful for integration tests, cloud
verification, and interop validation, but I'm suspiciously biased in
favor of gabbi from years of positive use, so would like some
additional input and feedback.

Gabbi is already very valuable for functional tests. When 
integrating with tempest it gets the discovery power that tempest

provides and things like FLAVOR_REF, both useful in integration or
real cloud scenarios.

Thanks for your attention.

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-July/120369.html
[2] https://gabbi.readthedocs.org/
[3] https://github.com/cdent/gabbi-tempest/pull/2
[4] A bad term, in much the same way serverless is. Of course there
is a client, but in this case the client is gabbi making raw http
requests rather than a library which might impose its own
expectations and obfuscations on the interactions.
[5] 
https://github.com/cdent/gabbi-tempest/blob/d570f5da52ba80b6d4b75b18e10897c49e9b6aed/samples/multi.yaml

--
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] [kolla] LXD driver in nova

[Mark Baker]

There is a python nova-lxd binary (.deb) as part of Ubuntu OpenStack. To
enable this a good place to start is James Page's blog:

https://javacruft.wordpress.com/2017/09/01/openstack-pike-for-ubuntu-16-04-lts/

The cloud archive wiki page is also worth checking:

https://wiki.ubuntu.com/OpenStack/CloudArchive





Best Regards


Mark Baker

On 4 January 2018 at 10:52, Eduardo Gonzalez  wrote:

> Hi João,
>
> It would be possible but there is not any  container image with the
> nova-lxc code on it at the moment. (No binary rpm in RDO neither)
>
> Only supported drivers (for now) are: kvm, qemu, vmware and hyperv (xen in
> progress).
>
> Feel free to add lxd as driver into the project :)
>
> Regards
>
> 2018-01-04 11:42 GMT+01:00 João Paulo Sá da Silva <
> joao-sa-si...@alticelabs.com>:
>
>> Hello!
>>
>>
>>
>> Is it possible to use the LXD driver for nova compute instead of the KVM?
>>
>>
>>
>> Kind regards,
>>
>> João
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] [watcher] January holidays

[Alexander Chadin]

Hi Watcher team.

I’m on vacation till January 9. Our next weekly meeting is scheduled on January 
10, I’d be happy to see you all there:)


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

Re: [openstack-dev] [kolla] LXD driver in nova

[Eduardo Gonzalez]

Hi João,

It would be possible but there is not any  container image with the
nova-lxc code on it at the moment. (No binary rpm in RDO neither)

Only supported drivers (for now) are: kvm, qemu, vmware and hyperv (xen in
progress).

Feel free to add lxd as driver into the project :)

Regards

2018-01-04 11:42 GMT+01:00 João Paulo Sá da Silva <
joao-sa-si...@alticelabs.com>:

> Hello!
>
>
>
> Is it possible to use the LXD driver for nova compute instead of the KVM?
>
>
>
> Kind regards,
>
> João
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] LXD driver in nova

[João Paulo Sá da Silva]

Hello!

Is it possible to use the LXD driver for nova compute instead of the KVM?

Kind regards,
João
__
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] [charms] evolving the ha interface type

[Liam Young]

Hi James,
I like option 2 but I think there is a problem with it. I don't
think the hacluster charm sets any data down the relation with the
principle until it has first received data from the principle. As I
understand it option 2 would change this behaviour so that hacluster
immediately sets an api-version option for the principle to consume.
The only problem is the principle does not know whether to wait for
this api-version information or not. eg when the principle is deciding
whether to json encode its data it cannot differentiate between:

a) An old version of the hacluster charm which does not support
api-version or json
b) A new version of the hacluster charm which has not set the api-version yet.

Thanks
Liam

__
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] problems with bringing up openstack in AIO flavor with OVS

[Periyasamy Palanisamy]

Hi OSA Experts,

I'm trying to bring up openstack using openstack-ansible in AIO flavor by 
having neutron ml2 plugin set to ovs.
OSA is being executed from OPNFV XCI deployer with attached 
openstack_user_config and user_variables*.yml files.
I can see installation [1] is being successful, but not able to boot nova VMs 
and VxLAN tunnel is not established between compute (vm) and neutron-agents 
container (inside the same vm).

Here are the observations:


  1.  Timeout errors occur continuously in neutron-openvswitch-agent.log of the 
compute vm. It looks like this happens while accessing rpc for agent report 
status [2] .

Increasing rpc_response_timeout to 180 sec and restarting openvswich-agent, l3, 
dhcp and neutron-server service also doesn't help.

Here is the neutron-openvswitch-agent.log [3] and neutron agent-list CLI shows 
empty output. There is no weird errors in rabbitmq log.

  1.  Nova boot fails with "The requested availability zone is not available" 
error and corresponding error logs in neutron-server.log  [4].
  2.  On the compute vm, vxlan port is not created on the br-tun bridge and 
neutron-agents container doesn't have br-tun bridge itself [5].

Please have a look and let me know if you need more details.

[1] https://paste.ubuntu.com/26318366/
[2] 
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L312.
[3] https://paste.ubuntu.com/26318305/
[4] https://paste.ubuntu.com/26318445/
[5] https://paste.ubuntu.com/26318474/

Thanks,
Periyasamy


openstack_user_config.yml
Description: openstack_user_config.yml


user_variables_os-nosdn-nofeature.yml
Description: user_variables_os-nosdn-nofeature.yml


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

[openstack-dev] [qa] Office Hours Report 2018-01-04

[Chandan kumar]

Hello,

Thanks everyone for attending QA office hour. Since It's the starting
of the year so attendance is low. We managed to triaged some bugs
opened/changed in last 14 days.

The IRC report [0] and full log [1] are available through meetbot.

**Bug Traiged Summary**
* Bug #1740194 in devstack: "Apache2 unable to start as 2 MPM modules
enabled on Fedora 27"
  Status: Confirmed, Related Review: https://review.openstack.org/#/c/527048/
  https://bugs.launchpad.net/devstack/+bug/1740194

* Bug #1740480 in devstack: "502 Proxy Error"
  Status: New, Action: Need help in traiging
  https://bugs.launchpad.net/devstack/+bug/1740480

* Bug #1740920 in devstack: "stable/newton branch does not work
because keystone does not have stable/newton branch"
  Status: Invalid
  https://bugs.launchpad.net/devstack/+bug/1740920

* Bug #1741097 in devstack: "Installing pip fails on RHEL 7.4 with SSL error"
  status: In Progress, Related Review: https://review.openstack.org/#/c/530991/
  https://bugs.launchpad.net/devstack/+bug/1741097

* Bug #1740544 in tempest: "Volume retype fails when migration occurs"
  Status: confirmed
  https://bugs.launchpad.net/tempest/+bug/1740544

* Bug #1739829 in tempest: "tempest-full job failing in stable/pike
with 404 from keystone during tempest verify-config"
  Status: Confirmed, Related Review:
https://review.openstack.org/#/c/530915/ (Needs to be backported for
stable branches)
  https://bugs.launchpad.net/tempest/+bug/1739829

* Bug #1740258 in tempest: "[scenario]/img_dir is deprecated but required"
  Status: Undecided, Action: Needs discussion
  https://bugs.launchpad.net/tempest/+bug/1740258


Links:

[0]. 
http://eavesdrop.openstack.org/meetings/qa_office_hours/2018/qa_office_hours.2018-01-04-09.02.html

[1]. 
http://eavesdrop.openstack.org/meetings/qa_office_hours/2018/qa_office_hours.2018-01-04-09.02.log.html

Thanks,

Chandan Kumar

__
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] [oslo][oslo.log]Error will be occurred if watch_log_file option is true

[Rikimaru Honjo]

Hello,

The below bug was reported in Masakari's Launchpad.
I think that this bug was caused by oslo.log.
(And, the root cause is a bug of pyinotify using by oslo.log. The detail is
written in the bug report.)

* masakari-api failed to launch due to setting of watch_log_file and log_file
  https://bugs.launchpad.net/masakari/+bug/1740111

There is a possibility that this bug will affects all openstack components 
using oslo.log.
(But, the processes working with uwsgi[1] wasn't affected when I tried to 
reproduce.
I haven't solved the reason of this yet...)

Could you help us?
And, what should we do...?

[1]
e.g. nova-api, cinder-api, keystone...

Best regards,
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikim...@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-dev] [ironic-inspector] Resigning my core-reviewer duties

[Dmitry Tantsur]

On 01/03/2018 04:24 PM, milanisko k wrote:

Folks,

as announced already on the Ironic upstream meeting, I'm hereby resigning my 
core-reviewer duties. I've changed my downstream occupation recently and I won't 
be able to keep up anymore.


As I said many times, I'm really sad to hear it, but I'm glad that you've found 
new cool challenges :)


I have removed your rights. I've also done a similar change to Yuiko, who is 
apparently no longer active in the community. Thanks both for your incredible 
contributions that allowed ironic-inspector to be what it is now!




Thank you all, I really enjoyed collaborating with the wonderful Ironic 
community!

Best regards,
milan


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




__
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