June 2021 - openstack-discuss - lists.openstack.org

[kolla] Reorganization of kolla-ansible documentation
by Klemen Pogacnik 03 Jun '21

03 Jun '21

Hello! I promised to prepare my view as a user of kolla-ansible on its documentation. In my opinion the division between admin guides and user guides is artificial, as the user of kolla-ansible is actually the cloud administrator. Maybe it would be good to think about reorganizing the structure of documentation. Many good chapters are already written, they only have to be positioned in the right place to be found more easily. So here is my proposal of kolla-ansible doc's structure: 1. Introduction 1.1. mission 1.2. benefits 1.3. support matrix 2. Architecture 2.1. basic architecture 2.2. HA architecture 2.3. network architecture 2.4. storage architecture 3. Workflows 3.1. preparing the surroundings (networking, docker registry, ...) 3.2. preparing servers (packages installation) 3.3. configuration (of kolla-ansible and description of basic logic for configuration of Openstack modules) 3.4. 1st day procedures (bootstrap, deploy, destroy) 3.5. 2nd day procedures (reconfigure, upgrade, add, remove nodes ...) 3.6. multiple regions 3.7. multiple cloud 3.8. security 3.9. troubleshooting (how to check, if cloud works, what to do, if it doesn't) 4. Use Cases 4.1. all-in-one 4.2. basic vm multinode 4.3. some production use cases 5. Reference guide Mostly the same structure as already is. Except it would be desirable that description of each module has: - purpose of the module - configuration of the module - how to use it with links to module docs - basic troubleshooting 6. Contributor guide The documentation also needs figures, pictures, diagrams to be more understandable. So at least in the first chapters some of them shall be added. I'm also thinking about convergence of documentation of kayobe, kolla and kolla-ansible projects. It's true that there's no strict connection between kayobe and other two and kolla containers can be used without kolla-ansible playbooks. But the real benefit the user can get is to use all three projects together. But let's leave that for the second phase. So please comment on this proposal. Do you think it's going in the right direction? If yes, I can refine it.

2 2

[TripleO] tripleo repos going Extended Maintenance stable/train OK? (not yet IMO)
by Marios Andreou 03 Jun '21

03 Jun '21

Hello TripleO o/ per [1] and the proposal at [2] the stable/train branch for all tripleo repos [3] is going to transition to extended maintenance [4]. Once [2] merges, we can still merge things to stable/train but it means we can no longer make official openstack tagged releases for stable/train. TripleO is a trailing project so if we want to hold on this for a while longer I think that is OK and that would also be my personal preference. >From a quick check just now e.g. tripleo-heat-templates @ [5] and at current time there are 87 commits since last September which isn't a tiny amount. So I don't think TripleO is ready to declare stable/train as extended maintenance, but perhaps I am wrong, what do you think? Please comment here or directly at [2] if you prefer regards, marios [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022287.html [2] https://review.opendev.org/c/openstack/releases/+/790778/2#message-e981f749… [3] https://releases.openstack.org/teams/tripleo.html#train [4] https://docs.openstack.org/project-team-guide/stable-branches.html#maintena… [5] https://github.com/openstack/tripleo-heat-templates/compare/11.5.0...stable…

2 3

[wallaby][nova] Change Time Zone
by Malik Obaid 03 Jun '21

03 Jun '21

2 1

[kolla] [kolla-ansible] fluentd doesn't forward OpenStack logs to Elasticsearch
by Bernd Bausch 03 Jun '21

03 Jun '21

I might have found a bug in Kolla-Ansible (Victoria version) but don't know where to file it. This is about central logging. In my installation, none of the interesting logs (Nova, Cinder, Neutron...) are sent to Elasticsearch. I confirmed that using tcpdump. I found that fluentd's config file /etc/kolla/fluentd/td-agent.conf tags these logs with "kolla.*". But later in the file, one finds filters like this: # Included from conf/filter/01-rewrite-0.14.conf.j2: <match kolla.var.log.kolla.*.*.log> @type rewrite_tag_filter capitalize_regex_backreference yes ... <rule> key programname pattern ^(nova-api|nova-compute|nova-compute-ironic|nova-conductor|nova-manage|nova-novncproxy|nova-scheduler|nova-placement-api|placement-api|privsep-helper)$ tag openstack_python </rule> If I understand this right, this basically re-tags all nova logs with "openstack_python". The same config file has an output rule at the very end. I think the intention is to make this a catch-all rule (or "match anything else"): # Included from conf/output/01-es.conf.j2: <match *.**> @type copy <store> @type elasticsearch host 192.168.122.209 port 9200 scheme http etc. Unfortunately, the /openstack_python/ tag doesn't match /*.**/, since it contains no dot. I fixed this with <match **>. Now I receive all logs, but I am not sure if this is the right way to fix it. The error, if it is one, is in https://opendev.org/openstack/kolla-ansible/src/branch/master/ansible/roles…. If you want me to file a bug, please let me know how. Bernd.

2 3

[largescale-sig] Next meeting: June 2, 15utc
by Thierry Carrez 03 Jun '21

03 Jun '21

Hi everyone, Our next Large Scale SIG meeting will be this Wednesday in #openstack-meeting-3 on OFTC IRC, at 15UTC. You can doublecheck how it translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210602T15 Note that we changed IRC networks, you should now connect to OFTC[1] rather than Freenode servers. [1] https://www.oftc.net/ A number of topics have already been added to the agenda, including discussing our next OpenInfra.Live show. Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1

[neutron] Drivers meetning 04.06.2021 - agenda
by Slawek Kaplonski 03 Jun '21

03 Jun '21

Hi, We have one new RFE to discuss on the tomorrows drivers meeting: https://bugs.launchpad.net/neutron/+bug/1930200 - [RFE] Add support for Node-Local virtual IP[1] Please check it, ask any questions You will have regarding this proposal and see You on the meeting tomorrow. -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://bugs.launchpad.net/neutron/+bug/1930200 - [RFE] Add support for Node-Local virtual IP

1 0

[all][tc] Technical Committee next weekly meeting on June 3rd at 1500 UTC
by Ghanshyam Mann 03 Jun '21

03 Jun '21

Hello Everyone, NOTE: FROM THIS WEEK ONWARDS, TC MEETINGS WILL BE HELD IN #openstack-tc CHANNEL ON OFTC NETWORK (NOT FREENODE) Technical Committee's next weekly meeting is scheduled for June 3rd at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, June 2nd, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[ops] rabbitmq queues for nova versioned notifications queues keep filling up
by Ajay Tikoo (BLOOMBERG/ 120 PARK) 02 Jun '21

02 Jun '21

I am not sure if this is the right channel/format to post this question, so my apologies in advance if this is not the right place. We are using Openstack Rocky. Watcher needs versioned notifications to be enabled. However after enabling versioned notifications, the queues for versioned_notifications (info and error) keep filling up Based on the updates the the Watchers cluster data model, it appears that Watcher is consuming messages, but they still linger in these queues. So with nova versioned notifications disabled, Watcher is unable to update the cluster data model (between rebuild intervals), and with them enabled, it keeps filling up the MQ queues. What is the best way to resolve this? Thank you, Ajay Tikoo

1 0

Is the server Action Log immutable?
by Linebarger, John 02 Jun '21

02 Jun '21

Hello! Is the server Action Log absolutely immutable? Meaning, if you make a mistake in handling a server (VM) and it shows up in the Action Log, is there any way to remove that entry? I understand that the Action Log is kept in a database but am searching in vain for an API call that will allow such entries to be modified or deleted as opposed to merely displayed. What workarounds might exist? Thanks! Enjoy! John M. Linebarger, PhD, MBA Principal Member of Technical Staff Sandia National Laboratories (Office) 505-845-8282

2 1

[nova] Proper way to regenerate request_specs of existing instances?
by Patryk Jakuszew 02 Jun '21

02 Jun '21

Hi! I have a Rocky deployment and I want to enable AggregateInstanceExtraSpecsFilter on it. There is one slight problem I'm trying to solve in a proper way: fixing the request_specs of instances that are already running. After enabling the filter, I want to add necessary metadata keys to flavors, but this won't be propagated into request_specs of running instances, and this will cause issues later on (like scheduler selecting wrong destination hosts for migration, for example) Few years ago I encountered a similar problem on Mitaka: that deployment already had the filter enabled, but some flavors were misconfigured and lacked the metadata keys. I ended up writing a crude Python script which connected directly into the Nova database, searched for bad request_specs and manually appended the necessary extra_specs keys into request_specs JSON blob. Now, my question is: has anyone encountered a similar scenario before? Is there a more clean method for regeneration of instance request_specs, or do I have to modify the JSON blobs manually by writing directly into the database? -- Regards, Patryk Jakuszew

3 4