April 2019 - openstack-discuss - lists.openstack.org

[searchlight] Team meeting today at 13:30 UTC
by Trinh Nguyen 07 Apr '19

07 Apr '19

Hi team, We will have the team meeting today at 13:30 UTC on #openstack-searchlight IRC channel. Please look at the meeting agenda at https://etherpad.openstack.org/p/search-team-meeting-agenda Yours, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[Magnum] How to use docker CLI against a Magnum-managed Kubernetes cluster
by Namrata Sitlani 07 Apr '19

07 Apr '19

Hello, I am trying to use docker CLI against a Magnum-managed Kubernetes cluster so as to interact with its Docker registry. I followed the steps as explained in https://docs.openstack.org/magnum/rocky/user/#interfacing-with-a-secure-clu… but magnum does not setup docker on tcp port so it cannot be accessed outside the minion node(where docker is running). I appreciate any help guiding how to use docker CLI. Thanks Namrata Sitlani

2 1

Re: [OpenStack-I18n] Questions about Stein Dashboard UI translations
by Ian Y. Choi 06 Apr '19

06 Apr '19

"Team activities with release" are described in https://docs.openstack.org/i18n/latest/release_management.html , but let me first try to clarify more on I18n team activites with stable versions in Zanata regarding project release activities. Generally, there are two main reasons creating and maintaining stable versions in Zanata: 1. Hard StringFreezes with RC1, RC2, and so on : checking translation is much better using stable versions(with translation checksite, ideally) : That's why creating stable versions in Zanata is encouraged when there is first stable-xx branch in project repositories 2. Maintaining translation bugs on stable branches : There might be translation bugs on released artifacts - tranlation bugs can be fixed by editing stable versions in Zanata, syncing with project repos, and releasing new artifacts on target stable branches. : Usually, after final real stable artifacts are announced, then translations on stable versions from the first part are merged into master version for the next release. For the first part, Ideally, it would be excellent if there are enough translation demand, stable version creation activities in Zanata, translation activites on stable versions, communications via I18n-release cross project liaison, and review activities through translation checksite, and those are interactive together. If not, then I think I18n team needs to minimize the targets for such purpose or think differently how I18n team reacts with final new stable version creation. For the second part, the glad news I wanna share is that now all stable versions in Zanata now have content. More details are described in below: - Now projects mentioned in http://lists.openstack.org/pipermail/openstack-i18n/2019-March/003382.html should have "stable-stein" versions in Zanata : except "sahara-plugin-*" since there is no translated resource even on master version -> I wanna set that those will be synced only for master repos. - Some stable document versions including "keystone, octavia-dashboard, trove, watcher" projects were already filled translations from master (thanks a lot, Andreas and/or Frank!), but a few of them still had releasenotes documents, which need to be deleted on stable versions: "murano-dashboard, solum-dashboard, swift, trove-dashboard, zaqar, zaqar-ui, zun-ui". - One zh-CN translator did translations from empty content stable-stein version for ironic-ui project. Since the content were actually the same as master branch, I deleted stable-stein version on ironic-ui project, re-created stable-version by copying from master version, and removed releasenotes document on stable-stein version. - Strangely, there are no releasenotes document on master version for karbor-dashboard and neutron-lbaas-dashboard projects - need to be investigated further. As Train PTL, I will identify how much translations were for Stein release and try to find better ways how I18n team can work well regarding new release activites which will happen after around 6 months. With many thanks, /Ian Akihiro Motoki wrote on 4/5/2019 1:35 AM: > I see no content for stable-stein version for example in > neutron-fwaas-dashboard [1]. > What should we do? > I am really confused with the process around stable-stein cut.... > > [1] > https://translate.openstack.org/project/view/neutron-fwaas-dashboard?dswid=… > > On Mon, Apr 1, 2019 at 7:21 PM Frank Kloeker <eumel(a)arcor.de > <mailto:eumel@arcor.de>> wrote: > > Good morning, > > last week I was on a business trip and just wondering about ML > activities. But for sure, we have release weeks and thanks for > raising > up that topic. > Based on Ian's work I just cleaned up the Stein Dashboard with stable > branches as available [1]. So it's more clear what translators > have to > do, I mean translate stable branch instead of master. There is no > clear > handover between project teams when a stable branch is available, so > this needs to investigate by Zanata admin/PTL, or the failed job > list on > [2]. A lot of good jobs are already running on [3] > Further I investigted Ian's creation of empty versions in Zanata > and I > would say that won't work well, because that are post jobs and not > periodic jobs in Zuul. So if now merge on stable branch will > happen, the > po files won't sync to Zanata. Or it will take days, like in [4]. > On the > other hand, someone will translate things targeting in that release, > then it's required to copy the stable version from master as usually. > I know, this takes some time and work, but at the moment there is no > improvement because Zanata developement is already gone and the > feature > set on API is at it is. > > Regarding the second question for Horizon on translation check > site it > might be a question for the Horizon team. From my experience with > language settings it depends mostly on your browser settings. So > I'm not > sure if it's really a bug. > > kind regards > > Frank > > > [1] > https://translate.openstack.org/version-group/view/Stein-dashboard-translat… > [2] > http://zuul.openstack.org/builds?job_name=upstream-translation-update&job_n… > [3] > http://zuul.openstack.org/builds?job_name=upstream-translation-update&branc… > [4] > http://zuul.openstack.org/builds?job_name=upstream-translation-update&proje… > > > > > Am 2019-03-27 03:21, schrieb Yuko Katabami: > > Hi Frank and all, > > > > I have a couple of questions about Horizon UI translation. > > Hope you can help me. > > > > 1. Is stable-stein version going to be created soon in Zanata? I > > noticed that the projects in github already have the new branch. > > > > 2. With Octavia Dashboard, I am not able to see Japanese > translations > > in Horizon even though it is 100% completed in master. I can see > that > > po files are imported properly: > > > https://github.com/openstack/octavia-dashboard/tree/master/octavia_dashboar… > > Is there anything I need to do to be able to see it in my > environment? > > > > Many thanks in advance. > > > > Yuko > > _______________________________________________ > > OpenStack-I18n mailing list > > OpenStack-I18n(a)lists.openstack.org > <mailto:OpenStack-I18n@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n > > > _______________________________________________ > OpenStack-I18n mailing list > OpenStack-I18n(a)lists.openstack.org > <mailto:OpenStack-I18n@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n > > > _______________________________________________ > OpenStack-I18n mailing list > OpenStack-I18n(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n

1 0

Re: [Zun] Address already belongs to a bound Neutron port Error
by Hongbin Lu 06 Apr '19

06 Apr '19

On Thu, Apr 4, 2019 at 5:14 AM Navdeep Uniyal <navdeep.uniyal(a)bristol.ac.uk> wrote: > Hi Hongbin, > > > > I could not see the logs. I have installed zun on the baremetal machine > with full openstack (not devstack) > > -- Logs begin at Tue 2019-04-02 16:23:14 UTC, end at Thu 2019-04-04 > 09:05:59 UTC. -- > > -- No entries – > My bad. If you were following the installation guide, you should run "sudo journalctl -u kuryr-libnetwork" > > > Please advise me how can I enable logging for this. > > I can’t find anything in /etc/kuryr/kuryr.log > In my kuryr.conf file I have set the value to debug and the log file as > ‘/etc/kuryr/kuryr.log’ > It is systemd process so uses journalctl to retrieve the log. No further configuration is needed, although it is always helpful to turn on debug on troubleshooting > > My flat network is: > > openstack network show 5guknet > > > +---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ > > | Field | > Value > | > > > +---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ > > | admin_state_up | > UP > | > > | availability_zone_hints > | > | > > | availability_zones | > nova > | > > | created_at | > 2019-04-03T15:30:50Z > | > > | description > | > | > > | dns_domain | > None > | > > | id | > a9decbf0-e8c8-4574-86f8-242756fce63b > | > > | ipv4_address_scope | > None > | > > | ipv6_address_scope | > None > | > > | is_default | > False > | > > | is_vlan_transparent | > None > | > > | mtu | > 1500 > | > > | name | > 5guknet > | > > | port_security_enabled | True > | > > | project_id | > a8888997d0da4d3d80fe7ca833e74bb7 > | > > | provider:network_type | > flat > | > > | provider:physical_network | 5guknet > | > > | provider:segmentation_id | > None > | > > | qos_policy_id | > None > | > > | revision_number | 4 > | > > | router:external | > External > | > > | segments | > None > | > > | shared | True > | > > | status | > ACTIVE > | > > | subnets | > e684a17b-6b17-4ea2-bbc9-752a21304dcc > | > > | tags | kuryr.net.existing:7c34de9e89a3, > kuryr.net.uuid.lh:7c34de9e89a3e86ee3561834520bc2ea, > kuryr.net.uuid.uh:35c16ff10c1821c06a7098833e0bf131 | > > | updated_at | > 2019-04-03T15:33:37Z > | > > > +---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ > > > > Subnet: > > openstack subnet show e684a17b-6b17-4ea2-bbc9-752a21304dcc > > +-------------------+--------------------------------------+ > > | Field | Value | > > +-------------------+--------------------------------------+ > > | allocation_pools | 10.68.48.131-10.68.48.150 | > > | cidr | 10.68.48.0/24 | > > | created_at | 2019-04-03T15:30:51Z | > > | description | | > > | dns_nameservers | 8.8.8.8 | > > | enable_dhcp | True | > > | gateway_ip | 10.68.48.1 | > > | host_routes | | > > | id | e684a17b-6b17-4ea2-bbc9-752a21304dcc | > > | ip_version | 4 | > > | ipv6_address_mode | None | > > | ipv6_ra_mode | None | > > | name | 5guknet | > > | network_id | a9decbf0-e8c8-4574-86f8-242756fce63b | > > | project_id | a8888997d0da4d3d80fe7ca833e74bb7 | > > | revision_number | 1 | > > | segment_id | None | > > | service_types | | > > | subnetpool_id | None | > > | tags | b130d090-9b7f-4c68-9f45-775a18bbb649 | > > | updated_at | 2019-04-03T15:33:37Z | > > +-------------------+--------------------------------------+ > > > > Port: > openstack port show 8b203580-2051-4ad0-8057-c7885324d0b9 > > > +-----------------------+-----------------------------------------------------------------------------+ > > | Field | > Value > | > > > +-----------------------+-----------------------------------------------------------------------------+ > > | admin_state_up | UP > | > > | allowed_address_pairs > | > | > > | binding_host_id | > bedminster > | > > | binding_profile > | > | > > | binding_vif_details | > port_filter='True' > | > > | binding_vif_type | bridge > | > > | binding_vnic_type | > normal > | > > | created_at | > 2019-04-04T09:05:33Z > | > > | data_plane_status | > None > | > > | description > | > | > > | device_id | > c6428670-2846-4862-8ecb-611293cabc2c > | > > | device_owner | > compute:kuryr > | > > | dns_assignment | > None > | > > | dns_domain | > None > | > > | dns_name | > None > | > > | extra_dhcp_opts > | > | > > | fixed_ips | ip_address='10.68.48.143', > subnet_id='e684a17b-6b17-4ea2-bbc9-752a21304dcc' | > > | id | 8b203580-2051-4ad0-8057-c7885324d0b9 > | > > | mac_address | > fa:16:3e:2e:07:ad > | > > | name > | > | > > | network_id | > a9decbf0-e8c8-4574-86f8-242756fce63b > | > > | port_security_enabled | > True > | > > | project_id | a8888997d0da4d3d80fe7ca833e74bb7 > | > > | qos_policy_id | > None > | > > | revision_number | > 2 > | > > | security_group_ids | > 49839b6f-79c7-4db7-bb71-ffecbdd645d5 > | > > | status | > DOWN > | > > | tags > | > | > > | trunk_details | > None > | > > | updated_at | 2019-04-04T09:05:33Z > | > > > +-----------------------+-----------------------------------------------------------------------------+ > > Thank you, > > Kind Regards, > > Navdeep > > > > > > *From:* Hongbin Lu <hongbin034(a)gmail.com> > *Sent:* 04 April 2019 02:49 > *To:* Navdeep Uniyal <navdeep.uniyal(a)bristol.ac.uk> > *Cc:* openstack(a)lists.openstack.org > *Subject:* Re: [Zun] Address already belongs to a bound Neutron port Error > > > > Hi Navdeep, > > > > It looks I cannot reproduce the problem using rocky with flat network. If > possible, would you provide the following: > > > > * Your kuryr-libnetwork log (with sensitive information removed). You can > get it by running "sudo journalctl -u devstack@kuryr-libnetwork". > > * Your flat network (openstack network show XXX) > > * Your subnet (openstack subnet show e684a17b-6b17-4ea2-bbc9-752a21304dcc) > > * Your port (openstack port show f0d6153a-7408-4cd5-82c3-9abed48ad056) > > > > Best regards, > > Hongbin > > > > On Wed, Apr 3, 2019 at 11:52 AM Navdeep Uniyal < > navdeep.uniyal(a)bristol.ac.uk> wrote: > > Dear All, > > > > I have just installed Zun and tried creating a container following the > instructions as per the following webpage: > > https://docs.openstack.org/zun/rocky/install/index.html > > > > I am getting following error while starting my test container using > ‘openstack appcontainer run --name container2 --net network=$NET_ID cirros > ping 8.8.8.8’: > > > > status_reason | Docker internal error: 500 Server Error: Internal > Server Error ("IpamDriver.RequestAddress: Requested ip address > {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': > u'10.68.48.147'} already belongs to a bound Neutron port: > f0d6153a-7408-4cd5-82c3-9abed48ad056"). > > > > The network I selected is a flat network on openstack with external flag > true. > > Please advise me how to solve the issue or if there is a specific > requirement for this. > > > > Thank you, > > Kind Regards, > > Navdeep > >

2 6

[zun][k8s][tc] OpenStack Zun become the official provider for Virtual Kubelet
by Hongbin Lu 06 Apr '19

06 Apr '19

Hi all, I have a good news to share. Right now, Zun is officially accepted [1] as OpenStack provider for Virtual Kubelet. A brief introduce. Virtual Kubelet is a CNCF sandbox project that allows cloud providers to implement Kubelet equivalent functionality. Existing providers of Virtual Kubelet are AWS Fargate, Azure Container Instance, etc. I think it is quite important for OpenStack to have a provider implementation in Virtual Kubelet, which basically makes OpenStack align with what other proprietary cloud providers in this territory. OpenStack Zun team is committed to enhance and maintain this provider and offer a great k8s integration experience for our users. Please feel free to reach out the Zun team if there is any inquiries. [1] https://github.com/virtual-kubelet/virtual-kubelet/pull/239 Best regards, Hongbin

5 6

[tc][ptl][all] Completion Report: OpenStack gate testing migration to Bionic (Ubuntu LTS 18.04)
by Ghanshyam Mann 06 Apr '19

06 Apr '19

Hello Everyone, We have all patches merged now for legacy job migration to bionic. All the legacy and zuulv3 native jobs are running on Bionic in stable/stein onwards. This means we have completed our stein testing runtime[1] in OpenStack as a whole. Thanks a lot to all of the teams for such nice coordination. Summary: - Started this migration very late in stein (in Dec 2018) - FInished migration in 2 part. 1. zuulv3 native job migration, 2. legacy jobs migration. - networking-midonet bionic jobs are n-v as it is not yet ready on bionic. - ~50 patches merged to migrate the gate jobs - ~ 60 DNM testing patches done before migration happens - We managed no big gate break for any project. Except for Cinder which was for 1 day I think. Ref: - https://review.openstack.org/#/q/(topic:legacy-job-bionic+OR+topic:legacy-j… - https://review.openstack.org/#/q/topic:devstack-bionic - http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004268.ht… - http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003598.ht… - https://etherpad.openstack.org/p/legacy-job-bionic - http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000837… - https://etherpad.openstack.org/p/devstack-bionic [1] https://governance.openstack.org/tc/reference/runtimes/stein.html -gmann

6 5

[ec2api] SSL Problem
by Georgios Dimitrakakis 06 Apr '19

06 Apr '19

Dear all, I am trying to setup ec2-api with SSL support on Rocky and no matter what I do I am getting the following error in the logs (/var/log/messages) ec2-api: SSLError: [SSL: SSL_HANDSHAKE_FAILURE] ssl handshake failure (_ssl.c:1822) and in the end ec2-api: SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a certificate (_ssl.c:1822) The full trace can be found here: https://pastebin.com/iPHXudag (where I have hidden the hostname) What I have done is that in "ec2api.conf" I have set the ca_file, cert_file and key_file pointing to the same files that Openstack's Dashboard is using which can be accessed without a problem. Afterwards I have restarted all ec2 services meaning both the "openstack-ec2-api-metadata.service" and "openstack-ec2-api.service". Using openssl cli and trying to connect to port 8788 I am seeing somewhere in the middle the error: SSL_connect:SSLv3 write client key exchange A write to 0x26c3e30 [0x2721290] (6 bytes => -1 (0xFFFFFFFFFFFFFFFF)) SSL_connect:error in SSLv3 write finished A SSL_connect:error in SSLv3 write finished A write:errno=32 The same openssl cli for port 443 (dashboard) works out of the box without a problem Obviously the cert is not served properly but cannot figure out why... Needless to say that I have tripled checked for any spelling mistakes, permissions etc. but I am open to suggestions. I have set ec2api to "Debug" mode but there isn't anything useful in the logs and in fact is not writing anything except a line like the one below when trying to access it: 2019-04-06 01:25:03.805 211954 DEBUG ec2api.wsgi.server [-] (211954) accepted ('xxx.xxx.xxx.xxx', 60154) server /usr/lib/python2.7/site-packages/eventlet/wsgi.py:883 Can someone shed some light please? If there is anything that you would like me to share with you like the openssl CLI's output or the ec2api.log please let me know. Best regards, G.

2 3

octavia 4.0.0.0rc3 (stein)
by no-reply＠openstack.org 06 Apr '19

06 Apr '19

Hello everyone, A new release candidate for octavia for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/octavia/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/octavia/log/?h=stable/stein Release notes for octavia can be found at: https://docs.openstack.org/releasenotes/octavia/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/908 and tag it *stein-rc-potential* to bring it to the octavia release crew's attention.

1 0

[telemetry] how does one can participate in the telemetry planning for train?
by Miguel Lavalle 05 Apr '19

05 Apr '19

Hi Telemetry Team, Some of my co-workers are interested in participating in the up-coming telemetry planning for Train ( https://etherpad.openstack.org/p/telemetry-train) How can we get the url of the Google hangout? Best regards Miguel

1 0

[requirements][FFE][congress] lower psycopg2 requirement to 2.5.1
by Eric K 05 Apr '19

05 Apr '19

Requesting exception to lower a requirement to resolve a packaging issue. https://review.openstack.org/#/c/650100/

4 7