- openstack-discuss - lists.openstack.org

[Openstack] [OpenStack][Cinder] Config Volumes to Store on Compute nodes
by Soheil Pourbafrani 26 Nov '18

26 Nov '18

Hi, I want to configure cinder to store Volumes on the Compute nodes. I know I should use the InstanceLocalityFilter. Suppose we have one Controller and two Compute node, should I install the Cinder on each node (Controller and Compute)? I will be appreciated if you suggest me any instruction about this. Thanks! _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

1 0

[Openstack] [openstack][neutron]Iptables snat not work when securitygroup is on
by 陈炤 25 Nov '18

25 Nov '18

Hi, I am building an openstack all-in-one environment in a CentOS7.4 machine. For some reason I have only one network interface(eth0) and one ip address, so I created a linux bridge(br0), and forwarded datas to eth0 using iptables command: iptables -t nat -A POSTROUTING -s {bridge virtual ip} -j SNAT --to {eth0 ip} But it seems not work. When I ping to 8.8.8.8 from br0 and run tcpdump, I can see that datas can be forwared to eth0 and be sent to 8.8.8.8, but when datas are sent back to eth0, they can not be forwarded to br0. Ip forwarding, net.bridge.bridge-nf-call-iptables and net.bridge.bridge-nf-call-ip6tablesare set to 1. If I close security group by setting securitygroup = false, this rule works fine, but if I use iptables -F instead, the rule is not work. Does the securitygroup have a magic to trap iptables? BR Don _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

2 1

[openstack-dev] [kolla] Berlin summit resume
by Eduardo Gonzalez 25 Nov '18

25 Nov '18

Hi kollagues, During the Berlin Summit kolla team had a few talks and forum discussions, as well as other cross-project related topics [0] First session was ``Kolla project onboarding``, the room was full of people interested in contribute to kolla, many of them already using kolla in production environments whiling to make upstream some work they've done downstream. I can say this talk was a total success and we hope to see many new faces during this release putting features and bug fixes into kolla. Slides of the session at [1] Second session was ``Kolla project update``, was a brief resume of what work has been done during rocky release and some items will be implemented in the future. Number of attendees to this session was massive, no more people could enter the room. Slides at [2] Then forum sessions.. First one was ``Kolla user feedback``, many users came over the room. We've notice a big increase in production deployments and some PoC migrating to production soon, many of those environments are huge. Overall the impressions was that kolla is great and don't have any big issue or requirement, ``it works great`` became a common phrase to listen. Here's a resume of the user feedback needs [3] - Improve operational usage for add, remove, change and stop/start nodes and services. - Database backup and recovery - Lack of documentation is the bigger request, users need to read the code to know how to configure other than core/default services - Multi cells_v2 - New services request, cyborg, masakari and tricircle were the most requested - SElinux enabled - More SDN services such as Contrail and calico - Possibility to include user's ansible tasks during deploy as well as support custom config.json - HTTPS for internal networks Second one was about ``kolla for the edge``, we've meet with Edge computing group and others interested in edge deployments to identify what's missing in kolla and where we can help. Things we've identified are: - Kolla seems good at how the service split can be done, tweaking inventory file and config values can deploy independent environments easily. - Missing keystone federation - Glance cache support is not a hard requirement but improves efficiency (already merged) - Multi cells v2 - Multi storage per edge/far-edge - A documentation or architecture reference would be nice to have. Last one was ``kolla for NFV``, few people came over to discuss about NUMA, GPU, SRIOV. Nothing noticiable from this session, mainly was support DPDK for CentOS/RHEL,OracleLinux and few service addition covered by previous discussions. [0] https://etherpad.openstack.org/p/kolla-stein-summit [1] https://es.slideshare.net/EduardoGonzalezGutie/kolla-project-onboarding-ope… [2] https://es.slideshare.net/EduardoGonzalezGutie/openstack-kolla-project-upda… [3] https://etherpad.openstack.org/p/berlin-2018-kolla-user-feedback [4] https://etherpad.openstack.org/p/berlin-2018-kolla-edge [5] https://etherpad.openstack.org/p/berlin-2018-kolla-nfv __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

3 2

[Openstack] [OpenStack][Glance]Getting instance snapshot result in size 0 byte
by Soheil Pourbafrani 24 Nov '18

24 Nov '18

Hi, I have many instances running on OpenStack and I wanted to export them. So I create a snapshot of an instance and it results in a new record in images in the format of Qcow2 and size of 0 bytes! It just created a volume snapshot of the instance, too. I tried with both command line and horizon but the same results! How can I export instances in the correct way? _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

2 1

[Openstack] [OpenStack][Keystone] the controller is node listening on port 5000
by Soheil Pourbafrani 24 Nov '18

24 Nov '18

Hi, I installed keystone step by step according to the OpenStack Doc <https://docs.openstack.org/keystone/rocky/install/keystone-install-rdo.html> but the http server is not listening on the port 5000! The only difference is my hostname (address) is "controller.a.b" instead of "controller". In verifying part of the document I could do all (like creating a user, project, ....) but after installing glance, I found out the Glance API is not running properly and it's because of Keystone is not listening on port 5000! Here are AUTH variables: export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_NAME=admin export OS_USERNAME=admin export OS_PASSWORD=XXX export OS_AUTH_URL=http://controller.a.b:5000/v3 export OS_IDENTITY_API_VERSION=3 export OS_IMAGE_API_VERSION=2 When I try "glance image-list", I got: "http://controller.a.b:9292/v2/images?limit=20&sort_key=name&sort_dir=asc: Unable to establish connection" Here is TCP listening ports: tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1614/master tcp 0 0 0.0.0.0:9191 0.0.0.0:* LISTEN 961/python2 tcp 0 0 0.0.0.0:25672 0.0.0.0:* LISTEN 957/beam.smp tcp 0 0 192.168.0.31:3306 0.0.0.0:* LISTEN 1622/mysqld tcp 0 0 192.168.0.31:2379 0.0.0.0:* LISTEN 963/etcd tcp 0 0 192.168.0.31:11211 0.0.0.0:* LISTEN 952/memcached tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 952/memcached tcp 0 0 192.168.0.31:2380 0.0.0.0:* LISTEN 963/etcd tcp 0 0 0.0.0.0:4369 0.0.0.0:* LISTEN 1/systemd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 953/sshd tcp6 0 0 ::1:25 :::* LISTEN 1614/master tcp6 0 0 :::5000 :::* LISTEN 960/httpd tcp6 0 0 :::5672 :::* LISTEN 957/beam.smp tcp6 0 0 ::1:11211 :::* LISTEN 952/memcached tcp6 0 0 :::80 :::* LISTEN 960/httpd tcp6 0 0 :::22 :::* LISTEN 953/sshd As you can see httpd is listening on port 5000 IPV6, but it's not active for IPV4! Here is keystone.log: 2018-11-24 15:55:59.685 17325 INFO keystone.common.wsgi [req-9fedd505-5d98-4c12-a6ad-967f28c766e7 - - - - -] POST http://controller.a.b:5000/v3/auth/tokens 2018-11-24 15:56:00.275 17327 INFO keystone.common.wsgi [req-ca93da87-1d9f-4611-835c-d6972054b8e1 - - - - -] POST http://controller.a.b:5000/v3/auth/tokens 2018-11-24 15:56:00.929 17328 INFO keystone.common.wsgi [req-cf8c6af8-342d-4b14-9826-ba27e5f2897a 1b96f6b67f08495092e98a9b60476152 b33579097090499499625154e92724ee - default default] GET http://controller.a.b:5000/v3/domains/default 2018-11-24 15:56:14.753 17325 INFO keystone.common.wsgi [req-cca0e4a5-0ef9-40d8-a2f4-56c1f0acafcc 1b96f6b67f08495092e98a9b60476152 b33579097090499499625154e92724ee - default default] POST http://controller.a.b:5000/v3/users 2018-11-24 15:56:14.773 17325 WARNING py.warnings [req-cca0e4a5-0ef9-40d8-a2f4-56c1f0acafcc 1b96f6b67f08495092e98a9b60476152 b33579097090499499625154e92724ee - default default] /usr/lib/python2.7/site-packages/oslo_policy/policy.py:896: UserWarning: Policy identity:create_user failed scope check. The token used to make the request was project scoped but the policy requires ['system'] scope. This behavior may change in the future where using the intended scope is required warnings.warn(msg) Another difference between my system and document is that I use static IP and here are interface settings: TYPE="Ethernet" PROXY_METHOD="none" BROWSER_ONLY="no" BOOTPROTO="none" DEFROUTE="yes" IPV4_FAILURE_FATAL="no" IPV6INIT="yes" IPV6_AUTOCONF="yes" IPV6_DEFROUTE="yes" IPV6_FAILURE_FATAL="no" IPV6_ADDR_GEN_MODE="stable-privacy" NAME="enp2s0" UUID="62aa5ce8-64da-41b4-abd3-293fd43584fa" DEVICE="enp2s0" ONBOOT="yes" IPADDR="192.168.0.X" PREFIX="24" GATEWAY="192.168.0.1" DNS1="192.168.0.1" DNS2="8.8.8.8" IPV6_PRIVACY="no" What can be the cause? _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

1 0

[oslo] [config] Using environment variables for config options
by Chris Dent 24 Nov '18

24 Nov '18

I don't recall seeing any specific announcement for this, and I think it is a pretty useful feature, so I thought I'd write about some functionality that I added to oslo.config and was released in 6.7.0. Especially since a lot of people I've mentioned this to thought we already had it. The new version is able to satisfy any registered config option by looking in the process environment for a variable with a predictable name and using its value if set. Options are satisfied in this order: * command line args * environment * config file(s) * everything else (using the new(ish) "sources" concept) In the past it was possible to get config from the environment if the option had been pre-defined as using something in the environment as its default. This new way is much more flexible, and in my experience ideal for container-based environments where you would like an immutable container but want small differences between multiple instances of the same container to be easy to control. Or if you don't need much config at all, you can avoid using a config file entirely. I've been using this with placement, where it's possible to set up a testable placement service with just two environment variables: OS_PLACEMENT_DATABASE__CONNECTION=mysql+pymysql://root:secret@127.0.0.1/placement?charset=utf8 OS_API__AUTH_STRATEGY=noauth2 This shows the pattern of the environment variable name: OS_<config group>__<config opt> There are some docs at https://docs.openstack.org/oslo.config/latest/reference/drivers.html#module… I hope this proves as useful for other people as it has for me. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

3 3

[Openstack-operators] urlopen error [Errno 113] No route to host
by Jawad Ahmed 24 Nov '18

24 Nov '18

Hi all, Has anyone come across this error with utility container.I am running CentOS7 with Queens. After running setup-infrastructure.yml getting into this error while rest is success.Any workaround ? internal_lb_vip_address: 172.25.30.101 fatal: [rmq-db_utility_container-8e503460]: FAILED! => {"changed": false, "content": "", "msg": "Status code was -1 and not [200]: Request failed: <urlopen error [Errno 113] No route to host>", "redirected": false, "status": -1, "url": " http://172.25.30.101:8181/os-releases/18.0.0/centos-7.5-x86_64/requirements… "} Thank you. -- Greetings, Jawad Ahmed _______________________________________________ OpenStack-operators mailing list OpenStack-operators(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

1 0

[forum] Summary of the "Better expose what we produce" session
by Thierry Carrez 23 Nov '18

23 Nov '18

Hi everyone, The OpenStack community produces a complex landscape of services and other deliverables. Presenting those to the rest of the world in a way that is comprehensive, makes sense and is not overwhelming has been a constant challenge. During this forum session in Berlin we presented the status of various efforts and websites, and discussed next steps. You can see the notes of the session at: https://etherpad.openstack.org/p/BER-better-expose-what-we-produce The plan going forward is to: 1. Continue improving the information presented on openstack.org/software and make more elements driven by the openstack/openstack-map repository YAML files. Immediate next steps include rolling out a new "Overview" page, providing an example YAML template, adding project update video links to the YAML for easier update, and finishing compiling "dependency" information from teams. We will also consider adding diagrams, although it creates a lot of consistency challenges. 2. Make the pages less about the teams and more about the software. That involves creating team pages (or enriching those from the governance website) and link to them instead of displaying information on the software page. 3. Brainstorm ways to move the "drivers list" (currently displayed in the "marketplace" using outdated data from stackalytics Drivers page) directly on the software page 4. For deployment tools, include data from the deployment tool comparison effort (discussed in another session), and consider making room for third-party tools as well. Also as a comparison point see https://kubernetes.io/docs/setup/pick-right-solution/ 5. For SDKs, include non-developed-locally language SDKs in a separate tab, and engage with the groups working on SDK certification / validation to see if there is any additional information we can show. Also as a comparison point see https://kubernetes.io/docs/reference/using-api/client-libraries/ Thanks ! -- Thierry Carrez (ttx)

4 3

Re: [Openstack-operators] Openstack zun on centos???
by Hongbin Lu 23 Nov '18

23 Nov '18

Hi Edoardo, It looks you gets your answer from others. I just want to add a few more comments. We (the Zun team) would like to have CentOS included in our installation guide and I have created a ticket for that: https://blueprints.launchpad.net/zun/+spec/installation-guide-for-centos . It will be picked up by contributors if someone interests to work on it. I expect the steps would be very similar as Ubuntu expect a few necessary tweaks. Right now, there is no Debian or RPM packages for Zun so we instruct users to install from source, which might be a bit painful. I would like to see Zun included in distro packages and I will see if we can recruit contributors to work on that, or I will work on that myself. Best regards, Hongbin On Wed, Nov 14, 2018 at 1:51 PM Ignazio Cassano <ignaziocassano(a)gmail.com> wrote: > Hi Edoardo, > does it mean openstack kolla installs zun using pip ? > I did not find any zun rpm package > Regards > Ignazio > > Il giorno Mer 14 Nov 2018 18:38 Eduardo Gonzalez <dabarren(a)gmail.com> ha > scritto: > >> Hi Cassano, you can use zun in centos deployed by kolla-ansible. >> >> https://docs.openstack.org/kolla-ansible/latest/reference/zun-guide.html >> >> Regards >> >> El mié., 14 nov. 2018 17:11, Ignazio Cassano <ignaziocassano(a)gmail.com> >> escribió: >> >>> Hi All, >>> I'd like to know if openstack zun will be released for centos. >>> Reading documentation at docs.openstack.org only ubuntu installation is >>> reported. >>> Many thanks >>> Ignazio >>> _______________________________________________ >>> OpenStack-operators mailing list >>> OpenStack-operators(a)lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >> _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > _______________________________________________ OpenStack-operators mailing list OpenStack-operators(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

1 0

[placement] update 18-47
by Chris Dent 23 Nov '18

23 Nov '18

HTML: https://anticdent.org/placement-update-18-47.html It's been a while since the last placement update. Summit happened. Seemed pretty okay, except for the food. People have things they'd like to do with placement. # Most Important We're starting to approach the point where we're thinking about the possibility of maybe turning off placement-in-nova. We're not there yet, and as is always the case with these kinds of things, it's the details at the end that present the challenges. As such there are a mass of changes spread around nova, placement, devstack, grenade, puppet and openstack-ansible related to making things go. More details on those below, but what we need is the same as ever: reviews. Don't be shy. If you're not a core or not familiar with placement, reviews are still very helpful. A lot of the patches take the form of "this _might_ be the right way to do this". # What's Changed There is now a placement-manage command which can do database migrations, driven by alembic. This means that the devstack patch which uses the extracted placement can merge soon. Several other testing related (turning on tempest and grenade for placement) changes depend-on that. Matt did a placement-status command which has a no-op we-are-here upgrade check. We've already met the python3 goals (I think?), so I reckon placement is good to go on community-wide goals. Woot. The PlacementFixture that placement provides for other projects to do functional tests with it has merged. There's a patch for [nova using it](https://review.openstack.org/#/c/617941/). The spec for [counting quota usage in placement](https://review.openstack.org/#/c/509042/) has been revived after learning at summit that a proposed workaround that didn't use placement wasn't really all that good for people using cells v2. # Bugs * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 17. +1. * [In progress placement bugs](https://goo.gl/vzGGDQ) 13. +2 # Specs Summit and U.S. Thanksgiving has disrupted progress on some of these, but there are still plenty of specs awaiting their future. _Many_ of these have unaddressed negative review comments. * <https://review.openstack.org/#/c/544683/> Account for host agg allocation ratio in placement (Still in rocky/) * <https://review.openstack.org/#/c/595236/> Add subtree filter for GET /resource_providers * <https://review.openstack.org/#/c/597601/> Resource provider - request group mapping in allocation candidate * <https://review.openstack.org/#/c/549067/> VMware: place instances on resource pool (still in rocky/) * <https://review.openstack.org/#/c/555081/> Standardize CPU resource tracking * <https://review.openstack.org/#/c/599957/> Allow overcommit of dedicated CPU (Has an alternative which changes allocations to a float) * <https://review.openstack.org/#/c/591037/> Modelling passthrough devices for report to placement * <https://review.openstack.org/#/c/603955/> Nova Cyborg interaction specification. * <https://review.openstack.org/#/c/601596/> supporting virtual NVDIMM devices * <https://review.openstack.org/#/c/603352/> Spec: Support filtering by forbidden aggregate * <https://review.openstack.org/#/c/552924/> Proposes NUMA topology with RPs * <https://review.openstack.org/#/c/569011/> Count quota based on resource class * <https://review.openstack.org/#/c/141219/> Adds spec for instance live resize * <https://review.openstack.org/#/c/612497/> Provider config YAML file * <https://review.openstack.org/#/c/509042/> Propose counting quota usage from placement and API database * <https://review.openstack.org/603545> Resource modeling in cyborg. # Main Themes ## Making Nested Useful Progress is being made on gpu-reshaping for libvirt and xen: * <https://review.openstack.org/#/q/topic:bp/reshape-provider-tree+status:open> Making use of nested is bandwidth-resource-provider: * <https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:…> Somewhat related to nested are a stack of changes to how often the ProviderTree in the resource tracker is checked against placement, and a variety of other "let's make this more right" changes in the same neighborhood: * Stack at: <https://review.openstack.org/#/c/615646/> ## Extraction (There's an [etherpad](https://etherpad.openstack.org/p/placement-extract-stein-4) which tracks some of the work related to extraction. Please refer to that for additional information.) TripleO and OpenStack-Ansible are both working on tooling to install and/or upgrade to extracted placement: * <https://review.openstack.org/#/q/topic:tripleo-placement-extraction> * <https://review.openstack.org/#/q/project:openstack/openstack-ansible-os_pla…> libvirt support for GPU reshaping: * <https://review.openstack.org/#/c/599208/> Grenade and tempest testing for extracted placement: * Extracted placement in devstack: <https://review.openstack.org/600162> * Turning on tests: <https://review.openstack.org/#/c/617565/> * Some fixes to grenade using python3: <https://review.openstack.org/#/c/619728/> A replacement for `placeload` performance testing that was in the `nova-next` job: <https://review.openstack.org/#/c/619248/>. This might be of interest to people trying to do testing of live services without devstack. It starts with a basic node, turns on mysql, runs placement with uwsgi, and does the placeload testing. Note that this found a pretty strange [bug in _ensure_aggregates](https://bugs.launchpad.net/nova/+bug/1804453). Documentation tuneups: * Front page: <https://review.openstack.org/#/c/619273/> * Release-notes: <https://review.openstack.org/#/c/618708/> This is blocked until we refactor the release notes to reflect _now_ better. * The main remaining task here is participating in [openstack-manuals](https://docs.openstack.org/doc-contrib-guide/doc-index.h…. We've been putting off making a decision about os-resource-classes. Anyone have strong opinions? # Other Besides the 20 or so [open changes](https://review.openstack.org/#/q/status:open+project:openstack/pla… in placement itself, and those mentioned above, here are some other changes that may be of interest. * <https://review.openstack.org/#/q/topic:bp/initial-allocation-ratios> Improve handling of default allocation ratios * <https://review.openstack.org/#/q/topic:minimum-bandwidth-allocation-placeme…> Neutron minimum bandwidth implementation * <https://review.openstack.org/#/c/602160/> Add OWNERSHIP $SERVICE traits * <https://review.openstack.org/#/c/586960/> zun: Use placement for unified resource management * <https://review.openstack.org/#/q/topic:cd/gabbi-tempest-job> Using gabbi-tempest for integration tests. * <https://review.openstack.org/#/q/project:openstack/blazar+topic:bp/placemen…> Blazar using the placement-api * <https://review.openstack.org/619626> Tenks doing some node management, with a bit of optional placement. * <https://review.openstack.org/617273> Extracted placement in loci * <https://review.openstack.org/#/c/613589/> Extracted placement in kolla * <https://review.openstack.org/#/c/613629/> Extracted placement in kolla-ansible # End Lot going on. Thanks to everyone for their contributions. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0