[openstack-dev] [kolla] stable-policy tag has been removed in kolla

[Jeffrey Zhang]

This has already happened[1] based on talks during Sydney summit[0]. But
seems
it is not noticed by some guys.

Even though the tag is merged, we should still follow rule during backport
patches
to stable branches. The rules, I think, should be

- do not break upgrade from y-1 or z-1 stream
- API should be still backward compatible, and before removing any feature,
we
  still need one more cycle to mark it as deprecated. and then remove it
 during next cycle.

On the other hand, some bp-like patches like this[2] could be backported to
stable
branches. Since it won't break anything.

[0] https://etherpad.openstack.org/p/SYD-stable-policy
[1] https://review.openstack.org/#/c/519685/
[2] https://review.openstack.org/557729


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

Re: [openstack-dev] [tripleo] The Weekly Owl - 16th Edition

[Wesley Hayutin]

On Tue, 10 Apr 2018 at 19:24 Emilien Macchi  wrote:

> Note: this is the sixteenth 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-April/129035.html
>
> +-+
> | General announcements |
> +-+
>
> +--> Rocky milestone 1 is next week! Please update your blueprints status
> accordingly)
>
> +--+
> | Continuous Integration |
> +--+
>
> +--> Rover is Arx and Ruck is Rafael. Please let them know any new CI
> issue.
> +--> Master promotion is 5 days, Queens is 12 days, Pike is 17 days and
> Ocata is 17 days.
>

FYI.. Queens promoted today
Master promotion is 5 days, Queens is 0 days, Pike is 17 days and Ocata is
17

Thanks Emilien!


> +--> Efforts around a simple "keystone-only" CI job across all branches.
> +--> Good progress on running Tempest for undercloud jobs, also tempest
> containerization.
> +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting and
> https://goo.gl/D4WuBP
>
> +-+
> | Upgrades |
> +-+
>
> +--> Progress on FFU CLI in tripleoclient and FFU/Ceph as well.
> +--> Work on CI jobs for undercloud upgrades and containerized undercloud
> upgrades.
> +--> Need reviews, see etherpad
> +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status
>
> +---+
> | Containers |
> +---+
>
> +--> Good progress on upgrades, now working on THT tasks to upgrade
> undercloud services
> +--> Focusing on UX problems: logs, permissions, directories, complete
> deployment message
> +--> Container workflow is still work in progress, and needed to make
> progress on CI / container updates
> +--> We had to revert containerized undercloud testing on fs010 :
> https://bugs.launchpad.net/tripleo/+bug/1762422
> +--> More:
> https://etherpad.openstack.org/p/tripleo-containers-squad-status
>
> +--+
> | config-download |
> +--+
>
> +--> Moving to config-download by default is imminent.
> +--> ceph/octavia/skydive migration is wip.
> +--> Inventory improvements in progress.
> +--> Polishing tripleo-common deploy_plan and messaging patches to get
> correct deployment state tracking.
> +--> UI work is work in progress.
> +--> More:
> https://etherpad.openstack.org/p/tripleo-config-download-squad-status
>
> +--+
> | Integration |
> +--+
>
> +--> Migrate to new ceph-ansible container images naming style.
> +--> Config-download transition is still ongoing.
> +--> More:
> https://etherpad.openstack.org/p/tripleo-integration-squad-status
>
> +-+
> | UI/CLI |
> +-+
>
> +--> Efforts on config-download integration
> +--> Investigating undeploy_plan workflow in tripleo-common
> +--> Maintaining pending UI patches to be up to date with tripleo-common
> changes
> +--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status
>
> +---+
> | Validations |
> +---+
>
> +--> OpenShift on OpenStack validations in progress
> +--> Starting work on Custom validations/swift storage
> +--> 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 |
> +--+
>
> +--> Need reviews, see etherpad.
> +--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status
>
> +---+
> | Security |
> +---+
>
> +--> Last meeting's was about Public TLS by default, Limit TripleO users
> and Security Hardening.
> +--> More: https://etherpad.openstack.org/p/tripleo-security-squad
>
> ++
> | Owl fact  |
> ++
>
> Did you know owls were good hunters? Check this video:
> https://youtu.be/a68fIQzaDBY?t=39
> Don't mess with owls ;-)
>
> Thanks all for reading and 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
>
__
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] [zun] zun-api error

[Hongbin Lu]

HI Murali,

This is the guide for installing and configuring kuryr-libnetwork:
https://docs.openstack.org/kuryr-libnetwork/queens/install/ (it is for
Queens version). Several questions from me:

* Which version of Kuryr-libnetwork you installed. I asked this question
because you mentioned that you were using Pike version but Kuryr-libnetwork
doesn't have the stable/pike branch. The closest matching version is 0.2.0 (
https://github.com/openstack/kuryr-libnetwork/tree/0.2.0) which was cut for
matching the Pike integration release.
* Did you use dual stack (ipv4 & v6)? If yes, see if you were hitting this
bug: https://bugs.launchpad.net/kuryr-libnetwork/+bug/1668803

To debug further, could you provide the following information?
* The log of kuryr-libnetwork (ideally with debug model enabled).
* The output of this command "pip freeze"

Best regards,
Hongbin

On Mon, Apr 9, 2018 at 9:41 PM, Murali B  wrote:

> Hi Hongbin Lu,
>
> After I run the etcd service up and tried to create  container I see the
> below error and my container is in error state
>
> Could you please share me if I need to change any configuration in neutron
> for docker kuryer
>
> ckercfg'] find_config_file /usr/local/lib/python2.7/dist-
> packages/docker/utils/config.py:21
> 2018-04-09 16:47:44.058 41736 DEBUG docker.utils.config
> [req-0afc6b91-e50e-4a5a-a673-c2cecd6f2986 - - - - -] No config file found
> find_config_file /usr/local/lib/python2.7/dist-
> packages/docker/utils/config.py:28
> 2018-04-09 16:47:44.345 41736 ERROR zun.compute.manager
> [req-0afc6b91-e50e-4a5a-a673-c2cecd6f2986 - - - - -] Error occurred while
> calling Docker start API: Docker internal error: 500 Server Error: Internal
> Server Error ("IpamDriver.RequestAddress: Requested ip address
> {'subnet_id': u'fb768eca-8ad9-4afc-99f7-e13b9c36096e', 'ip_address':
> u'3.3.3.12'} already belongs to a bound Neutron port:
> 401a5599-2309-482e-b100-e2317c4118cf").: DockerError: Docker internal
> error: 500 Server Error: Internal Server Error ("IpamDriver.RequestAddress:
> Requested ip address {'subnet_id': u'fb768eca-8ad9-4afc-99f7-e13b9c36096e',
> 'ip_address': u'3.3.3.12'} already belongs to a bound Neutron port:
> 401a5599-2309-482e-b100-e2317c4118cf").
> 2018-04-09 16:47:44.372 41736 DEBUG oslo_concurrency.lockutils
> [req-0afc6b91-e50e-4a5a-a673-c2cecd6f2986 - - - - -] Lock
> "b861d7cc-3e18-4037-8eaf-c6d0076b02a5" released by
> "zun.compute.manager.do_container_create" :: held 5.163s inner
> /usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:285
> 2018-04-09 16:47:48.493 41610 DEBUG eventlet.wsgi.server [-] (41610)
> accepted ('10.11.142.2', 60664) server /usr/lib/python2.7/dis
>
> Thanks
> -Murali
>
> On Fri, Apr 6, 2018 at 11:00 AM, Murali B  wrote:
>
>> Hi Hongbin Lu,
>>
>> Thank you. After changing the endpoint it worked. Actually I was using
>> magnum service also. I used the service as "container" for magnum  that is
>> why its is going to 9511 instead of 9517
>> After I corrected it worked.
>>
>> Thanks
>> -Murali
>>
>> On Fri, Apr 6, 2018 at 8:45 AM, Hongbin Lu  wrote:
>>
>>> Hi Murali,
>>>
>>> It looks your zunclient was sending API requests to
>>> http://10.11.142.2:9511/v1/services , which doesn't seem to be the
>>> right API endpoint. According to the Keystone endpoint you configured, the
>>> API endpoint of Zun should be http://10.11.142.2:9517/v1/services
>>>  (it is on port 9517 instead of
>>> 9511).
>>>
>>> What confused the zunclient is the endpoint's type you configured in
>>> Keystone. Zun expects an endpoint of type "container" but it was configured
>>> to be "zun-container" in your setup. I believe the error will be resolved
>>> if you can update the Zun endpoint from type "zun-container" to type
>>> "container". Please give it a try and let us know.
>>>
>>> Best regards,
>>> Hongbin
>>>
>>> On Thu, Apr 5, 2018 at 7:27 PM, Murali B  wrote:
>>>
 Hi Hongbin,

 Thank you for your help

 As per the our discussion here is the output for my current api on
 pike. I am not sure which version of zun client  client  I should use for
 pike

 root@cluster3-2:~/python-zunclient# zun service-list
 ERROR: Not Acceptable (HTTP 406) (Request-ID:
 req-be69266e-b641-44b9-9739-0c2d050f18b3)
 root@cluster3-2:~/python-zunclient# zun --debug service-list
 DEBUG (extension:180) found extension EntryPoint.parse('vitrage-keycloak
 = vitrageclient.auth:VitrageKeycloakLoader')
 DEBUG (extension:180) found extension EntryPoint.parse('vitrage-noauth
 = vitrageclient.auth:VitrageNoAuthLoader')
 DEBUG (extension:180) found extension EntryPoint.parse('noauth =
 cinderclient.contrib.noauth:CinderNoAuthLoader')
 DEBUG (extension:180) found extension EntryPoint.parse('v2token =
 keystoneauth1.loading._plugins.identity.v2:Token')
 DEBUG (extension:180) found extension 

Re: [openstack-dev] [nova] Changes toComputeVirtAPI.wait_for_instance_event

[Chen CH Ji]

Thanks for your info ,really helpful

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Andreas Scheuring 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   04/10/2018 10:19 PM
Subject:Re: [openstack-dev] [nova] Changes
toComputeVirtAPI.wait_for_instance_event



Yes, that’s how it works!

---
Andreas Scheuring (andreas_s)



On 10. Apr 2018, at 16:05, Matt Riedemann  wrote:

On 4/9/2018 9:57 PM, Chen CH Ji wrote:
  Could you please help to share whether this kind of event is sent by
  neutron-server or neutron agent ? I searched neutron code
  from [1][2] this means the agent itself need tell neutron server the
  device(VIF) is up then neutron server will send notification
  to nova through REST API and in turn consumed by compute node?
  [1]
  
https://github.com/openstack/neutron/tree/master/neutron/notify_port_active_direct

  [2]
  
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/rpc.py#L264

I believe the neutron agent is the one that is getting (or polling) the
information from the underlying network backend when VIFs are plugged or
unplugged from a host, then route that information via RPC to the neutron
server which then sends an os-server-external-events request to the compute
REST API, which then routes the event information down to the nova-compute
host where the instance is currently running.

--

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
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=tIntFpZ0ffp-_h5CsqN1I9tv64hW2xugxBXaxDn7Z_I=z2jOgMD7B3XFoNsUHTtIO6hWKYXH-Dm4L4P0-u-oSSw=



__
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] roadmap on containers workflow

[Emilien Macchi]

Greetings,

Steve Baker and I had a quick chat today about the work that is being done
around containers workflow in Rocky cycle.

If you're not familiar with the topic, I suggest to first read the
blueprint to understand the context here:
https://blueprints.launchpad.net/tripleo/+spec/container-prepare-workflow

One of the great outcomes of this blueprint is that in Rocky, the operator
won't have to run all the "openstack overcloud container" commands to
prepare the container registry and upload the containers. Indeed, it'll be
driven by Heat and Mistral mostly.

But today our discussion extended on 2 uses-cases that we're going to
explore and find how we can address them:
1) I'm a developer and want to deploy a containerized undercloud with
customized containers (more or less related to the all-in-one discussions
on another thread [1]).
2) I'm submitting a patch in tripleo-common (let's say a workflow) and need
my patch to be tested when the undercloud is containerized (see [2] for an
excellent example).

Both cases would require additional things:
- The container registry needs to be deployed *before* actually installing
the undercloud.
- We need a tool to update containers from this registry and *before*
deploying them. We already have this tool in place in our CI for the
overcloud (see [3] and [4]). Now we need a similar thing for the undercloud.

Next steps:
- Agree that we need to deploy the container-registry before the undercloud.
- If agreed, we'll create a new Ansible role called
ansible-role-container-registry that for now will deploy exactly what we
have in TripleO, without extra feature.
- Drive the playbook runtime from tripleoclient to bootstrap the container
registry (which of course could be disabled in undercloud.conf).
- Create another Ansible role that would re-use container-check tool but
the idea is to provide a role to modify containers when needed, and we
could also control it from tripleoclient. The role would be using
the ContainerImagePrepare parameter, which Steve is working on right now.

Feedback is welcome, thanks.

[1] All-In-One thread:
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128900.html
[2] Bug report when undercloud is containeirzed
https://bugs.launchpad.net/tripleo/+bug/1762422
[3] Tool to update containers if needed:
https://github.com/imain/container-check
[4] Container-check running in TripleO CI:
https://review.openstack.org/#/c/558885/ and
https://review.openstack.org/#/c/529399/
-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [All][Elections] Candidate Proposals for TC Positions Are Now Open

[Kendall Nelson]

 Hello All!

Nominations for the Technical Committee positions (7 positions) are now
open and will remain open until 2018-04-17T23:45.

All nominations must be submitted as a text file to the openstack/election
repository as explained on the election website[1].

Please note that the name of the file should match an email address in the
foundation member profile of the candidate.

Also for TC candidates, election officials refer to the community member
profiles at [2], so please take this opportunity to ensure that your
profile contains current information.

Candidates for the Technical Committee Positions: Any Foundation individual
member can propose their candidacy for an available, directly-elected TC
seat.

The election will be held from 2018-04-23T23:59 through to
2018-04-30T23:45. The electorate are the Foundation individual members that
are also committers for one of the official teams[3] over the Pike-Queens
timeframe (22 Feb 2017 to
28 Feb 2018, as well as the extra-ATCs who are acknowledged by the TC[4].

Please see the website[5] for additional details about this election.

Please find below the timeline:

TC nomination starts @ 2018-04-10T23:59
TC nomination ends @ 2018-04-17T23:45
TC campaigning starts @ 2018-04-17T23:45
TC campaigning ends @ 2018-04-22T23:45
TC elections starts @ 2018-04-23T23:59
TC elections ends @ 2018-04-30T23:45

If you have any questions please be sure to either ask them on the mailing
list or to the elections officials[6].

Thank you,

Kendall Nelson (diablo_rojo)

[1] http://governance.openstack.org/election/#how-to-submit-your-candidacy
[2] http://www.openstack.org/community/members/
[3] https://governance.openstack.org/tc/reference/projects/
[4] https://releases.openstack.org/rocky/schedule.html#p-extra-atcs
[5] https://governance.openstack.org/election/
[6] http://governance.openstack.org/election/#election-officials
__
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] [api] Re-Reminder on the state of WSME

[Michael Johnson]

I echo Ben's question about what is the recommended replacement.

Not long ago we were advised to use WSME over the alternatives which
is why Octavia is using the WSME types and pecan extension.

Thanks,
Michael

On Mon, Apr 9, 2018 at 10:16 AM, Ben Nemec  wrote:
>
>
> On 04/09/2018 07:22 AM, Chris Dent wrote:
>>
>>
>> A little over two years ago I sent a reminder that WSME is not being
>> actively maintained:
>>
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088658.html
>>
>> Today I was reminded of this becasue a random (typo-related)
>> patchset demonstrated that the tests were no longer passing and
>> fixing them is enough of a chore that I (at least temporarily)
>> marked one test as an expected failure.o
>>
>>  https://review.openstack.org/#/c/559717/
>>
>> The following projects appear to still use WSME:
>>
>>  aodh
>>  blazar
>>  cloudkitty
>>  cloudpulse
>>  cyborg
>>  glance
>>  gluon
>>  iotronic
>>  ironic
>>  magnum
>>  mistral
>>  mogan
>>  octavia
>>  panko
>>  qinling
>>  radar
>>  ranger
>>  searchlight
>>  solum
>>  storyboard
>>  surveil
>>  terracotta
>>  watcher
>>
>> Most of these are using the 'types' handling in WSME and sometimes
>> the pecan extension, and not the (potentially broken) Flask
>> extension, so things should be stable.
>>
>> However: nobody is working on keeping WSME up to date. It is not a
>> good long term investment.
>
>
> What would be the recommended alternative, either for new work or as a
> migration path for existing projects?
>
> __
> 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] [all] Gerrit server replacement scheduled for May 2nd 2018

[Paul Belanger]

Hello from Infra.

This is our weekly reminder of the upcoming gerrit replacement.  We'll continue
to send these announcements out up until the day of the migration.

If you have any questions, please contact us in #openstack-infra.

---

It's that time again... on Wednesday, May 02, 2018 20:00 UTC, the OpenStack
Project Infrastructure team is upgrading the server which runs
review.openstack.org to Ubuntu Xenial, and that means a new virtual machine
instance with new IP addresses assigned by our service provider. The new IP
addresses will be as follows:

IPv4 -> 104.130.246.32
IPv6 -> 2001:4800:7819:103:be76:4eff:fe04:9229

They will replace these current production IP addresses:

IPv4 -> 104.130.246.91
IPv6 -> 2001:4800:7819:103:be76:4eff:fe05:8525

We understand that some users may be running from egress-filtered
networks with port 29418/tcp explicitly allowed to the current
review.openstack.org IP addresses, and so are providing this
information as far in advance as we can to allow them time to update
their firewalls accordingly.

Note that some users dealing with egress filtering may find it
easier to switch their local configuration to use Gerrit's REST API
via HTTPS instead, and the current release of git-review has support
for that workflow as well.
http://lists.openstack.org/pipermail/openstack-dev/2014-September/045385.html

We will follow up with final confirmation in subsequent announcements.

Thanks,
Paul


__
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][requirements] uncapping eventlet

[Ben Nemec]

On 04/09/2018 04:32 PM, Ben Nemec wrote:



On 04/09/2018 01:12 PM, Ben Nemec wrote:



On 04/06/2018 04:02 AM, Jens Harbott wrote:

2018-04-05 19:26 GMT+00:00 Matthew Thode :

On 18-04-05 20:11:04, Graham Hayes wrote:

On 05/04/18 16:47, Matthew Thode wrote:
eventlet-0.22.1 has been out for a while now, we should try and 
use it.

Going to be fun times.

I have a review projects can depend upon if they wish to test.
https://review.openstack.org/533021


It looks like we may have an issue with oslo.service -
https://review.openstack.org/#/c/559144/ is failing gates.

Also - what is the dance for this to get merged? It doesn't look 
like we
can merge this while oslo.service has the old requirement 
restrictions.




The dance is as follows.

0. provide review for projects to test new eventlet version
    projects using eventlet should make backwards compat code 
changes at

    this time.


But this step is currently failing. Keystone doesn't even start when
eventlet-0.22.1 is installed, because loading oslo.service fails with
its pkg definition still requiring the capped eventlet:

http://logs.openstack.org/21/533021/4/check/legacy-requirements-integration-dsvm/7f7c3a8/logs/screen-keystone.txt.gz#_Apr_05_16_11_27_748482 



So it looks like we need to have an uncapped release of oslo.service
before we can proceed here.


I've proposed a patch[1] to uncap eventlet in oslo.service, but it's 
failing the unit tests[2].  I'll look into it, but I thought I'd 
provide an update in the meantime.


Oh, the unit test failures are unrelated.  Apparently the unit tests 
have been failing in oslo.service for a while.  dims has a patch up at 
https://review.openstack.org/#/c/559831/ that looks to be addressing the 
problem, although it's also failing the unit tests. :-/


We finally got the uncap patch merged and a release request is up at 
https://review.openstack.org/560163.  Hopefully once that is in u-c 
we'll be past this issue.






1: https://review.openstack.org/559800
2: 
http://logs.openstack.org/00/559800/1/check/openstack-tox-py27/cef8fcb/job-output.txt.gz 



__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


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

Re: [openstack-dev] [tc] Proposal to start TC elections earlier

[Kendall Nelson]

Thanks Chris!

Sounds like a good plan to me. Added bonus for election officials, it
pushes things a little further back from the Summit to avoid conflict with
prep/planning.

-Kendall (diablo_rojo)

On Tue, Apr 10, 2018 at 5:17 AM Chris Dent  wrote:

>
> I've posted a review
>
>  https://review.openstack.org/#/c/560002/
>
> that suggests we do elections for the TC with a bigger gap between
> the election and summit. From the commit message:
>
>  The existing 3 weeks prior to summit target for TC elections can
>  be problematic for travel planning for candidates who might only
>  go to summit if they win their election, or might plan a
>  different length of trip depending on their role(s) in the
>  community. This change makes the target for the election to be
>  six weeks prior to summit to ease that planning.
>
>  In addition to helping with travel concerns, it also means that
>  any newly elected TC members will be more involved in planning
>  for the forum at the summit.
>
>  If approved this change would go in effect for the second
>  election in 2018. The first election of 2018 is already
>  scheduled.
>
> If you have opinions on this please comment here or on the review.
>
>
> --
> 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
>
__
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 - 16th Edition

[Emilien Macchi]

Note: this is the sixteenth 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-April/129035.html

+-+
| General announcements |
+-+

+--> Rocky milestone 1 is next week! Please update your blueprints status
accordingly)

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

+--> Rover is Arx and Ruck is Rafael. Please let them know any new CI issue.
+--> Master promotion is 5 days, Queens is 12 days, Pike is 17 days and
Ocata is 17 days.
+--> Efforts around a simple "keystone-only" CI job across all branches.
+--> Good progress on running Tempest for undercloud jobs, also tempest
containerization.
+--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting and
https://goo.gl/D4WuBP

+-+
| Upgrades |
+-+

+--> Progress on FFU CLI in tripleoclient and FFU/Ceph as well.
+--> Work on CI jobs for undercloud upgrades and containerized undercloud
upgrades.
+--> Need reviews, see etherpad
+--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status

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

+--> Good progress on upgrades, now working on THT tasks to upgrade
undercloud services
+--> Focusing on UX problems: logs, permissions, directories, complete
deployment message
+--> Container workflow is still work in progress, and needed to make
progress on CI / container updates
+--> We had to revert containerized undercloud testing on fs010 :
https://bugs.launchpad.net/tripleo/+bug/1762422
+--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status

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

+--> Moving to config-download by default is imminent.
+--> ceph/octavia/skydive migration is wip.
+--> Inventory improvements in progress.
+--> Polishing tripleo-common deploy_plan and messaging patches to get
correct deployment state tracking.
+--> UI work is work in progress.
+--> More: https://etherpad.openstack.org/p/tripleo-config-
download-squad-status

+--+
| Integration |
+--+

+--> Migrate to new ceph-ansible container images naming style.
+--> Config-download transition is still ongoing.
+--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status

+-+
| UI/CLI |
+-+

+--> Efforts on config-download integration
+--> Investigating undeploy_plan workflow in tripleo-common
+--> Maintaining pending UI patches to be up to date with tripleo-common
changes
+--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status

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

+--> OpenShift on OpenStack validations in progress
+--> Starting work on Custom validations/swift storage
+--> 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 |
+--+

+--> Need reviews, see etherpad.
+--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status

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

+--> Last meeting's was about Public TLS by default, Limit TripleO users
and Security Hardening.
+--> More: https://etherpad.openstack.org/p/tripleo-security-squad

++
| Owl fact  |
++

Did you know owls were good hunters? Check this video:
https://youtu.be/a68fIQzaDBY?t=39
Don't mess with owls ;-)

Thanks all for reading and 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

[openstack-dev] [Heat][Trove][Vitrage] (Re: [oslo][requirements][vitrage] oslo.service 1.28.1 breaks Vitrage gate)

[Davanum Srinivas]

Dear Trove, Vitrage, Heat teams,

Can you please see if this review will affect your CI jobs?

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

I've tested at least the Heat unit tests. But need you to test as well
as a previous version of this change broke stuff

Thanks,
Dims


On Fri, Dec 15, 2017 at 5:51 AM, ChangBo Guo  wrote:
> Thanks for raising this,  Oslo team will revert the change in
> https://review.openstack.org/#/c/528202/
>
> 2017-12-14 23:58 GMT+08:00 Afek, Ifat (Nokia - IL/Kfar Sava)
> :
>>
>> Hi,
>>
>>
>>
>> The latest release of oslo.service 1.28.1 breaks the Vitrage gate. We are
>> creating several threads and timers [1], but only the first thread is
>> executed. We noticed that Trove project already reported this problem [2].
>>
>>
>>
>> Please help us fix it.
>>
>>
>>
>> Thanks,
>>
>> Ifat.
>>
>>
>>
>> [1]
>> https://github.com/openstack/vitrage/blob/master/vitrage/datasources/services.py
>>
>> [2] https://review.openstack.org/#/c/527755/
>>
>>
>>
>>
>>
>>
>> __
>> 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
>>
>
>
>
> --
> ChangBo Guo(gcb)
> Community Director @EasyStack
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] [puppet] Add new puppet-senlin repository to Puppet OpenStack

[Mohammed Naser]

Done!

Thanks :)

On Tue, Apr 10, 2018 at 4:09 AM, 钟生平  wrote:
> Hi, Mohammed
>
> Needs PTL+1, Can you review?
>
> Thanks,
> Zhong Shengping
>
>
> At 2018-04-10 14:03:54, "钟生平"  wrote:
>
> Hi, core members
>
> I have added new puppet-senlin repository to Puppet OpenStack[1][2][3]. I'm
> going to work on this module. Please review.
>
> [1]https://review.openstack.org/#/c/559537/
> [2]https://review.openstack.org/#/c/559539/
> [3]https://review.openstack.org/#/c/559563/
>
> Thanks,
> Zhong Shengping
>
>
>
>
>
>
>



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.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] [FEMDC] Wed. 11 Apr - FEMDC IRC Meeting 15:00 UTC

[Dimitri Pertin]

Dear all,

This is a gentle reminder for our tomorrow meeting at 15:00 UTC.

A draft of the agenda is available at line 391, you are very welcome to 
add any item:

https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2018

Best regards,

Dimitri

__
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] Changes toComputeVirtAPI.wait_for_instance_event

[Andreas Scheuring]

Yes, that’s how it works!

---
Andreas Scheuring (andreas_s)



On 10. Apr 2018, at 16:05, Matt Riedemann  wrote:

On 4/9/2018 9:57 PM, Chen CH Ji wrote:
> Could you please help to share whether this kind of event is sent by 
> neutron-server or neutron agent ? I searched neutron code
> from [1][2] this means the agent itself need tell neutron server the 
> device(VIF) is up then neutron server will send notification
> to nova through REST API and in turn consumed by compute node?
> [1]https://github.com/openstack/neutron/tree/master/neutron/notify_port_active_direct
> [2]https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/rpc.py#L264

I believe the neutron agent is the one that is getting (or polling) the 
information from the underlying network backend when VIFs are plugged or 
unplugged from a host, then route that information via RPC to the neutron 
server which then sends an os-server-external-events request to the compute 
REST API, which then routes the event information down to the nova-compute host 
where the instance is currently running.

-- 

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] [nova] Changes toComputeVirtAPI.wait_for_instance_event

[Matt Riedemann]

On 4/9/2018 9:57 PM, Chen CH Ji wrote:
Could you please help to share whether this kind of event is sent by 
neutron-server or neutron agent ? I searched neutron code
from [1][2] this means the agent itself need tell neutron server the 
device(VIF) is up then neutron server will send notification

to nova through REST API and in turn consumed by compute node?

[1]https://github.com/openstack/neutron/tree/master/neutron/notify_port_active_direct
[2]https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/rpc.py#L264


I believe the neutron agent is the one that is getting (or polling) the 
information from the underlying network backend when VIFs are plugged or 
unplugged from a host, then route that information via RPC to the 
neutron server which then sends an os-server-external-events request to 
the compute REST API, which then routes the event information down to 
the nova-compute host where the instance is currently running.


--

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-dev] [tc] Proposal to start TC elections earlier

[Chris Dent]

I've posted a review

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

that suggests we do elections for the TC with a bigger gap between
the election and summit. From the commit message:

The existing 3 weeks prior to summit target for TC elections can
be problematic for travel planning for candidates who might only
go to summit if they win their election, or might plan a
different length of trip depending on their role(s) in the
community. This change makes the target for the election to be
six weeks prior to summit to ease that planning.

In addition to helping with travel concerns, it also means that
any newly elected TC members will be more involved in planning
for the forum at the summit.

If approved this change would go in effect for the second
election in 2018. The first election of 2018 is already
scheduled.

If you have opinions on this please comment here or on the review.


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

[openstack-dev] [tc] [all] TC Report 18-15

[Chris Dent]

Also at: https://anticdent.org/tc-report-18-15.html

It feels like people are busy. Traffic in the `#openstack-tc`
channel has been light for the past week.

# Forum Topics

By this coming Thursday we hope to have determined which [of several
topics](https://etherpad.openstack.org/p/YVR-forum-TC-sessions)
should be proposed for [the forum](http://forumtopics.openstack.org/).

# Kolla Situation

[In](http://lists.openstack.org/pipermail/openstack-dev/2018-March/128822.html)
[email](http://lists.openstack.org/pipermail/openstack-dev/2018-April/128950.html)
and in IRC discussion
[Wednesday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-04.log.html#t2018-04-04T17:52:45)
and
[Thursday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-05.log.html#t2018-04-05T15:01:20)
the many faces of Kolla have been debated. This started as a
discussion of whether kolla-kubernetes should be retired but has
branched widely since then, including plenty of discussion on
whether Kolla is doing containers "the right way" (whatever that
might be), and whether the start scripts in Kolla images should [be
moved](http://lists.openstack.org/pipermail/openstack-dev/2018-April/129088.html).

One of the side topics within this discussion is the nature of the
multiple hats worn by members of the community when engaging in
discussion. Does membership on the TC mean that everything you say
is with the voice of the TC? I certainly hope not, however there is
probably more that can be done to be clear which hat is being worn
in any given situation.

(So it's clear, these reports are written wearing my Chris hat and
are not the voice of the TC.)

# Consumption Models

There was some discussion [on
Thursday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-05.log.html#t2018-04-05T15:40:23)
about more effectively tracking the consumption (of OpenStack)
models that are present in the community. ttx suggested some
additional survey questions. Better data ought to help us decide if
energy is being spent in the right ways.

# Elections

The nomination period for TC
[elections](https://governance.openstack.org/election/) starts
tonight at 1 minute to midnight, UTC. There are seven positions open
for this election. The [potential forum
topics](https://etherpad.openstack.org/p/YVR-forum-TC-sessions) give
a pretty good overview of _some_ of the things that are on the TC's
radar for the coming months.

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

[openstack-dev] [nova][cinder] Concurrent requests to attach the same non-multiattach volume to multiple instances can succeed

[Lee Yarwood]

Hello all,

I just wanted to draw some attention to the following bug I stumbled
across yesterday when sending concurrent requests to attach a
non-multiattach volume to multiple instances :

https://bugs.launchpad.net/cinder/+bug/1762687

Scanning over the v3 API code in Cinder suggests that this could be due
to a complete lack of locking when creating the initial attachment but I
might be missing something here. I've marked this as impacting both Nova
and Cinder for now while but if I'm honest this strikes me as something
we need to resolve in c-api alone.

Cheers,

-- 
Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76


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] [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Stein" release

[Kashyap Chamarthy]

On Mon, Apr 09, 2018 at 04:24:06PM -0500, Matt Riedemann wrote:
> On 4/9/2018 4:58 AM, Kashyap Chamarthy wrote:
> > Keep in mind that Matt has a tendency to sometimes unfairly
> > over-simplify others views;-).  More seriously, c'mon Matt; I went out
> > of my way to spend time learning about Debian's packaging structure and
> > trying to get the details right by talking to folks on
> > #debian-backports.  And as you may have seen, I marked the patch[*] as
> > "RFC", and repeatedly said that I'm working on an agreeable lowest
> > common denominator.
> 
> Sorry Kashyap, I didn't mean to offend. I was hoping "delicious bugs" would
> have made that obvious but I can see how it's not. You've done a great,
> thorough job on sorting this all out.

No problem at all.  I know your communication style enough to not take
offence :-).  Thanks for the words!

> Since I didn't know what "RFC" meant until googling it today, how about
> dropping that from the patch so I can +2 it?

Sure, I meant to remove it on my last iteration; now dropped it.  (As
you noted on the review, should've used '-Workflow', but I typed "RFC"
out of muscle memory.)

Thanks for the review.

* * *

Aside: On the other patch[+] that actually bumps for "Rocky" and fixes
the resulting unit test fallout, I intend to fix the rest of the failing
tests sometime this week.  Remaining tests to be fixed:

test_live_migration_update_serial_console_xml
test_live_migration_with_valid_target_connect_addr
test_live_migration_raises_exception
test_virtuozzo_min_version_ok
test_min_version_ppc_ok
test_live_migration_update_graphics_xml
test_min_version_s390_ok

[+] https://review.openstack.org/#/c/558783/ -- libvirt: Bump
MIN_{LIBVIRT,QEMU}_VERSION for "Rocky"

-- 
/kashyap

__
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.db] innodb OPTIMIZE TABLE ?

[Gorka Eguileor]

On 09/04, Michael Bayer wrote:
> On Mon, Apr 9, 2018 at 5:53 AM, Gorka Eguileor  wrote:
> > On 06/04, Michael Bayer wrote:
> >> On Wed, Apr 4, 2018 at 5:00 AM, Gorka Eguileor  wrote:
> >> > On 03/04, Jay Pipes wrote:
> >> >> On 04/03/2018 11:07 AM, Michael Bayer wrote:
> >> >> > The MySQL / MariaDB variants we use nowadays default to
> >> >> > innodb_file_per_table=ON and we also set this flag to ON in installer
> >> >> > tools like TripleO. The reason we like file per table is so that
> >> >> > we don't grow an enormous ibdata file that can't be shrunk without
> >> >> > rebuilding the database.  Instead, we have lots of little .ibd
> >> >> > datafiles for each table throughout each openstack database.
> >> >> >
> >> >> > But now we have the issue that these files also can benefit from
> >> >> > periodic optimization which can shrink them and also have a beneficial
> >> >> > effect on performance.   The OPTIMIZE TABLE statement achieves this,
> >> >> > but as would be expected it itself can lock tables for potentially a
> >> >> > long time.   Googling around reveals a lot of controversy, as various
> >> >> > users and publications suggest that OPTIMIZE is never needed and would
> >> >> > have only a negligible effect on performance.   However here we seek
> >> >> > to use OPTIMIZE so that we can reclaim disk space on tables that have
> >> >> > lots of DELETE activity, such as keystone "token" and ceilometer
> >> >> > "sample".
> >> >> >
> >> >> > Questions for the group:
> >> >> >
> >> >> > 1. is OPTIMIZE table worthwhile to be run for tables where the
> >> >> > datafile has grown much larger than the number of rows we have in the
> >> >> > table?
> >> >>
> >> >> Possibly, though it's questionable to use MySQL/InnoDB for storing 
> >> >> transient
> >> >> data that is deleted often like ceilometer samples and keystone tokens. 
> >> >> A
> >> >> much better solution is to use RDBMS partitioning so you can simply 
> >> >> ALTER
> >> >> TABLE .. DROP PARTITION those partitions that are no longer relevant 
> >> >> (and
> >> >> don't even bother DELETEing individual rows) or, in the case of 
> >> >> Ceilometer
> >> >> samples, don't use a traditional RDBMS for timeseries data at all...
> >> >>
> >> >> But since that is unfortunately already the case, yes it is probably a 
> >> >> good
> >> >> idea to OPTIMIZE TABLE on those tables.
> >> >>
> >> >> > 2. from people's production experience how safe is it to run OPTIMIZE,
> >> >> > e.g. how long is it locking tables, etc.
> >> >>
> >> >> Is it safe? Yes.
> >> >>
> >> >> Does it lock the entire table for the duration of the operation? No. It 
> >> >> uses
> >> >> online DDL operations:
> >> >>
> >> >> https://dev.mysql.com/doc/refman/5.7/en/innodb-file-defragmenting.html
> >> >>
> >> >> Note that OPTIMIZE TABLE is mapped to ALTER TABLE tbl_name FORCE for 
> >> >> InnoDB
> >> >> tables.
> >> >>
> >> >> > 3. is there a heuristic we can use to measure when we might run this
> >> >> > -.e.g my plan is we measure the size in bytes of each row in a table
> >> >> > and then compare that in some ratio to the size of the corresponding
> >> >> > .ibd file, if the .ibd file is N times larger than the logical data
> >> >> > size we run OPTIMIZE ?
> >> >>
> >> >> I don't believe so, no. Most things I see recommended is to simply run
> >> >> OPTIMIZE TABLE in a cron job on each table periodically.
> >> >>
> >> >> > 4. I'd like to propose this job of scanning table datafile sizes in
> >> >> > ratio to logical data sizes, then running OPTIMIZE, be a utility
> >> >> > script that is delivered via oslo.db, and would run for all innodb
> >> >> > tables within a target MySQL/ MariaDB server generically.  That is, I
> >> >> > really *dont* want this to be a script that Keystone, Nova, Ceilometer
> >> >> > etc. are all maintaining delivering themselves.   this should be done
> >> >> > as a generic pass on a whole database (noting, again, we are only
> >> >> > running it for very specific InnoDB tables that we observe have a poor
> >> >> > logical/physical size ratio).
> >> >>
> >> >> I don't believe this should be in oslo.db. This is strictly the purview 
> >> >> of
> >> >> deployment tools and should stay there, IMHO.
> >> >>
> >> >
> >> > Hi,
> >> >
> >> > As far as I know most projects do "soft deletes" where we just flag the
> >> > rows as deleted and don't remove them from the DB, so it's only when we
> >> > use a management tool and run the "purge" command that we actually
> >> > remove these rows.
> >> >
> >> > Since running the optimize without purging would be meaningless, I'm
> >> > wondering if we should trigger the OPTIMIZE also within the purging
> >> > code.  This way we could avoid innefective runs of the optimize command
> >> > when no purge has happened and even when we do the optimization we could
> >> > skip the ratio calculation altogether for tables where no rows have been
> >> > deleted (the ratio hasn't changed).
> >> 

Re: [openstack-dev] [nova] EC2 cleanup ?

[Chen CH Ji]

A patch set has been proposed [1] , additional stuffs will be posted once
got further feedback.

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

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Artom Lifshitz 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   03/27/2018 02:30 AM
Subject:Re: [openstack-dev] [nova] EC2 cleanup ?



> That is easier said than done. There have been a couple of related
attempts
> in the past:
>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_266425_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=7Qqd9VAjMEUMU2lmoHzRFtYMcpBvm9XhPsTVsUd3OoU=mmdwfYEaSGeM5GvfgBGKf29XfGL9FPgXyPc1BoBkex4=

>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_282872_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=7Qqd9VAjMEUMU2lmoHzRFtYMcpBvm9XhPsTVsUd3OoU=Q9I4L9tbv9-GN91W7rW6wrYpBzC_gbQZtk165On8qwc=

>
> I don't remember exactly where those fell down, but it's worth looking at
> this first before trying to do this again.

Interesting. [1] exists, and I'm pretty sure that we ship it as part
of Red Hat OpenStack (but I'm not a PM and this is not an official Red
Hat stance, just me and my memory), so it works well enough. If we
have things that depend on our in-tree ec2 api, maybe we need to get
them moved over to [1]?

[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_ec2-2Dapi=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=7Qqd9VAjMEUMU2lmoHzRFtYMcpBvm9XhPsTVsUd3OoU=c5424HG9UKS4FXVFz3BkIbBYzOGyF9_5F2JyRa9y8i4=


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=7Qqd9VAjMEUMU2lmoHzRFtYMcpBvm9XhPsTVsUd3OoU=rO0wjEa_YYM2oLf0FJcTVJXmbvDB4h93NGieFts62aU=




__
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][nova] about re-image the volume

[Gorka Eguileor]

On 09/04, Sean McGinnis wrote:
> On Mon, Apr 09, 2018 at 07:00:56PM +0100, Duncan Thomas wrote:
> > Hopefully this flow means we can do rebuild root filesystem from
> > snapshot/backup too? It seems rather artificially limiting to only do
> > restore-from-image. I'd expect restore-from-snap to be a more common
> > use case, personally.
> >
>
> That could get tricky. We only support reverting to the last snapshot if we
> reuse the same volume. Otherwise, we can create volume from snapshot, but I
> don't think it's often that the first thing a user does is create a snapshot 
> on
> initial creation of a boot image. If it was created from image cache, and the
> backend creates those cached volume by using a snapshot, then that might be an
> option.
>
> But these are a lot of ifs, so that seems like it would make the logic for 
> this
> much more complicated.
>
> Maybe a phase II optimization we can look into?
>

From the Cinder side of things I think these two would be easier than
the re-image, because we would have even fewer steps, and the
functionality to do the copying is exactly what we have now, as it will
copy the data to the same volume, so we wouldn't need to fiddle with the
UUID fields etc.

Moreover I know customers who have asked about this functionality in the
past, mostly interested in restoring the root volume of an existing VM
from a backup to preserve the system ID and not break licenses.

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

Re: [openstack-dev] [puppet] Add new puppet-senlin repository to Puppet OpenStack

[钟生平]

Hi, Mohammed


Needs PTL+1, Can you review?


Thanks,
Zhong Shengping



At 2018-04-10 14:03:54, "钟生平"  wrote:

Hi, core members


I have added new puppet-senlin repository to Puppet OpenStack[1][2][3]. I'm 
going to work on this module. Please review.


[1]https://review.openstack.org/#/c/559537/
[2]https://review.openstack.org/#/c/559539/
[3]https://review.openstack.org/#/c/559563/


Thanks,
Zhong Shengping




 __
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-stable-maint] Stable check of openstack/networking-midonet failed

[Elõd Illés]

Hi,

Thanks, too. I've prepared the remaining backport [1] for stable/ocata 
to solve the issue there as well [2]


[1] https://review.openstack.org/#/c/559940/
[2] 
http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/networking-midonet/stable/ocata/openstack-tox-py27/928af21/job-output.txt.gz#_2018-04-10_06_29_43_146966


Thanks,

Előd


On 2018-04-09 06:16, Tony Breeds wrote:

On Tue, Apr 03, 2018 at 02:05:35PM +0200, Elõd Illés wrote:

Hi,

These patches probably solve the issue, if someone could review them:

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

and

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

Thanks,

Thanks for digging into that.  I've approved these even though they
don't have a +2 from the neutron stable team.  They look safe as the
only impact tests, unblock the gate and also have +1's from subject
matter experts.

Yours Tony.




__
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] Changes to Zuul role checkouts

[Andrea Frittoli]

On Mon, Apr 9, 2018 at 5:55 PM James E. Blair  wrote:

> Hi,
>
> We recently fixed a subtle but important bug related to how Zuul checks
> out repositories it uses to find Ansible roles for jobs.
>

\o/


>
> This may result in a behavior change, or even an error, for jobs which
> use roles defined in projects with multiple branches.
>
> Previously, Zuul would (with some exceptions) generally check out the
> 'master' branch of any repository which appeared in the 'roles:' stanza
> in the job definition.  Now Zuul will follow its usual procedure of
> trying to find the most appropriate branch to check out.  That means it
> tries the project override-checkout branch first, then the job
> override-checkout branch, then the branch of the change, and finally the
> default branch of the project.
>
> This should produce more predictable behavior which matches the
> checkouts of all other projects involved in a job.
>
> If you find that the wrong branch of a role is being checked out,
> depending on circumstances, you may need to set a job or project
> override-checkout value to force the correct one, or you may need to
> backport a role to an older branch.
>
> If you encounter any problems related to this, please chat with us in
> #openstack-infra.
>
>
Thanks a lot Jim for fixing this!

With this in place I can now continue the work on devstack, tempest and
grenade base roles and jobs for zuul v3.
Next steps (in order of dependency):
- backport ansible devstack changes to queens and pike
- start using the "orchestrate-devstack" role in the "devstack-tempest" base
  job - so that it can be used for multinode jobs as well
- continue the work on setting up a grenade zuulv3 job

Andrea Frittoli (andreaf)



> Thanks,
>
> Jim
>
> __
> 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] [neutron] [OVN] Tempest API / Scenario tests and OVN metadata

[Anil Venkata]

How to override tempest tests in neutron or networking-ovn repo?

Thanks
Anil

On Mon, Apr 9, 2018 at 8:26 PM, Lucas Alvares Gomes 
wrote:

> Hi,
>
> > Another idea is to modify test that it will:
> > 1. Check how many ports are in tenant,
> > 2. Set quota to actual number of ports + 1 instead of hardcoded 1 as it
> is now,
> > 3. Try to add 2 ports - exactly as it is now,
> >
> > I think that this should be still backend agnostic and should fix this
> problem.
> >
>
> Great idea! I've gave it a go and proposed it at
> https://review.openstack.org/559758
>
> Cheers,
> Lucas
>
> __
> 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] [horizon][xstatic]How to handle xstatic if upstream files are modified

[Xinni Ge]

Hi Radomir, Ivan,

Thanks a lot for your advice.
I will update the xstatic files just as the upstream.
As for the customized lines, I will try to find a better way to solve it,
maybe override the original functions inside the project.

Best regards,
Xinni

On Tue, Apr 10, 2018 at 4:58 AM, Ivan Kolodyazhny  wrote:

> Hi, Xinni,
>
> I absolutely agree with Radomir. We should keep xstatic files without
> modifications. We don't know if they are used outside of OpenStack or not,
> so they should be the same as NPM packages
>
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Mon, Apr 9, 2018 at 12:32 PM, Radomir Dopieralski <
> openst...@sheep.art.pl> wrote:
>
>> The whole idea about xstatic files is that they are generic, not specific
>> to Horizon or OpenStack, usable by other projects that need those static
>> files. In fact, at the time we started using xstatic, it was being used by
>> the MoinMoin wiki project (which is now dead, sadly). The modifications you
>> made are very specific to your usecase and would make it impossible to
>> reuse the packages by other applications (or even by other Horizon
>> plugins). The whole idea of a library is that you are using it as it is
>> provided, and not modifying it.
>>
>> We generally try to use all the libraries as they are, and if there are
>> any modifications necessary, we push them upstream, to the original
>> library. Otherwise there would be quite a bit of maintenance overhead
>> necessary to keep all our downstream patches. When considerable
>> modification is necessary that can't be pushed upstream, we fork the
>> library either into its own repository, or include it in the repository of
>> the application that is using it.
>>
>> On Mon, Apr 9, 2018 at 2:54 AM, Xinni Ge  wrote:
>>
>>> Hello, team.
>>>
>>> Sorry for talking about xstatic repo for so many times.
>>>
>>> I didn't realize xstatic repositories should be provided with exactly
>>> the same file as upstream, and should have talked about it at very first.
>>>
>>> I modified several upstream files because some of them files couldn't be
>>> used directly under my expectation.
>>>
>>> For example,  {{ }} are used in some original files as template tags,
>>> but Horizon adopts {$ $} in angular module, so I modified them to be
>>> recognized properly.
>>>
>>> Another major modification is that css files are converted into scss
>>> files to solve some css import issue previously.
>>> Besides, after collecting statics, some png file paths in css cannot be
>>> referenced properly and shown as 404 errors, I also modified css itself to
>>> handle this issues.
>>>
>>> I will recheck all the un-matched xstatic repositories and try to
>>> replace with upstream  files as much as I can.
>>> But I if I really have to modify some original files, is it acceptable
>>> to still use it as embedded files with license info appeared at the top?
>>>
>>>
>>> Best Regards,
>>> Xinni Ge
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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: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
>
>


-- 
Best Regards,
Xinni Ge
__
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] [puppet] Add new puppet-senlin repository to Puppet OpenStack

[钟生平]

Hi, core members


I have added new puppet-senlin repository to Puppet OpenStack[1][2][3]. I'm 
going to work on this module. Please review.


[1]https://review.openstack.org/#/c/559537/
[2]https://review.openstack.org/#/c/559539/
[3]https://review.openstack.org/#/c/559563/


Thanks,
Zhong Shengping__
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