July 2019 - openstack-discuss - lists.openstack.org

[nova][ptg] Shanghai attendance
by Eric Fried 11 Jul '19

11 Jul '19

We (nova) need to let the foundation know about our planned presence at the Shanghai PTG for the U release. To that end, I've seeded an etherpad [1]. If you are a contributor or operator with an interest in nova, please add your name to the Attendance section, even (especially) if you know you are not attending. I need this information by the beginning of August, even if it's tentative. Thanks! efried [1] https://etherpad.openstack.org/p/nova-shanghai-ptg

6 8

openstack-sdk API - Get all flavors for all projects.
by Laurent Dumont 10 Jul '19

10 Jul '19

Hi everyone, I'm trying to map the relationship between projects, host-aggregate and computes. I'm trying to find a way to use the Openstack Python SDK in order to list all existing flavors and the "access_project_ids" seems to be the best way to see which project is associated with the flavor. That said, it seems that the python SDK does not expose the value when querying using "get_flavor". Anyone know of way of getting the information from the SDK? Thanks!

1 0

[tc] agenda for Technical Committee Meeting 11 July 2019 @ 1400 UTC
by Thierry Carrez 10 Jul '19

10 Jul '19

TC Members, Our next meeting will be this Thursday, 11 July at 1400 UTC in #openstack-tc. I'll be your chair and we'll rely on mugsie to keep the GIF game level high. This email contains the agenda for the meeting, based on the content of the wiki [0]. If you will not be able to attend, please include your name in the "Apologies for Absence" section of the wiki page [0]. [0] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee * Follow up on past action items ** Health check changes: asettle to update community (done), fungi to update wiki (done), mugise to update yaml file with liasons and mnaser to update the tooling ** Help-most-needed list: AlanClark and zaneb to update investment opportunities document [0] https://etherpad.openstack.org/p/2019-upstream-investment-opportunities-ref… [1] https://review.opendev.org/#/c/657447/ ** Goal selection: lbragstad to prune the community-goals etherpad [2] https://etherpad.openstack.org/p/community-goals ** Pop-up teams: ttx to define pop-up teams [3] https://review.opendev.org/#/c/661356/ [4] https://review.opendev.org/#/c/661983/5 ** SIG governance: tc-members to review goal, popup, and SIG project etherpad [5] https://etherpad.openstack.org/p/explain-team-formate-differentiate ** Review PTL Guide: asettle ttx ricolin to sync up and review the PTL section of the project teams guide to improve the PTL experience [6] https://review.opendev.org/#/c/665699/ * Active initiatives ** Python 3: mnaser to sync up with swift team on python3 migration and mugsie to sync with dhellmann or release-team to find the code for the proposal bot ** Forum follow-up: ttx to organise Milestone 2 forum meeting with tc-members ** Make goal selection a two-step process (needs reviews at https://review.opendev.org/#/c/667932/) * Update on U release naming process * What are retired repos ? Regards, -- Thierry Carrez (ttx)

1 0

[openstack-dev] [neutron] [ptg] Start planning for the PTG in Shanghai
by Miguel Lavalle 10 Jul '19

10 Jul '19

Dear Neutrinos, We need to help the Foundation to plan for the the PTG in Shanghai. To that end, I have created an etherpad to start collecting the names of the team members who plan to attend and also topics to be discussed during our meetings: https://etherpad.openstack.org/p/Shanghai-Neutron-Planning I need to respond back to the Foundation's survey by August 11th. So it will be very helpful if all of you who plan to be in Shanghai add your names and irc nicks to the "Attendees" section no later than August 4th. This deadline doesn't apply to the proposed topics section. For that, we have more time. Regards Miguel

1 0

[horizon] django-pyscss unmaintained?
by Thomas Goirand 10 Jul '19

10 Jul '19

Hi, As I'm maintaining python-django-pyscss in Debian, I've noticed that there's no commit since 2015 on the Github repository, and no pypi release either. I've sent a new pull request here: https://github.com/fusionbox/django-pyscss/pull/45 so that pyscss continues to pass unit tests with Django 2.2, but I have very little hope for it to be merged, as the previous pull request for Django 1.11 was never merged. Is it time to take over the project? Can someone from the Horizon team get in touch with the previous maintainer? Cheers, Thomas Goirand (zigo)

2 1

[ironic] Shanghai PTG/Forum
by Julia Kreger 10 Jul '19

10 Jul '19

Greetings fellow ironic contributors! I've created an initial planning/discussion etherpad for the upcoming Shanghai summit[0]. I need a count of contributors that intend to attend with-in the next few weeks. If you plan on or intend to attend, please indicate so on the etherpad. I look forward to ideas and items for discussion! -Julia [0]: https://etherpad.openstack.org/p/PVG-Ironic-Planning

1 0

[placement] mascot/logo live
by Chris Dent 10 Jul '19

10 Jul '19

https://www.openstack.org/project-mascots has been updated to have the Placement mascot/logo. Here's a sample: https://object-storage-ca-ymq-1.vexxhost.net/swift/v1/6e4619c416ff4bd19e1c0… Thanks very much to the Foundation and their designers for making this happen. In case you missed the discussion [1] about this a while back, we know it looks a bit cranky. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/thread.htm… -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

[devstack] Deploy issue on Ubuntu 16.04.
by Guannan GN2 Sun 10 Jul '19

10 Jul '19

Hi team, I meet some problem when deploying devstack(from https://github.com/openstack/devstack master branch) on Ubuntu 16.04. It seems something is wrong with placement-api error message as following: curl -g -k --noproxy '*' -s -o /dev/null -w '%{http_code}%' http://10.240.24.138/placement [[503 == 503]] [ERROR] /opt/stack/devstack/lib/placement:156 placement-api did not start However when I check its status using "systemctl status devstack@placement-api", it is active and running. I also change to "stein" branch and try to deploy again, but still meet the same problem. Does someone meet similar issue before or could someone help me to debug this issue? Below is my local.conf file. Thank you! local.conf: #################################################### [[local|localrc]] # Credentials ADMIN_PASSWORD=password DATABASE_PASSWORD=password RABBIT_PASSWORD=password SERVICE_PASSWORD=password SERVICE_TOKEN=password SWIFT_HASH=password SWIFT_TEMPURL_KEY=password GIT_BASE=${GIT_BASE:-https://git.openstack.org} # A clean install every time RECLONE=yes # Enable Ironic plugin IRONIC_USING_PLUGIN=true enable_plugin ironic git://github.com/openstack/ironic # Enable Tempest enable_service tempest # Disable nova novnc service, ironic does not support it anyway. disable_service n-novnc # Enable Swift for the direct deploy interface. enable_service s-proxy enable_service s-object enable_service s-container enable_service s-account enable_service placement-api enable_service placement-client # Disable Horizon disable_service horizon # Disable Cinder disable_service cinder c-sch c-api c-vol # Swift temp URL's are required for the direct deploy interface SWIFT_ENABLE_TEMPURLS=True # Tempest related options BUILD_TIMEOUT=3000 IRONIC_CALLBACK_TIMEOUT=3000 POWER_TIMEOUT=600 SERVICE_TIMEOUT=600 TEMPEST_PLUGINS+=' /opt/stack/ironic-tempest-plugin' # Ironic related options IRONIC_IS_HARDWARE=true VIRT_DRIVER=ironic IRONIC_HW_NODE_CPU=1 IRONIC_HW_NODE_RAM=4096 IRONIC_HW_NODE_DISK=20 IRONIC_BAREMETAL_BASIC_OPS=True DEFAULT_INSTANCE_TYPE=baremetal # Enable additional hardware types, if needed. IRONIC_ENABLED_HARDWARE_TYPES=ipmi,fake-hardware,xclarity # Don't forget that many hardware types require enabling of additional # interfaces, most often power and management: IRONIC_ENABLED_MANAGEMENT_INTERFACES=ipmitool,fake,xclarity IRONIC_ENABLED_POWER_INTERFACES=ipmitool,fake,xclarity # The 'ipmi' hardware type's default deploy interface is 'iscsi'. # This would change the default to 'direct': #IRONIC_DEFAULT_DEPLOY_INTERFACE=direct # Change this to alter the default driver for nodes created by devstack. # This driver should be in the enabled list above. IRONIC_DEPLOY_DRIVER=ipmi # The parameters below represent the minimum possible values to create # functional nodes. #IRONIC_VM_SPECS_RAM=1280 #IRONIC_VM_SPECS_DISK=10 # Size of the ephemeral partition in GB. Use 0 for no ephemeral partition. IRONIC_VM_EPHEMERAL_DISK=0 # By default, DevStack creates a 10.0.0.0/24 network for instances. # If this overlaps with the hosts network, you may adjust with the # following. PUBLIC_NETWORK_GATEWAY=10.240.24.1 FLOATING_RANGE=10.240.24.0/24 FIXED_RANGE=10.0.0.0/24 HOST_IP=10.240.24.138 SERVICE_HOST=$HOST_IP FIXED_NETWORK_SIZE=256 # Neutron options Q_USE_PROVIDERNET_FOR_PUBLIC=True PUBLIC_INTERFACE=ens9 OVS_PHYSICAL_BRIDGE=br-ens9 PUBLIC_BRIDGE=br-ens9 OVS_BRIDGE_MAPPINGS=public:br-ens9 ALLOCATION_POOL=start=10.0.0.30,end=10.0.0.100 # Log all output to files LOGFILE=/opt/stack/devstack.log LOGDIR=/opt/stack/logs IRONIC_VM_LOG_DIR=/opt/stack/ironic-bm-logs #################################################### Best Regards, Guannan

3 2

[auto-scaling] Auto-scaling SIG update
by Rico Lin 10 Jul '19

10 Jul '19

It has been two months after Summit and PTG [3], and we now have collected some use cases [1], and general documents for auto-scaling [2] (Great thanks to Joseph Davis and Adam Spiers). *Use Cases needed* We need more use cases from all, for autoscaling on/with OpenStack. For example, autoscaling k8s on OpenStack is already a thing, so IMO we need to put some words in use cases too. *Help to improve documents* Please check our new document and help to improve it if you think of any. *Join us* We have IRC channel and meeting so please join us in irc: #openstack-auto-scaling so we can hear you and you can help us. *Add request to our StoryBoard* If you have any feature requests or WIP plan, you can use our storyboard[4] as root trace for them all like request for `Integrate Monasca and Senlin`. *Open for bug?* One question I would like to bring to the team is should we open our storyboard[4] for bug collection? We have some good hands from multiple teams, who can help with bugs. And like feature requests, a top-level story for a bug should be very helpful, but what we need from the reporter in order to get better information about that bug, and also what part should we help? IMO we can make sure bug are well documented, trace bug progress (from top-level view), and help to raise attention(in ML and in events). Would like to hear more opinions on this. *PTG* I already sign up for half-day PTG schedule(as the team still under developing, I would not expect that we need more for now), so I see you all there if you will be there too! [1] https://docs.openstack.org/auto-scaling-sig/latest/use-cases.html [2] https://docs.openstack.org/auto-scaling-sig/latest/theory-of-auto-scaling.h… [3] https://etherpad.openstack.org/p/DEN-auto-scaling-SIG [4] https://storyboard.openstack.org/#!/project/openstack/auto-scaling-sig [5] https://storyboard.openstack.org/#!/story/2005627 -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

2 1

[tc] Assuming control of GitHub organizations
by Jim Rollenhagen 10 Jul '19

10 Jul '19

Hi, The opendev team reached out to me about handing off administrative access of the "openstack" and related organizations on GitHub. They think it would be best if the TC took control of that, or at least took control of delegating that access. In general, the goal here is to support OpenStack's presence and visibility on GitHub. Per Jim Blair: > In the long run, this shouldn't entail a lot of work, generally creating new > repos on GitHub to accept mirroring from opendev systems, performing renames, > handling transfer requests when repos move out of the openstack namespace, > setting and updating descriptions, and curating the list of pinned > repositories. In the short term, we have some archiving and moving to do.[0] Do TC members want to manage this, or should we delegate? One thing to figure out is how to grant that access. The opendev team uses a shared account with two-factor authentication provided by a shared shell account. This mitigates accidental pushes or settings changes when an admin is using their usual GitHub account. The TC (or its delegates) probably doesn't have a shared shell account to do this with. Some options: * each admin creates a second GitHub account for this purpose use a shared * account without 2FA use a shared account with 2FA, share the one time secret * with everyone to configure their own token generator use personal accounts * but be very careful Thoughts on these options? [0] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006829.html // jim

8 15