January 2019 - openstack-discuss - lists.openstack.org

[TripleO] containers logging to stdout
by Juan Antonio Osorio Robles 08 Feb '19

08 Feb '19

Hello! In Queens, the a spec to provide the option to make containers log to standard output was proposed [1] [2]. Some work was done on that side, but due to the lack of traction, it wasn't completed. With the Train release coming, I think it would be a good idea to revive this effort, but make logging to stdout the default in that release. This would allow several benefits: * All logging from the containers would en up in journald; this would make it easier for us to forward the logs, instead of having to keep track of the different directories in /var/log/containers * The journald driver would add metadata to the logs about the container (we would automatically get what container ID issued the logs). * This wouldo also simplify the stacks (removing the Logging nested stack which is present in several templates). * Finally... if at some point we move towards kubernetes (or something in between), managing our containers, it would work with their logging tooling as well. Any thoughts? [1] https://specs.openstack.org/openstack/tripleo-specs/specs/queens/logging-st… [2] https://blueprints.launchpad.net/tripleo/+spec/logging-stdout-rsyslog

7 11

[ironic] Hardware leasing with Ironic
by Lars Kellogg-Stedman 07 Feb '19

07 Feb '19

Howdy. I'm working with a group of people who are interested in enabling some form of baremetal leasing/reservations using Ironic. There are three key features we're looking for that aren't (maybe?) available right now: - multi-tenancy: in addition to the ironic administrator, we need to be able to define a node "owner" (someone who controls a specific node) and a node "consumer" (someone who has been granted temporary access to a specific node). An "owner" always has the ability to control node power or access the console, can mark a node as available or not, and can set lease policies (such as a maximum lease lifetime) for a node. A "consumer" is granted access to power control and console only when they hold an active lease, and otherwise has no control over the node. - leasing: a mechanism for marking nodes as available, requesting nodes for a specific length of time, and returning those nodes to the available pool when a lease has expired. - hardware only: we'd like the ability to leave os provisioning up to the "consumer". For example, after someone acquires a node via the leasing mechanism, they can use Foreman to provisioning an os onto the node. For example, a workflow might look something like this: - The owner of a baremetal node makes the node part of a pool of available hardware. They set a maximum lease lifetime of 5 days. - A consumer issues a lease request for "3 nodes with >= 48GB of memory and >= 1 GPU" and "1 node with >= 16GB of memory and >= 1TB of local disk", with a required lease time of 3 days. - The leasing system finds available nodes matching the hardware requirements and with owner-set lease policies matching the lease lifetime requirements. - The baremetal nodes are assigned to the consumer, who can then attach them to networks and make use of their own provisioning tools (which may be another Ironic instance?) to manage the hardware. The consumer is able to control power on these nodes and access the serial console. - At the end of the lease, the nodes are wiped and returned to the pool of available hardware. The previous consumer no longer has any access to the nodes. Our initial thought is to implement this as a service that sits in front of Ironic and provides the multi-tenancy and policy logic, while using Ironic to actually control the hardware. Does this seem like a reasonable path forward? On paper there's a lot of overlap here between what we want and features provided by things like the Nova schedulers or the Placement api, but it's not clear we can leverage those at the baremetal layer. Thanks for your thoughts, -- Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ |

7 21

[tc] agenda for upcoming TC meeting on 7 Feb
by Doug Hellmann 07 Feb '19

07 Feb '19

TC Members, Our next meeting will be on Thursday, 7 Feb at 1400 UTC in #openstack-tc. This email contains the agenda for the meeting. If you will not be able to attend, please include your name in the "Apologies for Absence" section of the wiki page [0]. * corrections to TC member election section of bylaws are completed (fungi, dhellmann) * status update for project team evaluations based on technical vision (cdent, TheJulia) * defining the role of the TC (cdent, ttx) * keeping up with python 3 releases (dhellmann, gmann) * status update of Train cycle goals selection update (lbragstad, evrardjp) * TC governance resolution voting procedures (dhellmann) * upcoming TC election (dhellmann) * review proposed OIP acceptance criteria (dhellmann, wendar) * TC goals for Stein (dhellmann) [0] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee -- Doug

1 1

[openstack-ansible][magnum]
by Alfredo De Luca 07 Feb '19

07 Feb '19

Hi all. I finally instaledl successufully openstack ansible (queens) but, after creating a cluster template I create k8s cluster, it stuck on kube_masters <https://10.1.8.113/project/stacks/stack/6221608c-e7f1-4d76-b694-cdd7ec22c38…> b7204f0c-b9d8-4ef2-8f0b-afe4c077d039 <https://10.1.8.113/project/stacks/stack/b7204f0c-b9d8-4ef2-8f0b-afe4c077d03…> OS::Heat::ResourceGroup 16 minutes Create In Progress state changedcreate in progress....and after around an hour it says...time out. k8s master seems to be up.....at least as VM. any idea? *Alfredo*

5 43

[openstack-helm] How to specify nova override for multiple pci alias
by Gauld, James 06 Feb '19

06 Feb '19

How can I specify a helm override to configure nova PCI alias when there are multiple aliases? I haven't been able to come up with a YAML compliant specification for this. Are there other alternatives to be able to specify this as an override? I assume that a nova Chart change would be required to support this custom one-alias-entry-per-line formatting. Any insights on how to achieve this in helm are welcomed. Background: There is a limitation in the nova.conf specification of PCI alias in that it does not allow multiple PCI aliases as a list. The code says "Supports multiple aliases by repeating the option (not by specifying a list value)". Basically nova currently only supports one-alias-entry-per-line format. Ideally I would specify global pci alias in a format similar to what can be achieved with PCI passthrough_whitelist, which can takes JSON list of dictionaries. This is what I am trying to specify in nova.conf (i.e., for nova-api-osapi and nova-compute): [pci] alias = {dict 1} alias = {dict 2} . . . The following nova configuration format is desired, but not as yet supported by nova: [pci] alias = [{dict 1}, {dict 2}] The following snippet of YAML works for PCI passthrough_whitelist, where the value encoded is a JSON string: conf: nova: overrides: nova_compute: hosts: - conf: nova: pci: passthrough_whitelist: '[{"class_id": "030000", "address": "0000:00:02.0"}]' Jim Gauld

3 5

[nova] [placement] [packaging] placement extraction check in meeting
by Chris Dent 06 Feb '19

06 Feb '19

As discussed in the recent pupdate [1] there will be a meeting this Wednesday at 1700 UTC to discuss the current state of the placement extraction and get some idea on the critical items that need to be addressed to feel comfy. If you're interested in this topic, meet near that time in the #openstack-placement IRC channel and someone will produce links for a hangout, etherpad, whatever is required. Thanks. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001666.… -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

6 13

[openstack-dev] [stackalytics] Stackalytics Facelift
by Boris Renski 06 Feb '19

06 Feb '19

Folks, Happy New Year! We wanted to start the year by giving a facelift to stackalytics.com (based on stackalytics openstack project). Brief summary of updates: - We have new look and feel at stackalytics.com - We did away with DriverLog <http://stackalytics.com/report/driverlog> and Member Directory <http://stackalytics.com/report/members>, which were not very actively used or maintained. Those are still available via direct links, but not in the men on the top - BIGGEST CHANGE: You can now track some of the CNCF and Unaffiliated project commits via a separate subsection accessible at the top nav. Before this was all bunched up in Project Type -> Complimentary Happy to hear comments or feedback or answer questions. -Boris

6 10

[tc][all] Project deletion community goal for Train cycle
by Adrian Turjak 06 Feb '19

06 Feb '19

Hello OpenStackers! As discussed at the Berlin Summit, one of the proposed community goals was project deletion and resource clean-up. Essentially the problem here is that for almost any company that is running OpenStack we run into the issue of how to delete a project and all the resources associated with that project. What we need is an OpenStack wide solution that every project supports which allows operators of OpenStack to delete everything related to a given project. Before we can choose this as a goal, we need to define what the actual proposed solution is, and what each service is either implementing or contributing to. I've started an Etherpad here: https://etherpad.openstack.org/p/community-goal-project-deletion Please add to it if I've missed anything about the problem description, or to flesh out the proposed solutions, but try to mostly keep any discussion here on the mailing list, so that the Etherpad can hopefully be more of a summary of where the discussions have led. This is mostly a starting point, and I expect there to be a lot of opinions and probably some push back from doing anything too big. That said, this is a major issue in OpenStack, and something we really do need because OpenStack is too big and too complicated for this not to exist in a smart cross-project manner. Let's solve this the best we can! Cheers, Adrian Turjak

7 15

[neutron] OVS OpenFlow L3 DVR / dvr_bridge agent_mode
by Duarte Cardoso, Igor 05 Feb '19

05 Feb '19

Hi Neutron, I've been internally collaborating on the ``dvr_bridge`` L3 agent mode [1][2][3] work (David Shaughnessy, Xubo Zhang), which allows the L3 agent to make use of Open vSwitch / OpenFlow to implement ``distributed`` IPv4 Routers thus bypassing kernel namespaces and iptables and opening the door for higher performance by keeping packets in OVS for longer. I want to share a few questions in order to gather feedback from you. I understand parts of these questions may have been answered in the past before my involvement, but I believe it's still important to revisit and clarify them. This can impact how long it's going to take to complete the work and whether it can make it to stein-3. 1. Should OVS support also be added to the legacy router? And if so, would it make more sense to have a new variable (not ``agent_mode``) to specify what backend to use (OVS or kernel) instead of creating more combinations? 2. What is expected in terms of CI for this? Regarding testing, what should this first patch include apart from the unit tests? (since the l3_agent.ini needs to be configured differently). 3. What problems can be anticipated by having the same agent managing both kernel and OVS powered routers (depending on whether they were created as ``distributed``)? We are experimenting with different ways of decoupling RouterInfo (mainly as part of the L3 agent refactor patch) and haven't been able to find the right balance yet. On one end we have an agent that is still coupled with kernel-based RouterInfo, and on the other end we have an agent that either only accepts OVS-based RouterInfos or only kernel-based RouterInfos depending on the ``agent_mode``. We'd also appreciate reviews on the 2 patches [4][5]. The L3 refactor one should be able to pass Zuul after a recheck. [1] Spec: https://blueprints.launchpad.net/neutron/+spec/openflow-based-dvr [2] RFE: https://bugs.launchpad.net/neutron/+bug/1705536 [3] Gerrit topic: https://review.openstack.org/#/q/topic:dvr_bridge+(status:open+OR+status:me… [4] L3 agent refactor patch: https://review.openstack.org/#/c/528336/29 [5] dvr_bridge patch: https://review.openstack.org/#/c/472289/17 Thank you! Best regards, Igor D.C.

5 6

[openstack-dev] [Neutron] Propose Liu Yulong for Neutron core
by Miguel Lavalle 05 Feb '19

05 Feb '19

Hi Stackers, I want to nominate Liu Yulong (irc: liuyulong) as a member of the Neutron core team. Liu started contributing to Neutron back in Mitaka, fixing bugs in HA routers. Since then, he has specialized in L3 networking, developing a deep knowledge of DVR. More recently, he single handedly implemented QoS for floating IPs with this series of patches: https://review.openstack.org/#/q/topic:bp/floating-ip-rate-limit+(status:op…. He has also been very busy helping to improve the implementation of port forwardings and adding QoS to them. He also works for a large operator in China, which allows him to bring an important operational perspective from that part of the world to our project. The quality and number of his code reviews during the Stein cycle is on par with the leading members of the core team: https://www.stackalytics.com/?module=neutron-group. I will keep this nomination open for a week as customary. Best regards Miguel

7 7