- openstack-discuss - lists.openstack.org

[openstack-dev] [nova] about filter the flavor
by Rambo 20 Nov '18

20 Nov '18

Hi,all I have an idea.Now we can't filter the special flavor according to the property.Can we achieve it?If we achieved this,we can filter the flavor according the property's key and value to filter the flavor. What do you think of the idea?Can you tell me more about this ?Thank you very much. __________________________________________________________________________ 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

2 1

[neutron] Allowing multiple segments from a routed network to the same host
by Kris G. Lindgren 20 Nov '18

20 Nov '18

Hello all, We have a use case where we need to allow multiple segments from the same routed network to a host. We have a spine-leaf L3 topology. Where the L2 domain exists only at the leaf level. In our use case we need to have multiple L2 vlans off the same switches pair mapped to all the servers on that switch. This is mainly done to split the L2 broadcast domains for that switch pair. Currently on our older clouds with non-routed networks we might have between 3 and 7 vlans each containing a /22 of ip address spacing, mapped to all the hosts on that switch. Where each of those vlans/subnets belong to the same L3 network segment, but are just used to keep the broadcast domains small on the switches. We are currently trying to implement the multi-segment to same host approach using ml2 + linuxbridge + vlan . We are running into a number of problems that we are working through, however before we go to much further I wanted to reach out and see if we are possibly just doing something wrong? Setup: 1.) Create a routed network with 2 segments, each segment is created with network_type: vlan with physical_network: fixed-net, using different vlans for the segments IE vlan 401 and vlan 402. 2.) Add one subnet per segment. 3.) Configure linuxbirdge agent - ml2.conf : [ml2] type_drivers = vlan tenant_network_types = vlan mechanism_drivers = linuxbridge extension_drivers = port_security [ml2_type_vlan] network_vlan_ranges = fixed-net:1:4095 [ml2_type_flat] flat_networks = physnet-mah [securitygroup] firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver [linux_bridge] #physical_interface_mappings = fixed-net:br0 bridge_mappings = fixed-net:br0 4.) Attempt to boot a vm Problems: 1.) The first issue that you hit will be the arbitrary more than 1 segment per host check that was added. If I remove: https://github.com/openstack/neutron/blob/master/neutron/objects/subnet.py#… The vm will boot with an ip from the first segment/subnet and everything is bound correctly. 2.) If I create a port on the second segment and boot the vm using that port. The vm will boot successfully using that port, however the HV br0.402 is not mapped into the bridge. The logs indicate that the port was bound using the first segment vlan 401. This is because https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/driver… receives 2 segments for network object, both segments are bindable to the host, so the first segment that is returned is vlan 401 segment, and neutron says its bindable and uses that. The fix that I have working here is 2 fold. First, since the port has a fixed_ip’s dict in it with a subnet_id in the port object, and the subnet contains the segment_id with which the ip of the port is supposed to be associated with. I first modify: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin… to add the segment_id into the fixed_ip dict, if the subnet_id has one: <snip> ) for ip in port['fixed_ips']: if 'subnet_id' in ip: subnet = self.get_subnet(orig_context._plugin_context, ip['subnet_id']) ip['segment_id'] = subnet['segment_id'] self._update_port_dict_binding(port, new_binding) <snip> Then, In the mech_agent I check if any of the fixed_ips has a segment_id and if it matches one of the segments on the network object, bind using that. <snip> if agent['alive']: ips = context.current['fixed_ips'] for ip in ips: if 'segment_id' in ip: for segment in context.segments_to_bind: if ip['segment_id'] == segment['id']: if self.try_to_bind_segment_for_agent(context, segment, agent): LOG.debug("Bound using segment: %s", segment) return for segment in context.segments_to_bind: <snip> This causes the correct segment_id to get sent to the agent and the agent creates br0.402 and assigns it to the bridge for the network. However, the agent assigns both br0.401 and br0.402 to the same linux bridge: -bash-4.2# brctl show <snip> brq3188bc9c-49 8000.9e8444c8e353 no br0.401 br0.402 tap1789c805-1c tap770e7357-be <snip> My guess is in order to correctly handle this neutron needs to create the brq interface based upon the segment vs's the network. I haven't yet started working on this particular issue. However, at this point I wanted to reach out to you guys to: 1.) Explain our use case. 2.) Get feedback on the path taken so far, as to be honest - while it works... its seems hacky. What we are trying to do is be able to use the vlan driver with segments and have the linuxbridge agents create the br0.<vlan_id> interfaces for us dynamically based upon the vlan id that we create the segment with. This will allow us to be able to have multiple of those segments (from the same routed network) per switch mapped into a single host. We are trying to avoid, outside of neutron, creating all the vlan interfaces/bridges, then just giving neutron the mappings in physical_interface_mappings or bridge_mappings. My understanding was that if these were normal provider networks using the vlan driver, I can have both networks map to the same interface on different vlans, by using the same physical_network name, and neutron will do the correct thing for me. 3.). Determine the correct process to follow to start working on this upstream. Does this need a spec? a RFE? Regards, Kris Lindgren

1 0

[openstack-dev] [omni] Has the Platform9's hybrid multicloud project been abandoned?
by Andrea Franceschini 20 Nov '18

20 Nov '18

Hello All, I'm trying to figure out if the project openstack/omni https://github.com/openstack/omni has been abandoned or superseded by another project, as it is no longer updated (at least not in the last year). Generally speaking, which is, if any, a project that aims at the same goal? In other words, which way should hybrid cloud be approached in Openstack? Do you have any idea/advice? Thanks a lot, Andrea __________________________________________________________________________ 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

4 3

Re: [tc] merging this list into openstack-discuss
by Jeremy Stanley 20 Nov '18

20 Nov '18

On 2018-11-20 08:18:34 -0500 (-0500), Doug Hellmann wrote: > As discussed previously in [1] and [2], this list is being merged into > the new openstack-discuss mailing list. Messages that previously would > have gone to this list should be sent to the new list using the subject > tag "[tc]" to attract Technical Committee members' attention. > > [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.ht… > [2] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134924.ht… Per Doug's post to the (now former) openstack-tc ML, I have proceeded with its retirement. The archives will be retained indefinitely, but the list itself can no longer receive new messages. -- Jeremy Stanley

1 0

[openstack-dev] [Senlin] Does Senlin support Prometheus？
by xuchao＠chinacloud.com.cn 20 Nov '18

20 Nov '18

Hi， Senlin, Ceilometer/Aodh is currently integrated, does it support Prometheus ？ thanks __________________________________________________________________________ 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

2 1

quick report on microstack
by Chris Morgan 20 Nov '18

20 Nov '18

Mark Shuttleworth introduced 'microstack' at the conference last week. It's a snap based openstack install suitable for getting a quick instance up for playing with. Project here : https://github.com/CanonicalLtd/microstack Its's aimed at bring-up on an actual ubuntu-installed host, however I got it running on a virtual Ubuntu VM on my Mac with a trivial change (see https://github.com/CanonicalLtd/microstack/issues/41) I found it an quick, easy, even fun way to get a test openstack instance, it installed in just a few minutes for me. It's a single command: snap install microstack --classic --edge So far I got a cirros instance to launch, but didn't yet manage to ssh into that instance, but I only had about an hour playing with it so far. Definitely a fun toy. Chris -- Chris Morgan <mihalis68(a)gmail.com>

2 1

[Openstack] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes??
by Yedhu Sastri 20 Nov '18

20 Nov '18

Hello All, I have some use-cases which I want to test in PowerPC architecture(ppc64). As I dont have any Power machines I would like to try it with ppc64 VM's. Is it possible to run these kind of VM's on my OpenStack cluster(Queens) which runs on X86_64 architecture nodes(OS RHEL 7)?? I set the image property architecture=ppc64 to the ppc64 image I uploaded to glance but no success in launching VM with those images. I am using KVM as hypervisor(qemu 2.10.0) in my compute nodes and I think it is not built to support power architecture. For testing without OpenStack I manually built qemu on a x86_64 host with ppc64 support(qemu-ppc64) and then I am able to host the ppc64 VM. But I dont know how to do this on my OpenStack cluster. Whether I need to manually build qemu on compute nodes with ppc64 support or I need to add some lines in my nova.conf to do this?? Any help to solve this issue would be much appreciated. -- Thank you for your time and have a nice day, With kind regards, Yedhu Sastri _______________________________________________ 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

4 4

[docs][i18n] Team meeting proposal
by Frank Kloeker 20 Nov '18

20 Nov '18

Hello, in the last weeks we had some informal discussions about combined team meeting for documentation and translation team. There should be overlapping topics and other project teams or operator would have the same contact persons on the same place. We also save resources on meeting chairs. Here are my proposal: 1) Meeting room #openstack-meeting 2) Switch back from (informal) Office Hour to (formal) Team Meeting. Topics for upcoming meetings will be collected on a Wiki page. If there are no topic we would skip the meeting. So often we recorded empty sessions in the past. 3) Meeting time is Thursday 07:00 UTC (odd week), 16:00 UTC (even week) 4) First part (30 min) I18n topics, second part documentation topics, meetingbot will recorded two sessions, so it's easier to read specific topics later. 5) Rotating meeting chairs between the two teams. This should renew a little bit the conversation and we are more flexible and visible on the move. kind regards Frank (PTL I18n)

5 4

[dev] [tc][all] TC office hours is started now on #openstack-tc
by Ghanshyam Mann 20 Nov '18

20 Nov '18

Hi All, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - TC

1 0

[openstack-dev] [charms] 18.11 OpenStack Charms release
by David Ames 19 Nov '18

19 Nov '18

Announcing the 18.11 release of the OpenStack Charms. The 18.11 charms have support for Nova cells v2 for deployments of Queens and later. The 18.11 release also has preview features including series upgrades and the Octavia load balancer charm. 47 bugs have been fixed and released across the OpenStack charms. For full details of the release, please refer to the release notes: https://docs.openstack.org/charm-guide/latest/1811.html Thanks go to the following contributors for this release: Alex Kavanagh Andrey Grebennikov Aymen Frikha Billy Olsen Chris MacNaughton Chris Sanders Corey Bryant David Ames Dmitrii Shcherbakov Drew Freiberger Edward Hope-Morley Felipe Reyes Frode Nordahl Fulvio Galeazzi James Page Liam Young Neiloy Mukerjee Pedro Guimarães Pete Vander Giessen Ryan Beisner Vladimir Grevtsev dongdong tao viswesuwara nathan __________________________________________________________________________ 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

1 0

[goals][tc] community-wide goals for train development cycle
by Doug Hellmann 19 Nov '18

19 Nov '18

Last week at the Forum in Berlin we met to discuss potential community-wide goals for the Train development cycle. We had a good list of proposals [1], although some of them do not meet the criteria for the goals program as currently defined [2]. We came up with a few suggestions that do fit the criteria, listed here in the order we discussed them: * Ensure that each project has contributor on-boarding documentation in a discoverable place in their documentation tree, and link to that from the contributor portal at openstack.org/community. (proposed by TheJulia) This should be relatively light-weight for teams to do, and will uncover some good opportunities for documentation reuse. * Deletion of project resources. (proposed by tobberydberg and adriant) This has been a long-standing request from operators, as discussed in forum session earlier in the week [3]. The propose next-steps are to establish a way for the existing os-purge program to accept plugins so that project teams can declare the relationships between resources that need to be deleted, to make orchestration easier. See the etherpad from the session for more details. * Finish moving legacy python-*client CLIs to python-openstackclient (proposed by mriedem on behalf of Tim Bell) This is another initiative that has been going on for a few years, and completing it would give users more clarity as well as providing a more consistent user interface. The general idea was to finish implementing all of the commands within OSC using the existing client libs, then update the SDK to support those features so we can drop the client libs from OSC as well, giving us 1 SDK and 1 CLI. That’s a multi-step process, so I think for the first phase targeting completing all of the commands within OSC using the various client libraries would be enough for 1 cycle. * Ensure all projects pass request-id when calling one another. (proposed by Pavlo Shchelokovskyy) Passing request-id allows us to chain requests together and trace them for debugging and profiling. We started this a while back and some projects are doing it but not all. * Rolling out oslo health-check middleware so each project provides that API. (proposed by mugsie) This came up at the PTG in Denver earlier this year [4]. There will be some up-front work to make the health check API able to support real backend checks for the database, message bus, etc. Then we would need to add the middleware to all services. In all of these cases, we have a bit more up-front work to do to be ready to accept the idea as a goal. There should be time during the remainder of the Stein cycle to make enough progress on that work to know if we could accept it as a goal. Our next steps are for the people proposing these goals to ensure that up-front work is done and be prepared to write up the goal document for review. If the proposes aren’t able/willing to act as goal champions, we need to identify someone else to fill that role. I propose we set a target of early March for having the formal goal proposals ready for review. That will give us time to approve them well before the next Summit/PTG, so that teams can use time during the PTG for planning their implementation. [1] https://etherpad.openstack.org/p/BER-t-series-goals [2] https://governance.openstack.org/tc/goals/index.html [3] https://etherpad.openstack.org/p/BER-deletion-of-project-resources [4] 1. https://etherpad.openstack.org/p/api-sig-stein-ptg (line 20) -- Doug

1 0

[cinder] On-Boarding Session Slides Posted ...
by Jay S Bryant 19 Nov '18

19 Nov '18

All, For those who are interested I have posted my Cinder Project On-Boarding slides here: [1] Thanks! Jay [1] https://www.slideshare.net/JayBryant2/cinder-onboarding-room-berlin-11132018

1 0

Re: [openstack-dev] [Openstack] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes??
by Sean Mooney 19 Nov '18

19 Nov '18

adding openstack dev. On Mon, 2018-11-19 at 18:08 +0000, Sean Mooney wrote: > On Mon, 2018-11-19 at 11:57 -0500, Ken D'Ambrosio wrote: > > On 2018-11-19 11:25, Yedhu Sastri wrote: > > > Hello All, > > > > > > I have some use-cases which I want to test in PowerPC architecture(ppc64). As I dont have any Power machines I > > > would > > > like to try it with ppc64 VM's. Is it possible to run these kind of VM's on my OpenStack cluster(Queens) which > > > runs > > > on X86_64 architecture nodes(OS RHEL 7)?? > > > > > > > I'm not 100% sure, but I'm 95% sure that the answer to your question is "No." While there's much emulation that > > occurs, the CPU isn't so much emulated, but more abstracted. Constructing and running a modern CPU in software > > would > > be non-trivial. > > you can do this but not with kvm. > you need to revert the virt dirver in the nova.conf back to qemu to disable kvm to allow emulation of other > plathforms. > that said i have only emulated power on x86_64 using libvirt or qemu idrectly never with openstack but i belive we > used > to support this i just hav enot done it personally. > > > > -Ken > > > > > I set the image property architecture=ppc64 to the ppc64 image I uploaded to glance but no success in launching VM > > > with those images. I am using KVM as hypervisor(qemu 2.10.0) in my compute nodes and I think it is not built to > > > support power architecture. For testing without OpenStack I manually built qemu on a x86_64 host with ppc64 > > > support(qemu-ppc64) and then I am able to host the ppc64 VM. But I dont know how to do this on my OpenStack > > > cluster. > > > Whether I need to manually build qemu on compute nodes with ppc64 support or I need to add some lines in my > > > nova.conf to do this?? Any help to solve this issue would be much appreciated. > > > > > > > > > -- > > > Thank you for your time and have a nice day, > > > > > > With kind regards, > > > Yedhu Sastri > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > > 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 __________________________________________________________________________ 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

2 2

[tc] summary of 12 Nov 2018 joint leadership meeting
by Doug Hellmann 19 Nov '18

19 Nov '18

On Monday 12 November, 2018 the OpenStack Foundation Board of Directors, staff, and project leadership held a joint meeting to discuss the project and foundation status [1]. We were hosted by Deutsche Telekom AG in their Berlin Representative Office. The meeting space was inside a room that housed their original telegraph offices built in 1861, and as someone who appreciates old architecture I can say that DT did an excellent job blending the feeling of the old building with the modern fittings needed for meetings like ours. The morning was taken up with a formal Board of Directors meeting, which Jonathan has already summarized at [2]. I won't repeat everything he wrote here, but there were a few topics that may be of particular interest to ATCs. The first is that the board has approved a set of bylaws changes [3] that declare that the Foundation will establish "Open Infrastructure Projects" (OIP), with the governance for each to be approved by the Board. Because the bylaws require a vote of the Foundation members to change, the details are left up to other documentation, which a subcommittee of the Board is going to begin preparing [4]. Completing that work is a prerequisite for Airship, Kata Containers, StarlingX, and Zuul to be confirmed as Foundation projects (they are "pilot" projects now). The current version of the bylaws includes details about the way OpenStack operates, by defining the membership and role of the Technical and User Committees. Those definitions will remain, to signal the "centrality" of the project and, and there are a few proposed wording changes to try to make election scheduling more flexible and to clarify the relationship between the OpenStack Technical and User Committees and the other OIPs. There is also a change to allow the Board and TC to update the "Technical Committee Member Policy" by voting on it together, rather than requiring a full vote of the Foundation members. There are also some minor cleanup and "modernization" of the language (removing obsolete references to bootstrapping directions, for example). There was not a lot of discussion of the changes in this meeting, because there had been several meetings to discuss and refine them before 12 November. Next, these changes need to be approved by the Platinum and Gold foundation members and then approved by the individual members. The goal is to have everything ready for approval during the board election this January. Please watch for the announcements for that vote and participate in the election, so that we have quorum and so the outcome of the vote is binding. The second topic I thought might be of interest is the discussion of the brand research the Foundation staff commissioned and which Wes previously summarized on the mailing list [5]. I was encouraged by the favorability numbers in the responses (67% of respondents rate OpenStack as "favorable" or "very favorable") as well as the 50-60% of overlap between people reporting an interest in OpenStack and in the existing OIPs. The "Open Infrastructure" renaming for the summit (announced last week) was also very popular in the survey results. After the Board meeting concluded, the Technical Committee presented a summary of the work done during Rocky, a preview of the work to be done during Stein (thank you to the PTLs who responded to my request for information) and some of the initiatives the TC is undertaking right now [6]. The Board was very interested in both the peer review culture change that Julia has been driving and the technical vision document that Zane has been writing [7]. Following the TC presentation, the User Committee presented updates on their work, the user survey, and work being done in adjacent communities such as Kubernetes [8]. We wrapped up the afternoon with presentations from each of the existing pilot projects on their mission and status [9]. [1] joint leadership meeting agenda https://wiki.openstack.org/wiki/Governance/Foundation/12Nov2018BoardMeeting [2] Jonathan’s summary of the Board meeting http://lists.openstack.org/pipermail/foundation/2018-November/002654.html [3] bylaws changes http://lists.openstack.org/pipermail/foundation-board/2018-November/000459.… [4] Board thread on creating acceptance criteria for OIPs http://lists.openstack.org/pipermail/foundation-board/2018-November/000462.… [5] OSF branch research results http://lists.openstack.org/pipermail/foundation/2018-October/002634.html [6] TC presentation https://docs.google.com/presentation/d/1wcG7InY2A5y67dt5lC14CI1gQHGZ3db8-ys… [7] Vision for OpenStack Clouds https://governance.openstack.org/tc/reference/technical-vision.html [8] UC Presentation https://docs.google.com/presentation/d/1gLcChOupELCGItD-SzhECEhFMGQc4jf0PlQ… [9] Pilot project presentations https://docs.google.com/presentation/d/1nsm6ht3kJRw7vZsbjLDcTfPA8d8gu3jSYin… -- Doug

1 0

Re: [openstack-dev] [tripleo] Proposing Enrique Llorente Pastora as a core reviewer for TripleO
by Steven Hardy 19 Nov '18

19 Nov '18

On Thu, Nov 15, 2018 at 3:54 PM Sagi Shnaidman <sshnaidm(a)redhat.com> wrote: > > Hi, > I'd like to propose Quique (@quiquell) as a core reviewer for TripleO. Quique is actively involved in improvements and development of TripleO and TripleO CI. He also helps in other projects including but not limited to Infrastructure. > He shows a very good understanding how TripleO and CI works and I'd like suggest him as core reviewer of TripleO in CI related code. > > Please vote! > My +1 is here :) +1! __________________________________________________________________________ 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

1 0

[docs] looking for help with sitemap generation
by Doug Hellmann 19 Nov '18

19 Nov '18

During Rocky an intern for the OSF started working on a project to build sitemap files for docs.openstack.org. Megan has moved on, and we're looking for someone to pick up and finish that work. What we need is to have the tool to produce the per-doc-build sitemap finished [1], then to update the main doc site build to produce a full sitemap that links to the other existing sitemaps. If you have a little time and interest, please get in touch and I'll be happy to clarify and expand on that description. [1] https://review.openstack.org/#/c/524862/ -- Doug

1 0

[python3] RHEL 8 will include python 3.6
by Doug Hellmann 19 Nov '18

19 Nov '18

Now that the RHEL 8 beta is released, there is more official information about what is included. In particular, the question we've been waiting to have answered is "which version of python 3 will be the default?" The answer is 3.6, which means it should be safe to drop 3.5 testing for Stein. https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/ -- Doug

1 0

[openstack-dev] [Searchlight] Weekly report, Stein R-21
by Trinh Nguyen 19 Nov '18

19 Nov '18

Hello team, Here is the report for last week, Stein R-21. Please have a look: https://www.dangtrinh.com/2018/11/searchlight-weekly-report-stein-r-21.html Thanks, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>* __________________________________________________________________________ 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

1 0

Re: [openstack-dev] [horizon] how to get horizon related logs to syslog?
by Akihiro Motoki 19 Nov '18

19 Nov '18

Hi, Horizon logging depends on Django configuration which supports full python logging [1]. [1] does not provide enough examples. Perhaps [2] will help you (though I haven't tested it). [1] https://docs.djangoproject.com/en/2.0/topics/logging/ [2] https://www.simonkrueger.com/2015/05/27/logging-django-apps-to-syslog.html Thanks, Akihiro 2018年11月16日(金) 18:47 Tikkanen, Viktor (Nokia - FI/Espoo) < viktor.tikkanen(a)nokia.com>: > Hi! > > For most openstack parts (e.g. Aodh, Cinder, Glance, Heat, Ironic, > Keystone, Neutron, Nova) it was easy to get logs to syslog. > > For example for Heat something similar to this (into file > templates/heat.conf.j2): > > # Syslog usage > {% if heat_syslog_enabled %} > use_syslog = True > syslog_log_facility = LOG_LOCAL3 > {% else %} > log_file = /var/log/heat/heat.log > {% endif %} > > But how to get Horizon related logs to syslog? > > -V. > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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

2 1

[openstack-dev] [Searchlight] New team meeting time
by Trinh Nguyen 19 Nov '18

19 Nov '18

Hello team, In order to welcome new contributors to the Searchlight project, we decided to change the meeting time [1]: - Time: 13:30 UCT - Meeting Channel: #openstack-searchlight - Meeting recurrence: bi-weekly starting from 19th Nov. 2018 [1] http://eavesdrop.openstack.org/irclogs/%23openstack-searchlight/latest.log.… Hope that there will be new blood into the project :D -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>* __________________________________________________________________________ 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

1 0

[glance] time to adjust your ML filters
by Brian Rosmaita 19 Nov '18

19 Nov '18

Hello Glancers, This message is sent from the new openstack-discuss mailing list so that you have a reference point from which to adjust your email filters. See Jeremy's message from earlier today [0] for more information about the new ML. cheers, brian [0] http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000000…

1 0

Re: [openstack-dev] [tripleo] Proposing Enrique Llorente Pastora as a core reviewer for TripleO
by Gabriele Cerami 19 Nov '18

19 Nov '18

On 15 Nov, Sagi Shnaidman wrote: > Hi, > I'd like to propose Quique (@quiquell) as a core reviewer for TripleO. > Quique is actively involved in improvements and development of TripleO and > TripleO CI. He also helps in other projects including but not limited to > Infrastructure. It'll be grand. +1 __________________________________________________________________________ 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

1 0

[ops][docs] operations-docs on StoryBoard
by Frank Kloeker 19 Nov '18

19 Nov '18

Hello, I've started today with a proposal on [1] to add docs for operations on StoryBoard [2].That could be useful to track bugs that people raise while reading the document. Also a rework for parts of the document could be planned in StoryBoard. A reference might be the work on the Contributor Guide which is mostly maintained in [3]. kind regards Frank [1] https://review.openstack.org/#/c/618722/ [2] https://storyboard.openstack.org [3] https://storyboard.openstack.org/#!/project/openstack/contributor-guide

1 0

Re: [openstack-dev] [tripleo] Proposing Enrique Llorente Pastora as a core reviewer for TripleO
by Juan Antonio Osorio Robles 19 Nov '18

19 Nov '18

+1 on making him tripleo-ci core. Great work! On 11/15/18 5:50 PM, Sagi Shnaidman wrote: > Hi, > I'd like to propose Quique (@quiquell) as a core reviewer for TripleO. > Quique is actively involved in improvements and development of TripleO > and TripleO CI. He also helps in other projects including but not > limited to Infrastructure. > He shows a very good understanding how TripleO and CI works and I'd > like suggest him as core reviewer of TripleO in CI related code. > > Please vote! > My +1 is here :) > > Thanks > -- > Best regards > Sagi Shnaidman > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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

1 0

[openstack-dev] [octavia] Please give me some comments about my patchs
by Jeff Yang 18 Nov '18

18 Nov '18

Hi, Octavia Team: There are two patches I committed: https://review.openstack.org/#/c/590620/ https://review.openstack.org/#/c/594040/ The first implement l7policy and l7rule's quota management. The second provides some restrictions about the protocol when listener is associated with pool. I think these functions are useful for users. I hope to receive some suggestions from you. Thinks. __________________________________________________________________________ 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

1 0

Re: [Openstack] (Juno - *sigh*) Want non-admin access to hypervisor:VM association.
by Ken D'Ambrosio 18 Nov '18

18 Nov '18

On 2018-11-18 09:11, Mohammed Naser wrote: > https://blueprints.launchpad.net/nova/+spec/openstack-api-hostid > > This should take care of it, don't know if it exists in Juno though. It *does* exist in Juno, it *can't*, however, do what I want -- at least, generically. The hostId that gets returned is a value that's (apparently) used to let you know, semi-anonymously, how affinity is (or isn't) working for your VMs. So you get a unique identifier for each hypervisor -- but it has no *obvious* bearing on the hostname. It's an id that's formed from the SHA224 hash of the ID of your tenant and the hostname of the hypervisor -- a bit of a catch-22, that, and prevents you from being able to make use of the hash if you don't know your back-end. But... I do. So I created an associative array with all the current (and, God willing, future) hypervisor hostnames in my company, with the key being the hostId/hash, and the value being the hypervisor name. Then I queried my VMs, got all the hostIds, used that as the index to query my associative array, and bingo! My hypervisor's name. Kinda fugly, but when you have a standardized hypervisor hostname nomenclature, it's sufficient, without having to go mucking about with changing poorly-documented Nova policy.json stuff in a four-year-old release of OpenStack. I'll take it. Thanks! -Ken > On Thu, Nov 15, 2018 at 1:49 PM Ken D'Ambrosio <ken(a)jots.org> wrote: > >> Hey, all. We've got a Juno cloud, and we'd like various end-users to be >> able to see which hypervisors their VMs spring up on. >> /etc/nova/policy.json seems to have some relevant info, but it's hard to >> tell what does what. "compute_extension:hypervisors" looks like a >> possible candidate, but that's so vague that there's no telling what, >> exactly, is meant by "hypervisors". So: >> >> * Given that I just want the hypervisor:VM association, any suggestions >> as to which rule(s) to modify? >> * Failing that, wondering if there's any for-real documentation on what >> the various options in policy.json *do*. I've found many, many lists of >> what's in a generic policy.json, but nothing that went into detail about >> what does what. >> >> Thanks! >> >> -Ken >> >> _______________________________________________ >> 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 > > -- > Mohammed Naser -- vexxhost > > ----------------------------------------------------- > D. 514-316-8872 > D. 800-910-1726 ext. 200 > E. mnaser(a)vexxhost.com > W. http://vexxhost.com [1] Links: ------ [1] http://vexxhost.com/ _______________________________________________ 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