[Openstack-operators] Short survey on Guest Images
If you're somehow involved in creating/providing images for glance, I have a very short survey that I'd like input on. https://docs.google.com/forms/d/1HR500i8raQiH72GwEbpFuUQA8OvA7Uae2e-39Y6YSQ0/viewform?usp=send_form https://docs.google.com/forms/d/1HR500i8raQiH72GwEbpFuUQA8OvA7Uae2e-39Y6YSQ0/viewform?usp=send_form Responses will help me as part of my presentation in Vancouver. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] how to attach VMs to external/vlan network directly
Hi, I've tried without success to attach instances directly to external VLAN network using provider:network_type vlan; below are the details. Using provider:network_type flat I made it work. I was basically following this: http://www.s3it.uzh.ch/blog/openstack-neutron-vlan/ Any idea will be appreciated. ML2 CONFIG ml2_type_vlan network_vlan_ranges vlannet:81:91 bridge_mappings vlannet:br-vlan enable_security_group True enable_ipset True firewall_driver neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver NETWORK CREATION neutron net-create vlan81 --router:external True --provider:physical_network vlannet --provider:network_type vlan --provider:segmentation_id 81 --shared neutron subnet-create vlan81 10.111.81.0/24 --name vlan81 --allocation-pool start=10.111.81.65,end=10.111.81.126 --enable-dhcp --gateway 10.111.81.254 --dns-nameserver 10.1.1.68 --dns-nameserver 10.1.1.42 --host-route destination=169.254.169.254/32,nexthop=10.111.81.65 NETWORK CONFIGURATION OF COMPUTE/NETWORK NODES em1 \ bond0 - vlan81 - | br-vlan | - | br-int | em2 / DEBUGGING root@juno-dev02:~# ovs-ofctl dump-flows br-vlan NXST_FLOW reply (xid=0x4): cookie=0x0, duration=2991.439s, table=0, n_packets=5374, n_bytes=357405, idle_age=2, priority=4,in_port=5,dl_vlan=1 actions=mod_vlan_vid:81,NORMAL cookie=0x0, duration=3439.498s, table=0, n_packets=3792, n_bytes=159460, idle_age=0, priority=2,in_port=5 actions=drop cookie=0x0, duration=3440.064s, table=0, n_packets=113217, n_bytes=18712371, idle_age=0, priority=1 actions=NORMAL root@juno-dev02:~# ovs-ofctl dump-flows br-int NXST_FLOW reply (xid=0x4): cookie=0x0, duration=3891.241s, table=0, n_packets=1448, n_bytes=157908, idle_age=1236, priority=3,in_port=7,dl_vlan=81 actions=mod_vlan_vid:1,NORMAL cookie=0x0, duration=4339.435s, table=0, n_packets=26538, n_bytes=1584268, idle_age=1, priority=2,in_port=7 actions=drop cookie=0x0, duration=4340.224s, table=0, n_packets=10686, n_bytes=590535, idle_age=1, priority=1 actions=NORMAL cookie=0x0, duration=4340.153s, table=23, n_packets=0, n_bytes=0, idle_age=4340, priority=0 actions=drop root@juno-dev02:~# nova list +--+--+++-+-+ | ID | Name | Status | Task State | Power State | Networks| +--+--+++-+-+ | 2f1a2cba-6fc7-45ae-a251-e709ab8b7ecc | test | ACTIVE | - | Running | vlan81=10.111.81.66 | +--+--+++-+-+ Instance can reach DHCP server on network node (10.111.81.65), but cannot reach default gateway (10.111.81.254), nor any host of the external network. The br-vlan bridge shows outgoing ARP packets tagged with vlan 81, and ARP replies not tagged, which I suppose it then drops because it does not match the first rule of br-vlan. The br-int bridge shows only outgoin ARP packets: root@juno-dev02:~# tcpdump -env -i br-vlan icmp or arp tcpdump: listening on br-vlan, link-type EN10MB (Ethernet), capture size 65535 bytes 11:45:56.463254 fa:16:3e:58:74:5b ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 81, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.111.81.254 tell 10.111.81.66, length 28 11:45:56.464491 78:19:f7:9b:2a:41 fa:16:3e:58:74:5b, ethertype ARP (0x0806), length 56: Ethernet (len 6), IPv4 (len 4), Reply 10.111.81.254 is-at 78:19:f7:9b:2a:41, length 42 11:45:57.461253 fa:16:3e:58:74:5b ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 81, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.111.81.254 tell 10.111.81.66, length 28 11:45:57.462765 78:19:f7:9b:2a:41 fa:16:3e:58:74:5b, ethertype ARP (0x0806), length 56: Ethernet (len 6), IPv4 (len 4), Reply 10.111.81.254 is-at 78:19:f7:9b:2a:41, length 42 root@juno-dev02:~# tcpdump -env -i br-int icmp or arp tcpdump: WARNING: br-int: no IPv4 address assigned tcpdump: listening on br-int, link-type EN10MB (Ethernet), capture size 65535 bytes 11:29:49.330084 fa:16:3e:58:74:5b ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 1, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.111.81.254 tell 10.111.81.66, length 28 11:29:50.162106 fa:16:3e:58:74:5b ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 1, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.111.81.49 tell 10.111.81.66, length 28 11:29:51.180111 fa:16:3e:58:74:5b ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 1, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.111.81.49 tell 10.111.81.66, length 28 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] OpenStack Community Weekly Newsletter (Apr 3 - 10)
Making your list and checking it twice for the OpenStack Vancouver Summit Emily Hugenbruch shared her pre-summit checklists: great tips there. OVN and OpenStack Integration Development Update The Open vSwitch project announced the OVN effort back in January and Russell Bryant started to look into it. He reports about OVN, calling it “a promising open source backend for OpenStack Neutron”. OpenStack in the classroom Amrith Kumar announced an effort to work with educational institutions in Massachusetts and near Toronto (where Tesora has offices) to try and make available a course on cloud computing with OpenStack as the exemplar system. OpenStack In The Enterprise A new mini-portal on openstack.org website to discover use cases and white papers from the enterprise world. The Road to Vancouver * Sign up for OpenStack Upstream Training in Vancouver * Canada Visa Information * Official Hotel Room Blocks * 2015 OpenStack T-Shirt Design Contest * Preparation to Design summit * Liberty Design Summit - Proposed slot allocation * What's a Design Summit? There is still room for Upstream Training Relevant Conversations * PTL Voting is now open * Kilo stable branches for other libraries * The Evolution of core developer to maintainer? * The Core Deficiency * Implementation of Pacemaker Managed OpenStack VM Recovery * Neutron Kilo Retrospective and a Look Toward Liberty * [Neutron] The specs process, effective operators feedback and product management Deadlines and Development Priorities * [Nova] Identifying release critical bugs in Kilo * [Cinder] Bug Triage - Call for Participation * [Nova] Liberty specs are now open and [Nova] Trunk is now Liberty * [neutron] Liberty Specs are now open! Security Advisories and Notices * None Tips ‘n Tricks * By Adam Young: Horizon WebSSO via SSSD * By Assaf Muller: Multinode DVR Devstack * By Alessandro Pilotti: VirtualBox driver for OpenStack Upcoming Events * Apr 13 - 14, 2015 OpenStack Live Santa Clara, CA, US * Apr 13 - 16, 2015 StackAttack! A HOLatCollaborate15 Las Vegas, NV, US * Apr 15, 2015 iX OpenStack Tag Köln, NRW, DE * Apr 15 - 16, 2015 1º Hangout OpenStack Brasil 2015 Brasil, BR * Apr 16 - 18, 2015 Open Cloud 2015 Beijing, Beijing, CN * Apr 16, 2015 8th OpenStack Meetup Stockholm Stockholm, SE * Apr 16, 2015 8th OpenStack User Group Nordics meetup Stockholm, SE * Apr 21 - 22, 2015 CONNECT 2015 Melbourne, Victoria, AU * Apr 22 - 23, 2015 China SDNNFV Conference Beijing, CN * Apr 22, 2015 OpenStack NYC Meetup New York, NY, US * Apr 23, 2015 OpenStack Philadelphia Meetup Philadelphia, PA, US * May 05 - 07, 2015 CeBIT AU 2015 Sydney, NSW, AU * May 18 - 22, 2015 OpenStack Summit May 2015 Vancouver, BC Other News * A community distribution of OpenStack * Why adopting OpenStack for dev/test matters * Gophercloud Update * Why OpenStack will change the way we live, work and play The weekly newsletter is a way for the community to learn about all the various activities occurring on a weekly basis. If you would like to add content to a weekly update or have an idea about this newsletter, please leave a comment. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Dynamic Policy for Access Control
On 04/07/2015 11:36 AM, Marc Heckmann wrote: My apologies for not seeing this sooner as the topic is of great interest. My comments below inline.. On Mon, 2015-02-23 at 16:41 +, Tim Bell wrote: -Original Message- From: Adam Young [mailto:ayo...@redhat.com] Sent: 23 February 2015 16:45 To: openstack-operators@lists.openstack.org Subject: [Openstack-operators] Dynamic Policy for Access Control Admin can do everything! has been a common lament, heard for multiple summits. Its more than just a development issue. I'd like to fix that. I think we all would. I'm looking to get some Operator input on the Dynamic Policy issue. I wrote up a general overview last fall, after the Kilo summit: https://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/ I agree with everything in that post. I would add the following comments: 1. I doubt this will change, but to be clear, we cannot lose the ability to create custom roles and limit the capabilities of the standard roles. For example, if I wanted to limit the ability to make images public or limit the ability to associate a floating IP. That is a baseline consideration. We are hoping to make custom roles the norm. 2. This work should not be done in vacuum. Ideally, Horizon support for assigning roles to users and editing policy should be released at the same time or not long after. I realize that this is easier said than done, but it will be important in order for the feature to get used. Role assignments will be done the same way they are now, as Horizon fetches the list of roles from Keystone. Editing policy will require a new UI. I don't see that happening in Horizon until the Keystone mechanism is finalized. Thanks for the response. We can carry on the conversation at the Summit. Some of what I am looking at is: what are the general roles that Operators would like to have by default when deploying OpenStack? As I described in http://openstack-in-production.blogspot.ch/2015/02/delegation-of-roles.html, we've got (mapped per-project to an AD group) - operator (start/stop/reboot/console) - accounting (read ceilometer data for reporting) I've submitted a talk about policy for the Summit: https://www.openstack.org/vote-vancouver/presentation/dynamic-policy-for- access-control If you want, please vote for it, but even if it does not get selected, I'd like to discuss Policy with the operators at the summit, as input to the Keystone development effort. Sounds like a good topic for the ops meetup track. Feedback greatly welcome. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [all] [api] [log] Erring is Caring
Hi all, The first draft of the spec for Log Message Error Codes (from the Log Working Group) is out for review: https://review.openstack.org/#/c/172552/ Please comment, and please look for the way forward so that the different places, ways and reasons errors get reported provide consistency across the projects the make up the Openstack ecosystem. Consistency across uses will speed problem solving and will provide a common language across the diversity of users of the OpenStack code and environments. This cross project spec is focused on just a part of the Log Message header, but it is the start of where log messages need to go. It dovetails in with developer focused API errors, but is aimed at the log files the operators rely on to keep their clouds running. Over the next couple of days, I will also specifically add reviewers to the list if you haven't already commented on the spec;-). Thanks for your patience waiting for this. It *is* a work in progress, but I think the meat is there for discussion. Also, please look at and comment on: Return Request ID to caller https://review.openstack.org/#/c/156508/ as this is also critical to get right for logging and developer efforts. --Rocky -Original Message- From: Everett Toews [mailto:everett.to...@rackspace.com] Sent: Tuesday, March 31, 2015 14:36 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [all] [api] Erring is Caring Hi All, An API Working Group Guideline for Errors https://review.openstack.org/#/c/167793/ Errors are a crucial part of the developer experience when using an API. As developers learn the API they inevitably run into errors. The quality and consistency of the error messages returned to them will play a large part in how quickly they can learn the API, how they can be more effective with the API, and how much they enjoy using the API. We need consistency across all services for the error format returned in the response body. The Way Forward I did a bit of research into the current state of consistency in errors across OpenStack services [1]. Since no services seem to respond with a top-level errors key, it's possible that they could just include this key in the response body along with their usual response and the 2 can live side-by-side for some deprecation period. Hopefully those services with unstructured errors should okay with adding some structure. That said, the current error formats aren't documented anywhere that I've seen so this all feels fair game anyway. How this would get implemented in code is up to you. It could eventually be implemented in all projects individually or perhaps a Oslo utility is called for. However, this discussion is not about the implementation. This discussion is about the error format. The Review I've explicitly added all of the API WG and Logging WG CPLs as reviewers to that patch but feedback from all is welcome. You can find a more readable version of patch set 4 at [2]. I see the id and code fields as the connection point to what the logging working group is doing. Thanks, Everett [1] https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Errors [2] http://docs-draft.openstack.org/93/167793/4/check/gate-api-wg-docs/e2f5b6e//doc/build/html/guidelines/errors.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
