Re: [openstack-dev] [neutron][routed-network] Host doesn't connected any segments when creating port

[shihanzhang]

Hi Zhi Chang,
Maybe you should add a config option in [ovs] section: bridge_mappings = 
public:br-ex, physnet1:br-physnet1 to handle the provider network 'physnet1'.


Thanks,
shihanzhang

At 2016-11-01 11:56:33, "zhi"  wrote:

hi shihanzhang.


Below is configuration in ml2_conf.ini. Please review it. :)


stack@devstack:~/neutron/neutron$ cat /etc/neutron/plugins/ml2/ml2_conf.ini 
|grep -v "#"|grep -v ^$
[DEFAULT]
[ml2]
tenant_network_types = vxlan
extension_drivers = port_security
mechanism_drivers = openvswitch,linuxbridge
tenant_network_types = vxlan
[ml2_type_flat]
flat_networks = public,public,
[ml2_type_geneve]
vni_ranges = 1:1000
[ml2_type_gre]
tunnel_id_ranges = 1:1000
[ml2_type_vlan]
network_vlan_ranges = physnet1,physnet2
[ml2_type_vxlan]
vni_ranges = 1:1000
[securitygroup]
firewall_driver = 
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
[agent]
tunnel_types = vxlan
root_helper_daemon = sudo /usr/local/bin/neutron-rootwrap-daemon 
/etc/neutron/rootwrap.conf
root_helper = sudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf
[ovs]
datapath_type = system
bridge_mappings = public:br-ex
tunnel_bridge = br-tun
local_ip = 192.168.10.20






Thanks
Zhi Chang


2016-11-01 9:15 GMT+08:00 shihanzhang :

hi Zhi chang,

Could you provide your ml2_conf.ini for ovs agent, I guess the reason is that 
your ovs-agent on host devstack can't handle the related segment id.


Thanks,
shihanzhang


在 2016-10-31 18:43:36，"zhi"  写道：

Hi, all.


Recently, I watch the OpenStack Summit video named ' Scaling Up OpenStack 
Networking with Routed Networks '.  Carl and Miguel made this topic.  I learned 
a lot of your topic. Thanks. 


But I have some questions about the demo in the topic. 


I do some steps according to the topic. 


First, creating two networks like this:


neutron net-create multinet --shared --segments type=dict list=true 
provider:physical_network=physnet1,provider:segmentation_id=2016,provider:network_type=vlan
 
provider:physical_network=physnet2,provider:segmentation_id=2016,provider:network_type=vlan




Second, I get two segments after creating this network. I get these segments by 
using " openstack network segment list ". 


Third, I create two subnets by these segments by using this command " 


neutron subnet-create --ip_version 4 --name multi-segment1-subnet [net-id] 
10.1.0.0/24 --segment_id [segment-id]
neutron subnet-create --ip_version 4 --name multi-segment2-subnet [net-id] 
10.1.1.0/24 --segment_id [segment-id]
 "


At last, I want to create a port with host_id. My local environment contains 
two compute nodes, one is named "devstack"  and the other is "devstack2". So I 
use this command "  neutron port-create --binding:host_id=devstack [net-id] ". 


Exception happens in neutron server. The exception says "


Host devstack is not connected to any segments on routed provider network 
[net-id].  It should be connected to one." I can not get this exact point about 
this exception. 


Why does the "routed network" have relationship with host? 


How they work together between "host info (compute node ?)" and "routed 
network"?


What should I do if I want to get rid of this exception?




Hope for your reply. Especially Carl and Miguel. ;-)






Many Thanks
Zhi Chang




 


__
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 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

Re: [openstack-dev] [All] Cross project prorietary driver code recap

[Ben Swartzlander]

On 10/31/2016 02:23 PM, Sean McGinnis wrote:

Last Tuesday we had a cross-project session around the use of proprietary
code/libs/binaries in OpenStack drivers. The challenge we are running into
is where to draw the line with these drivers. What is the appropriate policy
to have in place to allow/disallow certain approaches.

There was a lot of good discussion and input from multiple projects that are
affected by this. I won't attempt to recap the full conversation here. The
etherpad with the notes from the discussion can be found here:

https://etherpad.openstack.org/p/ocata-xp-proprietary-drivers

The two main concerns I heard were around 1) the ability to package and
redistribute everything needed to run an OpenStack environment, and 2) the
value these drivers bring to the OpenStack project. Particularly those that
have no business logic in the code in OpenStack and just call out to third
party libraries to handle all business logic.

Proposals
=

Option 1:

- All libraries imported by the driver must be licensed such that they are
  redistributable by package maintainers.
- Existing non-compliant driver code would need to be updated by the Q
  release to stay in tree.
- Code that does not get imported into the driver at runtime (CLIs, external
  binaries, remote application servers) are acceptable to be not
  redistributable.

Issues:

- The desire for having things redistributable was to have everything fully
  functional "out of the box" no matter how the deployer configured the system.
  I don't believe this is ever possible. With requirements of setting up some
  type of application or management server to enable some solutions, it is not
  possible to package all required code and binaries for every configuration.


Option 2:

- Remove all drivers that are not completely open source and contained in the
  project repo.

Issues:

- This restricts things down to only the drivers that can currently be run in
  gate.
- This would be a big issue for many Cinder drivers and I'm sure most Ironic
  drivers.
- I strongly believe this would result in less vendor involvement in upstream
  work.


Option 3:

- Require the majority of business logic is in the open source code.
- Allow third party, non-redistributable libraries and CLIs that are used as
  more of an "RPC" type interface.
- Reviewers should be able to review the driver code and at least get some
  idea of the steps the driver is doing to perform each requested operation.

Issues:

- Does not address the desire to package all needed requirements.



My preference is actually option 3. The reality is, with most vendor solutions
there's always going to be some part of the overall solution that is
proprietary and requires some configuration and setup by the deployer.
Arbitrarily drawing that line such that a proprietary app server is OK, but a
proprietary library is not OK, just leads to poor solution architectures such
as requiring the end user to set up a separate server just so the driver can
SSH into it to run commands.

The case that instigated this discussion for me was a proposal to have a driver
that did nothing more than make a one line call of everything out to a library
that handled all logic. In that case, there is no benefit to the community of
being able to review the code and give some assurance that it is doing things
correctly. And the only benefit really it gives the vendor is they have an out
of tree driver that gets advertised as being in tree.

My desire as a code reviewer and project maintainer is that I can take a look
at a driver and at least get an idea of what they are doing and how their
device works to perform some of these operations. That's not an exact number -
I'm not saying something like 10% of the code needs to be in the driver, but
9% would not be acceptable - but we need to have some visiblity to the logic
so we as a community can at least help point users in the right direction if
they come looking for help.

I think this works for Cinder and probably is necessary for Ironic.

I'd be interested in hearing feedback or other options from other folks. I'd
especially like to hear from Helion, OSP, Mirantis, and others that are doing
packaging and support for these deployments to hear how this impacts the way
they do things.


As usual I'd like to point to the Linux project as a good example for 
how to handle such things. Linux is older than us and has been dealing 
with drivers and proprietary code for a very long time.


Linux does a few specific things that I like a lot:
1) Drivers have to match the license (GPLv2 in Linux's case) which 
guarantees the code is free software.
2) Drivers have to be in tree, which makes it easier for kernel 
developers to evolve the driver interfaces without breaking most drivers.
3) Drivers which require proprietary stuff (typically called "firmware" 
or "binary blobs" in the Linux world) can contribute that stuff to the 
linux-firmware repo which supports closed-source 

Re: [openstack-dev] [neutron][routed-network] Host doesn't connected any segments when creating port

[zhi]

hi shihanzhang.

Below is configuration in ml2_conf.ini. Please review it. :)

stack@devstack:~/neutron/neutron$ cat /etc/neutron/plugins/ml2/ml2_conf.ini
|grep -v "#"|grep -v ^$
[DEFAULT]
[ml2]
tenant_network_types = vxlan
extension_drivers = port_security
mechanism_drivers = openvswitch,linuxbridge
tenant_network_types = vxlan
[ml2_type_flat]
flat_networks = public,public,
[ml2_type_geneve]
vni_ranges = 1:1000
[ml2_type_gre]
tunnel_id_ranges = 1:1000
[ml2_type_vlan]
network_vlan_ranges = physnet1,physnet2
[ml2_type_vxlan]
vni_ranges = 1:1000
[securitygroup]
firewall_driver =
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
[agent]
tunnel_types = vxlan
root_helper_daemon = sudo /usr/local/bin/neutron-rootwrap-daemon
/etc/neutron/rootwrap.conf
root_helper = sudo /usr/local/bin/neutron-rootwrap
/etc/neutron/rootwrap.conf
[ovs]
datapath_type = system
bridge_mappings = public:br-ex
tunnel_bridge = br-tun
local_ip = 192.168.10.20



Thanks
Zhi Chang

2016-11-01 9:15 GMT+08:00 shihanzhang :

> hi Zhi chang,
> Could you provide your ml2_conf.ini for ovs agent, I guess the reason is
> that your ovs-agent on host devstack can't handle the related segment id.
>
> Thanks,
> shihanzhang
>
> 在 2016-10-31 18:43:36，"zhi"  写道：
>
> Hi, all.
>
> Recently, I watch the OpenStack Summit video named ' Scaling Up OpenStack
> Networking with Routed Networks '.  Carl and Miguel made this topic.  I
> learned a lot of your topic. Thanks.
>
> But I have some questions about the demo in the topic.
>
> I do some steps according to the topic.
>
> First, creating two networks like this:
>
> neutron net-create multinet --shared --segments type=dict list=true
> provider:physical_network=physnet1,provider:segmentation_id=2016,provider:network_type=vlan
> provider:physical_network=physnet2,provider:
> segmentation_id=2016,provider:network_type=vlan
>
>
> Second, I get two segments after creating this network. I get these
> segments by using " openstack network segment list ".
>
> Third, I create two subnets by these segments by using this command "
>
> neutron subnet-create --ip_version 4 --name multi-segment1-subnet [net-id]
> 10.1.0.0/24 --segment_id [segment-id]
> neutron subnet-create --ip_version 4 --name multi-segment2-subnet [net-id]
> 10.1.1.0/24 --segment_id [segment-id]
>  "
>
> At last, I want to create a port with host_id. My local environment
> contains two compute nodes, one is named "devstack"  and the other is
> "devstack2". So I use this command "  neutron port-create
> --binding:host_id=devstack [net-id] ".
>
> Exception happens in neutron server. The exception says "
>
> Host devstack is not connected to any segments on routed provider network
> [net-id].  It should be connected to one." I can not get this exact point
> about this exception.
>
> Why does the "routed network" have relationship with host?
>
> How they work together between "host info (compute node ?)" and "routed
> network"?
>
> What should I do if I want to get rid of this exception?
>
>
> Hope for your reply. Especially Carl and Miguel. ;-)
>
>
>
> Many Thanks
> Zhi Chang
>
>
>
>
>
> __
> 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 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-dev] [cinder] consistency groups in ceph

[Victor Denisov]

Hi,

I'm working on consistency groups feature in ceph.
My question is about what kind of behavior does cinder expect from
storage backends.
I'm particularly interested in what happens to consistency groups
snapshots when I remove an image from the group:

Let's imagine I have a consistency group called CG. I have images in
the consistency group:
Im1, Im2, Im3, Im4.
Let's imagine we have snapshots of this consistency group:

CGSnap1
CGSnap2
CGSnap3

Snapshots of individual images in a consistency group snapshot I will call
CGSnap2Im1 - Snapshot of image 1 from consistency group snapshot 2.

Qustion 1:
If consistency group CG has 4 images: Im1, Im2, Im3, Im4.
Can CGSnap1 have more images than it already has: Im1, Im2, Im3, Im4, Im5.

Can CGSnap1 have less images than it already has: Im1, Im2, Im3.

Question 2:
If we remove image2 from the consistency group. Does it mean that
snapshots of this image should be removed from all the CGSnaps.

Example:
We are removing Im2.
CGSnaps look like this:

CGSnap1 - CGSnap1Im1, CGSnap1Im2, CGSnap1Im3
CGSnap2 - CGSnap2Im1, CGSnap2Im2, CGSnap2Im3, CGSnap3Im4
CGSnap3 - CGSnap3Im1, CGSnap3Im2, CGSnap3Im3, CGSnap3Im4

What happens to snapshots: CGSnap1Im2,CGSnap2Im2, CGSnap3Im2? Do we
remove them, do we keep them. Is it important what we do to them at
all?

Thanks,
Victor.

__
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

Re: [openstack-dev] [neutron] Cloud Provider Security Groups

[Sridar Kandaswamy (skandasw)]

Hi All:

Thanks Kevin. David, yes I think we have a model that will work for u and would 
definitely want to discuss this more with u. I do hope that this can also help 
refine some of our thoughts. U can join us in our weekly IRC [1] (next one is 
tomorrow) and we can create an agenda item for more discussion. If the time is 
inconvenient, pls reach out to me and we set a time for a discussion with the 
team.

[1] http://eavesdrop.openstack.org/#Firewall_as_a_Service_(FWaaS)_Team_Meeting

Thanks

Sridar

From: Kevin Benton >
Reply-To: OpenStack List 
>
Date: Monday, October 31, 2016 at 2:59 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron] Cloud Provider Security Groups

I believe the FWaaS v2 work is attempting to capture this concept of 
provider-set rules to address this very use-case.

One of the items from the spec[1] sounds closely related:

'Adds an explicit action attribute to rules so that "deny" and "reject" actions 
can be specified in addition to the existing "allow" action. This is 
particularly important for tenant or service provider network admins that 
specify firewall policies meant to apply to all of a tenant's or service 
provider's instances, regardless of application.'

1. 
https://github.com/openstack/neutron-specs/blob/master/specs/newton/fwaas-api-2.0.rst

On Mon, Oct 31, 2016 at 5:28 PM, David G. Bingham 
> wrote:
Yo Neutron devs :-)

I was wondering if something like the following subject has come up:  
"Cloud-provider Security Groups”.

*Goal of this email*: Gauge the community’s need and see if this has come up in 
past.
*Requirement*: Apply a provider-managed global set of network flows to all 
instances.
*Use Case*: For our private cloud, have need to dynamically allow network 
traffic flows from other internal network sources across all instances.
*Basic Idea*: Provide an *admin-only* accessible security group ruleset that 
would persist and apply these "cloud-provider" security group rules to all 
instances of a cloud. This *may* be in the form of new "provider" API or an 
extension to existing API only accessible via "admin". When instances are 
created, this global SG ruleset would be applied to each VM/ironic instance. 
This feature likely should be capable of being enabled/disabled depending on 
the provider's need.

*Real example*: Company security team wants to audit consistent security 
software installations (i.e. HIPS) across our entire fleet of servers for 
compliance reporting. Each vm/ironic instance is required to have this software 
installed and up to date. Security audit team actually audits each and every 
server to ensure it is running, patched and up to date. These auditing tools 
source from a narrow set of internal IPs/ports and each instance must allow 
access to these auditing tools.

--- What we do today to hack a "cloud-provider" flow in a private cloud ---
1) We've locked down the default rules (only admins can modify which makes 
effectively kills a lot of canned neutron tools).
2) We've written an external script that iterates over all projects in our 
private cloud (~10k projects)
3) For each project:
3a) Fetch default SGs for that project and do a comparison of its default rules 
against *target* default rules
3b) Create any new missing rules, delete any removed rules
3c) Next project
This process is cumbersome, takes 20+ hours to run (over ~10k projects) and has 
to be throttled such that it doesn't over-hammer neutron while its still 
serving production traffic.

--- What we'd like to do in future ---
1) Call Security Group API that would modify a "cloud-provider" ruleset.
2) When updated, agents on HVs detect the "cloud-provider" change and then 
apply the rules across all instances.
Naturally there are going to be a lot of technical hurdles to make this happen 
while a cloud is currently in-flight.

Other uses for “Provider SGs":
* We want to enable new shared features (i.e. monitoring aaS) that all our 
internal projects can take advantage of. When the monitoring team adds/modifies 
IPs to scale, we'd apply these cloud-provider rules on behalf of all projects 
in the private cloud without users having concern themselves about the 
monitoring team's changes.
* We want to allow access to some internal sites to our VPN users on specific 
ports. These VPN ranges are dynamically changed by the VPN team. Our teams 
should not need to go into individual projects to add a new rule when VPN team 
changes ranges.
* This list could go on and on and naturally makes much more sense in a 
*private cloud* scenario, but there may be cases for public providers.

I’d be happy to create a spec.

Seen this before? Thoughts? Good, Bad or Ugly? :-)

Thanks,
David Bingham (wwriverrat on irc)
GoDaddy

Re: [openstack-dev] [keystone] new keystone core (breton)

[Chen, Wei D]

Nice to hear you are onboard, congratulation Boris!





Best Regards,

Dave Chen



From: Steve Martinelli [mailto:s.martine...@gmail.com]
Sent: Tuesday, November 01, 2016 3:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [keystone] new keystone core (breton)



I want to welcome Boris Bobrov (breton) to the keystone core team. Boris has 
been a contributor for some time and is well respected by 
the keystone team for bringing real-world operator experience and feedback. He 
has recently become more active in terms of code 
contributions and bug triaging. Upon interacting with Boris, you quickly 
realize he has a high standard for quality and keeps us 
honest.



Thanks for all your hard work Boris, I'm happy to have you on the team.



Steve Martinelli

stevemar





smime.p7s
Description: S/MIME cryptographic signature
__
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

Re: [openstack-dev] [neutron][routed-network] Host doesn't connected any segments when creating port

[shihanzhang]

hi Zhi chang,

Could you provide your ml2_conf.ini for ovs agent, I guess the reason is that 
your ovs-agent on host devstack can't handle the related segment id.


Thanks,
shihanzhang


在 2016-10-31 18:43:36，"zhi"  写道：

Hi, all.


Recently, I watch the OpenStack Summit video named ' Scaling Up OpenStack 
Networking with Routed Networks '.  Carl and Miguel made this topic.  I learned 
a lot of your topic. Thanks. 


But I have some questions about the demo in the topic. 


I do some steps according to the topic. 


First, creating two networks like this:


neutron net-create multinet --shared --segments type=dict list=true 
provider:physical_network=physnet1,provider:segmentation_id=2016,provider:network_type=vlan
 
provider:physical_network=physnet2,provider:segmentation_id=2016,provider:network_type=vlan




Second, I get two segments after creating this network. I get these segments by 
using " openstack network segment list ". 


Third, I create two subnets by these segments by using this command " 


neutron subnet-create --ip_version 4 --name multi-segment1-subnet [net-id] 
10.1.0.0/24 --segment_id [segment-id]
neutron subnet-create --ip_version 4 --name multi-segment2-subnet [net-id] 
10.1.1.0/24 --segment_id [segment-id]
 "


At last, I want to create a port with host_id. My local environment contains 
two compute nodes, one is named "devstack"  and the other is "devstack2". So I 
use this command "  neutron port-create --binding:host_id=devstack [net-id] ". 


Exception happens in neutron server. The exception says "


Host devstack is not connected to any segments on routed provider network 
[net-id].  It should be connected to one." I can not get this exact point about 
this exception. 


Why does the "routed network" have relationship with host? 


How they work together between "host info (compute node ?)" and "routed 
network"?


What should I do if I want to get rid of this exception?




Hope for your reply. Especially Carl and Miguel. ;-)






Many Thanks
Zhi Chang__
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-dev] [Neutron] Summit design summary - a heads up

[Armando M.]

Hi folks,

For those of you who missed the summit, I wanted to give a heads up that I
am working with session chairs to provide here a distilled version of any
conclusion/agreement/proposal reached in Barcelona during the Neutron track.

In the meantime, some networking related conference sessions are available
at [1].

Cheers,
Armando

[1] https://www.openstack.org/videos/search?search=networking
__
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-dev] [tripleo] Barcelona Summit summary

[Emilien Macchi]

Hi,

I thought it would be useful to have a summary of what we discussed in
Barcelona and what we plan for the next months to deliver the Ocata
release.
Please reply to this thread if you want to add more things; also
please correct me if something's wrong or incomplete in this summary.

https://etherpad.openstack.org/p/ocata-tripleo

== Release management
Ocata will be short (4 months), we'll have to be more conservative at
the end of the cycle for feature freeze exceptions, if that happens.
During Newton, we created stable/newton branches too early. In Ocata,
we'll wait more so we reduce the number of backports that we have to
do recently. We'll do a better job in synchronizing with OpenStack
release management team to find the right dates for us.

== Team organization
The team were very positive on having squads, working together on a
specific area of TripleO.  The spec
(https://review.openstack.org/#/c/385201) is still under review but
I'll address latest comments this week. Please give feedback if you
haven't done it yet. We'll give a first try during Ocata cycle and
iterate / adjust later if needed.
Regarding the "Area Experts" policy
(https://review.openstack.org/#/c/388891/), I'm not sure we've reached
a consensus yet. I would suggest to start with the squads first and
let people looking at the second spec, and give feedback.
We also want to continue Deep-dive sessions but maybe make them with
more interactions with attendees.

== Containers work
Flavio led the session and he gave a great overview of what is going to happen.
I won't replicate much what we said, here's the etherpad:
https://etherpad.openstack.org/p/ocata-tripleo-containers
A short summary though:
During Ocata, we want to focus on:
- bringing the CI job back alive and green.
- iterate on composability to expand the deployment with controller services.

== Upgrades work
Marios let the session, and the overview was also great here:
https://etherpad.openstack.org/p/ocata-tripleo-upgrades
Because of the short Ocata cycle and also because some folks are still
busy on downstream Newton releases, we won't have enough bandwidth to
address all stuffs we want in long term.
A baby-step approach will be taken here, to start iterating on
"Composable service upgrade" feature. The "How" is not clearly defined
yet, but it seems we'll continue with bash+heat for now, due to short
deadlines. Don't expect major changes on upgrades before Pike. We also
Depends-On Composable HA deployments (target is Ocata).

== CI work
4 goals for Ocata:
- Allow anyone to run what is tested by TripleO CI -
https://blueprints.launchpad.net/tripleo/+spec/make-tripleo-ci-externally-consumable
- Move TripleO CI ovb jobs into third party CI jobs using RDO cloud
and TripleO Quickstart -
https://blueprints.launchpad.net/tripleo/+spec/use-tripleo-quickstart-and-tripleo-quickstart-extras-for-the-tripleo-ci-toolset
- Extend multinode jobs to more than more than 2 nodes -
https://blueprints.launchpad.net/tripleo/+spec/add-3-node-multinode-job
- Improve Tempest tests results visibility.

Note on the last item: I'm interested to also switch the deployment of
multinode job by using tripleo-quickstart, to have consistency on our
tools.

== GUI / CLI / Validations work
One of the main goals for Ocata is to bring parity between CLI and UI,
and improve/stabilize deployment/upgrade worlkflows.
All details here: https://etherpad.openstack.org/p/gui-ocata


== Features in Ocata
Here are the blueprints for Ocata:
https://blueprints.launchpad.net/tripleo/ocata

Our major and more important features are:
- Composable upgrades
- Composable HA
- Deploy undercloud with Heat
- TLS / IPv6 work
- CI improvements


Please let us know any question or feedback about our roadmap.

I was very happy to see you and our sessions were quite productive,
I'm looking forward to meeting you in Atlanta!
-- 
Emilien Macchi

__
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

Re: [openstack-dev] [neutron] Cloud Provider Security Groups

[Kevin Benton]

I believe the FWaaS v2 work is attempting to capture this concept of
provider-set rules to address this very use-case.

One of the items from the spec[1] sounds closely related:

'Adds an explicit action attribute to rules so that "deny" and "reject"
actions can be specified in addition to the existing "allow" action. This
is particularly important for tenant or service provider network admins
that specify firewall policies meant to apply to all of a tenant's or
service provider's instances, regardless of application.'

1.
https://github.com/openstack/neutron-specs/blob/master/specs/newton/fwaas-api-2.0.rst

On Mon, Oct 31, 2016 at 5:28 PM, David G. Bingham 
wrote:

> Yo Neutron devs :-)
>
> I was wondering if something like the following subject has come up:
> "Cloud-provider Security Groups”.
>
> *Goal of this email*: Gauge the community’s need and see if this has come
> up in past.
> *Requirement*: Apply a provider-managed global set of network flows to all
> instances.
> *Use Case*: For our private cloud, have need to dynamically allow network
> traffic flows from other internal network sources across all instances.
> *Basic Idea*: Provide an *admin-only* accessible security group ruleset
> that would persist and apply these "cloud-provider" security group rules to
> all instances of a cloud. This *may* be in the form of new "provider" API
> or an extension to existing API only accessible via "admin". When instances
> are created, this global SG ruleset would be applied to each VM/ironic
> instance. This feature likely should be capable of being enabled/disabled
> depending on the provider's need.
>
> *Real example*: Company security team wants to audit consistent security
> software installations (i.e. HIPS) across our entire fleet of servers for
> compliance reporting. Each vm/ironic instance is required to have this
> software installed and up to date. Security audit team actually audits each
> and every server to ensure it is running, patched and up to date. These
> auditing tools source from a narrow set of internal IPs/ports and each
> instance must allow access to these auditing tools.
>
> --- What we do today to hack a "cloud-provider" flow in a private cloud ---
> 1) We've locked down the default rules (only admins can modify which makes
> effectively kills a lot of canned neutron tools).
> 2) We've written an external script that iterates over all projects in our
> private cloud (~10k projects)
> 3) For each project:
> 3a) Fetch default SGs for that project and do a comparison of its default
> rules against *target* default rules
> 3b) Create any new missing rules, delete any removed rules
> 3c) Next project
> This process is cumbersome, takes 20+ hours to run (over ~10k projects)
> and has to be throttled such that it doesn't over-hammer neutron while its
> still serving production traffic.
>
> --- What we'd like to do in future ---
> 1) Call Security Group API that would modify a "cloud-provider" ruleset.
> 2) When updated, agents on HVs detect the "cloud-provider" change and then
> apply the rules across all instances.
> Naturally there are going to be a lot of technical hurdles to make this
> happen while a cloud is currently in-flight.
>
> Other uses for “Provider SGs":
> * We want to enable new shared features (i.e. monitoring aaS) that all our
> internal projects can take advantage of. When the monitoring team
> adds/modifies IPs to scale, we'd apply these cloud-provider rules on behalf
> of all projects in the private cloud without users having concern
> themselves about the monitoring team's changes.
> * We want to allow access to some internal sites to our VPN users on
> specific ports. These VPN ranges are dynamically changed by the VPN team.
> Our teams should not need to go into individual projects to add a new rule
> when VPN team changes ranges.
> * This list could go on and on and naturally makes much more sense in a
> *private cloud* scenario, but there may be cases for public providers.
>
> I’d be happy to create a spec.
>
> Seen this before? Thoughts? Good, Bad or Ugly? :-)
>
> Thanks,
> David Bingham (wwriverrat on irc)
> GoDaddy
>
> __
> 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 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

Re: [openstack-dev] [packstack] Proposal to add Alfredo Moralejo as core reviewer

[Emilien Macchi]

I'm not core but I've worked with Alfredo many times, and always was
very glad to have him onboard.
+1 on this addition.

On Mon, Oct 31, 2016 at 10:00 AM, David Moreau Simard  wrote:
> +1, Alfredo has been doing an excellent job both in contributions and
> in reviews.
>
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
>
> On Fri, Oct 28, 2016 at 6:44 AM, Javier Pena  wrote:
>> Hi all,
>>
>> I'd like to propose Alfredo Moralejo (amoralej in #Freenode) as a core 
>> reviewer for Packstack.
>>
>> Alfredo has been providing consistent and quality reviews during the Newton 
>> cycle, and also a good number of patches [1].
>>
>> Existing core reviewers, please vote now.
>>
>> Regards,
>> Javier
>>
>> [1] 
>> https://review.openstack.org/#/q/status:merged+owner:%22Alfredo+Moralejo+%253Camoralej%2540redhat.com%253E%22+project:openstack/packstack
>
> __
> 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



-- 
Emilien Macchi

__
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-dev] [neutron] Cloud Provider Security Groups

[David G. Bingham]

Yo Neutron devs :-)

I was wondering if something like the following subject has come up:  
"Cloud-provider Security Groups”.

*Goal of this email*: Gauge the community’s need and see if this has come up in 
past.
*Requirement*: Apply a provider-managed global set of network flows to all 
instances.
*Use Case*: For our private cloud, have need to dynamically allow network 
traffic flows from other internal network sources across all instances.
*Basic Idea*: Provide an *admin-only* accessible security group ruleset that 
would persist and apply these "cloud-provider" security group rules to all 
instances of a cloud. This *may* be in the form of new "provider" API or an 
extension to existing API only accessible via "admin". When instances are 
created, this global SG ruleset would be applied to each VM/ironic instance. 
This feature likely should be capable of being enabled/disabled depending on 
the provider's need.

*Real example*: Company security team wants to audit consistent security 
software installations (i.e. HIPS) across our entire fleet of servers for 
compliance reporting. Each vm/ironic instance is required to have this software 
installed and up to date. Security audit team actually audits each and every 
server to ensure it is running, patched and up to date. These auditing tools 
source from a narrow set of internal IPs/ports and each instance must allow 
access to these auditing tools.

--- What we do today to hack a "cloud-provider" flow in a private cloud ---
1) We've locked down the default rules (only admins can modify which makes 
effectively kills a lot of canned neutron tools).
2) We've written an external script that iterates over all projects in our 
private cloud (~10k projects)
3) For each project:
3a) Fetch default SGs for that project and do a comparison of its default rules 
against *target* default rules
3b) Create any new missing rules, delete any removed rules
3c) Next project
This process is cumbersome, takes 20+ hours to run (over ~10k projects) and has 
to be throttled such that it doesn't over-hammer neutron while its still 
serving production traffic.

--- What we'd like to do in future ---
1) Call Security Group API that would modify a "cloud-provider" ruleset.
2) When updated, agents on HVs detect the "cloud-provider" change and then 
apply the rules across all instances.
Naturally there are going to be a lot of technical hurdles to make this happen 
while a cloud is currently in-flight.

Other uses for “Provider SGs":
* We want to enable new shared features (i.e. monitoring aaS) that all our 
internal projects can take advantage of. When the monitoring team adds/modifies 
IPs to scale, we'd apply these cloud-provider rules on behalf of all projects 
in the private cloud without users having concern themselves about the 
monitoring team's changes.
* We want to allow access to some internal sites to our VPN users on specific 
ports. These VPN ranges are dynamically changed by the VPN team. Our teams 
should not need to go into individual projects to add a new rule when VPN team 
changes ranges.
* This list could go on and on and naturally makes much more sense in a 
*private cloud* scenario, but there may be cases for public providers.

I’d be happy to create a spec.

Seen this before? Thoughts? Good, Bad or Ugly? :-)

Thanks,
David Bingham (wwriverrat on irc)
GoDaddy
__
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

Re: [openstack-dev] [keystone] new keystone core (breton)

[Davanum Srinivas]

Great job Boris!

On Mon, Oct 31, 2016 at 4:12 PM, Lance Bragstad  wrote:
> Great work Boris. Welcome to the team!
>
> On Mon, Oct 31, 2016 at 2:50 PM, Kristi Nikolla  wrote:
>>
>> Congrats Boris! Well deserved!
>>
>> Kristi
>>
>> On 10/31/2016 03:46 PM, Steve Martinelli wrote:
>> > I want to welcome Boris Bobrov (breton) to the keystone core team. Boris
>> > has been a contributor for some time and is well respected by the
>> > keystone team for bringing real-world operator experience and feedback.
>> > He has recently become more active in terms of code contributions and
>> > bug triaging. Upon interacting with Boris, you quickly realize he has a
>> > high standard for quality and keeps us honest.
>> >
>> > Thanks for all your hard work Boris, I'm happy to have you on the team.
>> >
>> > Steve Martinelli
>> > stevemar
>> >
>> >
>> >
>> >
>> > __
>> > 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 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 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

Re: [openstack-dev] [keystone] new keystone core (breton)

[Lance Bragstad]

Great work Boris. Welcome to the team!

On Mon, Oct 31, 2016 at 2:50 PM, Kristi Nikolla  wrote:

> Congrats Boris! Well deserved!
>
> Kristi
>
> On 10/31/2016 03:46 PM, Steve Martinelli wrote:
> > I want to welcome Boris Bobrov (breton) to the keystone core team. Boris
> > has been a contributor for some time and is well respected by the
> > keystone team for bringing real-world operator experience and feedback.
> > He has recently become more active in terms of code contributions and
> > bug triaging. Upon interacting with Boris, you quickly realize he has a
> > high standard for quality and keeps us honest.
> >
> > Thanks for all your hard work Boris, I'm happy to have you on the team.
> >
> > Steve Martinelli
> > stevemar
> >
> >
> >
> > 
> __
> > 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 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 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

Re: [openstack-dev] [keystone] new keystone core (breton)

[Kristi Nikolla]

Congrats Boris! Well deserved!

Kristi

On 10/31/2016 03:46 PM, Steve Martinelli wrote:
> I want to welcome Boris Bobrov (breton) to the keystone core team. Boris
> has been a contributor for some time and is well respected by the
> keystone team for bringing real-world operator experience and feedback.
> He has recently become more active in terms of code contributions and
> bug triaging. Upon interacting with Boris, you quickly realize he has a
> high standard for quality and keeps us honest.
> 
> Thanks for all your hard work Boris, I'm happy to have you on the team.
> 
> Steve Martinelli
> stevemar
> 
> 
> 
> __
> 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
> 



signature.asc
Description: OpenPGP digital signature
__
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-dev] [keystone] new keystone core (breton)

[Steve Martinelli]

I want to welcome Boris Bobrov (breton) to the keystone core team. Boris
has been a contributor for some time and is well respected by the keystone
team for bringing real-world operator experience and feedback. He has
recently become more active in terms of code contributions and bug
triaging. Upon interacting with Boris, you quickly realize he has a high
standard for quality and keeps us honest.

Thanks for all your hard work Boris, I'm happy to have you on the team.

Steve Martinelli
stevemar
__
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-dev] [All] Cross project prorietary driver code recap

[Sean McGinnis]

Last Tuesday we had a cross-project session around the use of proprietary
code/libs/binaries in OpenStack drivers. The challenge we are running into
is where to draw the line with these drivers. What is the appropriate policy
to have in place to allow/disallow certain approaches.

There was a lot of good discussion and input from multiple projects that are
affected by this. I won't attempt to recap the full conversation here. The
etherpad with the notes from the discussion can be found here:

https://etherpad.openstack.org/p/ocata-xp-proprietary-drivers

The two main concerns I heard were around 1) the ability to package and
redistribute everything needed to run an OpenStack environment, and 2) the
value these drivers bring to the OpenStack project. Particularly those that
have no business logic in the code in OpenStack and just call out to third
party libraries to handle all business logic.

Proposals
=

Option 1:

- All libraries imported by the driver must be licensed such that they are
  redistributable by package maintainers.
- Existing non-compliant driver code would need to be updated by the Q
  release to stay in tree.
- Code that does not get imported into the driver at runtime (CLIs, external
  binaries, remote application servers) are acceptable to be not
  redistributable.

Issues:

- The desire for having things redistributable was to have everything fully
  functional "out of the box" no matter how the deployer configured the system.
  I don't believe this is ever possible. With requirements of setting up some
  type of application or management server to enable some solutions, it is not
  possible to package all required code and binaries for every configuration.


Option 2:

- Remove all drivers that are not completely open source and contained in the
  project repo.

Issues:

- This restricts things down to only the drivers that can currently be run in
  gate.
- This would be a big issue for many Cinder drivers and I'm sure most Ironic
  drivers.
- I strongly believe this would result in less vendor involvement in upstream
  work.


Option 3:

- Require the majority of business logic is in the open source code.
- Allow third party, non-redistributable libraries and CLIs that are used as
  more of an "RPC" type interface.
- Reviewers should be able to review the driver code and at least get some
  idea of the steps the driver is doing to perform each requested operation.

Issues:

- Does not address the desire to package all needed requirements.



My preference is actually option 3. The reality is, with most vendor solutions
there's always going to be some part of the overall solution that is
proprietary and requires some configuration and setup by the deployer.
Arbitrarily drawing that line such that a proprietary app server is OK, but a
proprietary library is not OK, just leads to poor solution architectures such
as requiring the end user to set up a separate server just so the driver can
SSH into it to run commands.

The case that instigated this discussion for me was a proposal to have a driver
that did nothing more than make a one line call of everything out to a library
that handled all logic. In that case, there is no benefit to the community of
being able to review the code and give some assurance that it is doing things
correctly. And the only benefit really it gives the vendor is they have an out
of tree driver that gets advertised as being in tree.

My desire as a code reviewer and project maintainer is that I can take a look
at a driver and at least get an idea of what they are doing and how their
device works to perform some of these operations. That's not an exact number -
I'm not saying something like 10% of the code needs to be in the driver, but
9% would not be acceptable - but we need to have some visiblity to the logic
so we as a community can at least help point users in the right direction if
they come looking for help.

I think this works for Cinder and probably is necessary for Ironic.

I'd be interested in hearing feedback or other options from other folks. I'd
especially like to hear from Helion, OSP, Mirantis, and others that are doing
packaging and support for these deployments to hear how this impacts the way
they do things.

Thanks!

Sean (smcginnis)

__
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-dev] [neutron][calico] networking-calico IRC meeting tomorrow

[Neil Jerram]

Hi all; just wanted to remind that there will be a networking-calico IRC
meeting tomorrow [1].  Please feel free to add to the agenda at [2] (or ask
me to do that if you prefer).

Thanks!
Neil

[1] http://eavesdrop.openstack.org/#Networking_Calico_Meeting
[2]
https://wiki.openstack.org/wiki/Meetings/NetworkingCalico#Agenda_for_2016-10-31
__
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-dev] [puppet] weekly meeting #95

[Alex Schultz]

Hey folks,

Just a reminder that we will have our meeting tomorrow at 3pm UTC on
#openstack-meeting-4.

Here's the current agenda:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20161101

Thanks,
-Alex

__
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

Re: [openstack-dev] [Ceilometer]: Instance creation and deletion metrics in ceilometer !

[gordon chung]

what meters are you looking for specifically? as Ganpat mentioned, we 
only derive a few meters from Nova notifications[1]. i don't understand 
your comment about being able to see events on kafka. by 'events' do you 
mean Ceilometer Events[2]?

[1] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/meter/data/meters.yaml#L83-L127
[2] http://docs.openstack.org/developer/ceilometer/events.html



On 31/10/16 04:27 AM, Raghunath D wrote:
> Hi Ganpat,
>
> I want the samples related with these events.
>
> With Best Regards
> Raghunath Dudyala
> Tata Consultancy Services Limited
> Mailto: raghunat...@tcs.com
> Website: http://www.tcs.com
> 
> Experience certainty. IT Services
> Business Solutions
> Consulting
> 
>
>
> -Ganpat Agarwal  wrote: -
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> From: Ganpat Agarwal 
> Date: 10/27/2016 12:02PM
> Subject: Re: [openstack-dev] [Ceilometer]: Instance creation and
> deletion metrics in ceilometer !
>
> Hi Raghunath,
>
> I am not able to understand your use case for compute.instance.* events.
>
> You are trying to catch the instance start and end events OR you want
> the samples related with these events?
>
> Regards,
> Ganpat
>
> On Wed, Oct 26, 2016 at 6:00 PM, Raghunath D  > wrote:
>
> Hi Ganpat/Gord,
>
> Callback for compute.instance.create.end events under
> ceilometer.compute.notifications should be invoked for those
> notification events on the nova exchange using the
> notifications.info  topic.
> But this is not happening,we can see events related to them and can
> receive events over kafka.
>
> I can see from logs which print my debug print during the loading of
> notification plugin.
> "2016-10-26 03:46:32.010 34977 INFO
> ceilometer.compute.notifications.instance
> [req-1ad3d5c9-5eab-404d-9fbe-f1605e93691f - - - - -] Check
> ComputeInstanceNotificationBase notification:"
>
> Do we need to change any thing in the configuration file of
> ceilometer or nova to achive this.
> It would be great help for me if this is fixed.
>
> With Best Regards
> Raghunath Dudyala
> Tata Consultancy Services Limited
> Mailto: raghunat...@tcs.com 
> Website: http://www.tcs.com
> 
> Experience certainty. IT Services
> Business Solutions
> Consulting
> 
>
>
> -Ganpat Agarwal  > wrote: -
> To: "OpenStack Development Mailing List (not for usage questions)"
>  >
> From: Ganpat Agarwal  >
> Date: 10/25/2016 09:32PM
>
> Subject: Re: [openstack-dev] [Ceilometer]: Instance creation and
> deletion metrics in ceilometer !
>
> Hi Raghunath,
>
> You can look at this file for details of meters related with
> compute.instance.*
>
> ceilometer/meter/data/meters.yaml
>
> Additionally, you can look at this link for compute meters documentation
>
> http://docs.openstack.org/admin-guide/telemetry-measurements.html
> 
>
>
> Also, have a look at "Meters definitions" section on this link
>
> 
> http://docs.openstack.org/admin-guide/telemetry-data-collection.html#meter-definitions
> 
> 
>
> Regards,
> Ganpat
>
>
> On Tue, Oct 25, 2016 at 5:45 PM, Raghunath D  > wrote:
>
> Hi Ganpat,
>
>  Are you able to see merers/samples related to
> compute.instance.* in ceilometer meter-list or ceilometer
> sample-list.
> My application which will read info from ceilometer publisher
> (pipeline.yaml) and I am looking for meters realted to
> ceilometer.instance.*
>
> With Best Regards
> Raghunath Dudyala
> Tata Consultancy Services Limited
> Mailto: raghunat...@tcs.com 
> Website: http://www.tcs.com
> 
> Experience certainty. IT Services
> Business Solutions
> Consulting
> 
>
>
> -Ganpat Agarwal  > wrote: -
> To: "OpenStack Development Mailing List (not for usage
> 

[openstack-dev] [nova][bugs] No Nova Bugs Team Meeting this Week

[Augustina Ragwitz]

I am unable to host the Bug Team Meeting this week because I'm starting
a new job and will be getting orientated. As usual, if you have bug
related questions, I'm available via email and IRC.

Our next U.S. time meeting will be on November 15, 1800 UTC. While I
don't predict future scheduling conflicts, if anyone is interested in
being a backup to run the U.S. time bugs meeting, please let me know!

-- 
Augustina Ragwitz
Señora Software Engineer
---
Ask me about contributing to OpenStack Nova!
https://wiki.openstack.org/wiki/Nova/Mentoring

Waiting for your change to get through the gate? Clean up some Nova
bugs!
http://45.55.105.55:8082/bugs-dashboard.html
---
email: aragwitz+n...@pobox.com
irc: auggy

__
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

Re: [openstack-dev] [nova] Ocata release schedule

[Sean McGinnis]

On Mon, Oct 31, 2016 at 08:56:43AM -0500, Matt Riedemann wrote:
> I plan on posting some recaps of the design summit sessions, but I
> wanted to quickly get out the Ocata release schedule for Nova.
> That's in the wiki here:
> 
> https://wiki.openstack.org/wiki/Nova/Ocata_Release_Schedule#Dates_Overview
> 
> The only Nova-specific milestone in there is spec approval freeze on
> o-1, which is November 17th.
> 
> Probably the most important note is what's omitted, which is that we
> won't have a non-priority blueprint feature freeze this cycle. So
> we're going to be driving all blueprints to the same OpenStack-wide
> feature freeze date of January 26th. Given the shorter cycle it just
> didn't make sense to time box the non-priority blueprints.
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 

Matt, do you plan on adding some of those dates here:

https://releases.openstack.org/ocata/schedule.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

Re: [openstack-dev] [ironic][ironic-python-agent]ask something about this commit https://review.openstack.org/#/c/369245/

[Jim Rollenhagen]

On Mon, Oct 31, 2016 at 3:46 AM,   wrote:
> Hi ironic team：
>
> I send this email to ask something about
> https://review.openstack.org/#/c/369245/ .
>
> The jenkins has -1 for this commit.After I rebase the code Oct 27，this
> commit didn't pass the jenkins anymore.
>
> And I don't know what caused -1，the log just showed below：

Hi zhouya, thanks for catching this. Looks like ironic-python-agent CI
is mostly down due to networking issues. I'm digging into this now,
but for now don't bother rechecking the tests.

// jim

__
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

Re: [openstack-dev] [packstack] Proposal to add Alfredo Moralejo as core reviewer

[David Moreau Simard]

+1, Alfredo has been doing an excellent job both in contributions and
in reviews.

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]


On Fri, Oct 28, 2016 at 6:44 AM, Javier Pena  wrote:
> Hi all,
>
> I'd like to propose Alfredo Moralejo (amoralej in #Freenode) as a core 
> reviewer for Packstack.
>
> Alfredo has been providing consistent and quality reviews during the Newton 
> cycle, and also a good number of patches [1].
>
> Existing core reviewers, please vote now.
>
> Regards,
> Javier
>
> [1] 
> https://review.openstack.org/#/q/status:merged+owner:%22Alfredo+Moralejo+%253Camoralej%2540redhat.com%253E%22+project:openstack/packstack

__
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-dev] [nova] Ocata release schedule

[Matt Riedemann]

I plan on posting some recaps of the design summit sessions, but I 
wanted to quickly get out the Ocata release schedule for Nova. That's in 
the wiki here:


https://wiki.openstack.org/wiki/Nova/Ocata_Release_Schedule#Dates_Overview

The only Nova-specific milestone in there is spec approval freeze on 
o-1, which is November 17th.


Probably the most important note is what's omitted, which is that we 
won't have a non-priority blueprint feature freeze this cycle. So we're 
going to be driving all blueprints to the same OpenStack-wide feature 
freeze date of January 26th. Given the shorter cycle it just didn't make 
sense to time box the non-priority blueprints.


--

Thanks,

Matt Riedemann


__
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-dev] [cinder] [nova] Cinder-Nova API changes weekly meeting cancelled today

[Ildiko Vancsa]

Hi,

As many of us are either traveling or still jet lagged today we agreed to skip 
the today’s meeting.

The next meeting will be held __ next Monday (November 7) at 1700UTC__.

We had progress with the discussions last week and we seem to orient towards a 
simpler Cinder API, but we still need to discuss a few things. To be efficient 
we plan to have the next week’s meeting on Hangouts with meeting minutes on the 
IRC channel.

If you have any questions please feel free to ping me any time.

For further pointer and status information please see the links on top of this 
etherpad: https://etherpad.openstack.org/p/cinder-nova-api-changes 


Thanks and Best Regards,
Ildikó
(IRC: ildikov)__
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

Re: [openstack-dev] Openstack Mitaka + neutron openVswitch + VMware-NSX plugin

[Gary Kotton]

Hi,
There are a number of different Neutron VMware plugins. These are as follows:

-  NSXv – this is a NSX plugin for vSphere only. This requires the NSX 
to be installed.

-  NSXv3 – this is a NSX plugin for a multi hypervisor environment. The 
following hypervisors are supported:

oKVM

oESX

oHyperV

-  DVS – this is a very simple plugin that provides isolated tenant 
networks. This plugin does not have security group and routing support. The 
purpose of this was to enable a cloud admin to get the ‘look and feel’ of 
Neutron and to be able to have basic network connectivity. Having said that it 
works pretty well ☺. This plugin requires the DHCP and metadata agents.

The NSX and NSXv3 plugins do not require any agents. They have native DHCP and 
metadata support. From the requirements below it sounds like you need the NSXv3 
plugin.
Thanks
Gary

From: Thiyagu Jayaraju 
Reply-To: OpenStack List 
Date: Thursday, October 27, 2016 at 12:08 AM
To: OpenStack List 
Subject: [openstack-dev] Openstack Mitaka + neutron openVswitch + VMware-NSX 
plugin



From: Thiyagu Jayaraju [mailto:thiyag...@veritas.com]
Sent: Wednesday, October 26, 2016 2:03 PM
To: openstack-dev@lists.openstack.org
Subject: Openstack Mitaka + neutron openVswitch + VMware-NSX plugin
Importance: High

HI Openstack team,

I’m in the process of integrating VMware infrastructure with my existing 
Openstack infrastructure and the details of the same are as follows … Can you 
please let me know , whether these two components can co-exist together in the 
same infrastructure.

Controller node --> 1 single controller --> CentOS 7 --> Running Mitaka release.
Network node --> 1 single network node --> CentOS 7 --> Running Mitaka release 
--> Neutron openVswitch as ML2 Plugin. --> Distributed Virtual Router (DVR) 
enabled.
Compute node --> 5 compute nodes --> CentOS 7 --> Running Mitaka release -->  
KVM hypervisor --> Neutron openVswitch agent --> Distributed Virtual Router 
(DVR) enabled.
Cinder node --> 1 single Cinder block node --> CentOS 7 --> Running Mitaka 
release -->  Ceph rbd backend.

Requirement :

My VMware infrastructure (vCenter server appliance 6.x) needs to be integrated 
with the above mentioned NEUTRON infrastructure using NSX plugin at the same 
time my existing infrastructure should remain intact.  Or is there any other 
way available  to accomplish this without any impact to the existing 
infrastructure ?

Kindly let me know whether this is possible ?  if so kindly share me the steps 
to get it configured …

Thanks
-TJ
__
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

Re: [openstack-dev] [nova] [searchlight] Discrepancies between nova server notifications and API response

[Matt Riedemann]

On 10/28/2016 4:32 PM, McLellan, Steven wrote:

Hi,

I was unfortunately unable to make the summit but I'm told there were
some good discussions around possible integration with searchlight to
help some scaling cases with nova cells. One issue we've had with
Searchlight is differences between the notifications and API
representation of server state, and Travis asked me to file some bug
reports against Nova to get a conversation started. I've filed four bugs
at https://bugs.launchpad.net/nova/+bugs?field.tag=searchlight (the
reason for separating them is that some may not be
straightforward/possible) to that end. I am out next week, but it would
be great to get some time at one of the nova weekly meetings the
following weeks to discuss it further.

Thanks, and safe travels for those returning home from the summit,

Steve


__
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



Thanks, I'll start going through these. Some of them might be covered by 
specs that are being worked in Ocata.


Also note that others that are for resources which get proxied from 
nova, like security groups in this bug:


https://bugs.launchpad.net/nova/+bug/1637635

Won't be fixed because nova is deprecating the APIs to perform CRUD 
operations on proxy resources, like network resources. You'd get that 
information from Neutron.


--

Thanks,

Matt Riedemann


__
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-dev] [tripleo] second newton release

[Emilien Macchi]

Hi,

I'm preparing a second newton release, since we fixed a quite good
number of things since GA.
Please let me know if there are bugfixes you want in this new release,
otherwise I'll process it on Wednesday afternoon.

Thanks,
-- 
Emilien Macchi

__
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-dev] [neutron][routed-network] Host doesn't connected any segments when creating port

[zhi]

Hi, all.

Recently, I watch the OpenStack Summit video named ' Scaling Up OpenStack
Networking with Routed Networks '.  Carl and Miguel made this topic.  I
learned a lot of your topic. Thanks.

But I have some questions about the demo in the topic.

I do some steps according to the topic.

First, creating two networks like this:

neutron net-create multinet --shared --segments type=dict list=true
provider:physical_network=physnet1,provider:segmentation_id=2016,provider:network_type=vlan

provider:physical_network=physnet2,provider:segmentation_id=2016,provider:network_type=vlan


Second, I get two segments after creating this network. I get these
segments by using " openstack network segment list ".

Third, I create two subnets by these segments by using this command "

neutron subnet-create --ip_version 4 --name multi-segment1-subnet [net-id]
10.1.0.0/24 --segment_id [segment-id]
neutron subnet-create --ip_version 4 --name multi-segment2-subnet [net-id]
10.1.1.0/24 --segment_id [segment-id]
 "

At last, I want to create a port with host_id. My local environment
contains two compute nodes, one is named "devstack"  and the other is
"devstack2". So I use this command "  neutron port-create
--binding:host_id=devstack [net-id] ".

Exception happens in neutron server. The exception says "

Host devstack is not connected to any segments on routed provider network
[net-id].  It should be connected to one." I can not get this exact point
about this exception.

Why does the "routed network" have relationship with host?

How they work together between "host info (compute node ?)" and "routed
network"?

What should I do if I want to get rid of this exception?


Hope for your reply. Especially Carl and Miguel. ;-)



Many Thanks
Zhi Chang
__
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

Re: [openstack-dev] [Ceilometer]: Instance creation and deletion metrics in ceilometer !

[Raghunath D]

 Hi Ganpat,

I want the samples related with these events.

With Best Regards
 Raghunath Dudyala
 Tata Consultancy Services Limited
 Mailto: raghunat...@tcs.com
 Website: http://www.tcs.com
 
 Experience certainty.  IT Services
Business Solutions
Consulting
 
 

-Ganpat Agarwal  wrote: -
To: "OpenStack Development Mailing List (not for usage questions)" 

From: Ganpat Agarwal 
Date: 10/27/2016 12:02PM
Subject: Re: [openstack-dev] [Ceilometer]: Instance creation and deletion 
metrics in ceilometer !

Hi Raghunath,

I am not able to understand your use case for compute.instance.* events.

You are trying to catch the instance start and end events OR you want the 
samples related with these events?

Regards,
Ganpat

On Wed, Oct 26, 2016 at 6:00 PM, Raghunath D  wrote:
 Hi Ganpat/Gord,

Callback for compute.instance.create.end events under 
ceilometer.compute.notifications should be invoked for those notification 
events on the nova exchange using the notifications.info topic. 
But this is not happening,we can see events related to them and can receive 
events over kafka.

I can see from logs which print my debug print during the loading of 
notification plugin.
"2016-10-26 03:46:32.010 34977 INFO ceilometer.compute.notifications.instance 
[req-1ad3d5c9-5eab-404d-9fbe-f1605e93691f - - - - -] Check 
ComputeInstanceNotificationBase notification:"

Do we need to change any thing in the configuration file of ceilometer or nova 
to achive this.
It would be great help for me if this is fixed.

With Best Regards
 Raghunath Dudyala
 Tata Consultancy Services Limited
 Mailto: raghunat...@tcs.com
 Website: http://www.tcs.com
 
 Experience certainty.IT Services
 Business Solutions
 Consulting
 
 

-Ganpat Agarwal  wrote: -
To: "OpenStack Development Mailing List (not for usage questions)" 

From: Ganpat Agarwal 
Date: 10/25/2016 09:32PM

Subject: Re: [openstack-dev] [Ceilometer]: Instance creation and deletion 
metrics in ceilometer !

Hi Raghunath,

You can look at this file for details of meters related with compute.instance.*

ceilometer/meter/data/meters.yaml

Additionally, you can look at this link for compute meters documentation

http://docs.openstack.org/admin-guide/telemetry-measurements.html


Also, have a look at "Meters definitions" section on this link

http://docs.openstack.org/admin-guide/telemetry-data-collection.html#meter-definitions

Regards,
Ganpat


On Tue, Oct 25, 2016 at 5:45 PM, Raghunath D  wrote:
 Hi Ganpat,

 Are you able to see merers/samples related to compute.instance.* in ceilometer 
meter-list or ceilometer sample-list.
My application which will read info from ceilometer publisher (pipeline.yaml) 
and I am looking for meters realted to ceilometer.instance.*

With Best Regards
 Raghunath Dudyala
 Tata Consultancy Services Limited
 Mailto: raghunat...@tcs.com
 Website: http://www.tcs.com
 
 Experience certainty.IT Services
 Business Solutions
 Consulting
 
 

-Ganpat Agarwal  wrote: -
To: "OpenStack Development Mailing List (not for usage questions)" 

From: Ganpat Agarwal 
Date: 10/25/2016 05:05PM
Subject: Re: [openstack-dev] [Ceilometer]: Instance creation and deletion 
metrics in ceilometer !


Hi,

I am able to get event notifications on kafka by applying these configurations:

nova.conf
instance_usage_audit = True
instance_usage_audit_period = hour
notify_on_state_change = vm_and_task_state

notification_driver = messagingv2

Restart nova compute service

ceilometer.conf
 [event]
 drop_unmatched_notifications = False
 definitions_cfg_file = /etc/ceilometer/event_definitions.yaml


event_pipeline.yaml
---
sources:
    - name: event_source
      events:
         - compute.instance.*
      sinks:
          - event_sink
sinks:
    - name: event_sink
      transformers:
      triggers:
      publishers:
          #- notifier://
          #- file:///home/stack/test?max_bytes=1000_count=5
  
          - kafka://kafka-broker:9092?topic=ceilometer


service ceilometer-api restart
 
service ceilometer-agent-notification restart


Wait for couple of minutes and you should be getting the events on your kafka 
consumer and in ceilometer notifications logs as well



tail -f 

[openstack-dev] [ironic][ironic-python-agent]ask something about this commit https://review.openstack.org/#/c/369245/

[zhou . ya]

Hi ironic team：

I send this email to ask something about 
https://review.openstack.org/#/c/369245/ .

The jenkins has -1 for this commit.After I rebase the code Oct 27，this 
commit didn't pass the jenkins anymore.

And I don't know what caused -1，the log just showed below：

http://logs.openstack.org/45/369245/30/check/gate-tempest-dsvm-ironic-ipa-wholedisk-agent_ssh-coreos-src/e3314e2/console.html

2016-10-31 03:40:39.980383 | fe80::b dev eth0 lladdr 74:a0:2f:b7:01:7f 
router STALE

2016-10-31 03:40:39.980443 | 2001:4800:1ae1:18::3 dev eth0  FAILED

2016-10-31 03:40:39.980466 | fe80::a dev eth0 lladdr 88:1d:fc:6c:67:7f 
router STALE

2016-10-31 03:40:39.980485 | 2001:4800:1ae1:18::2 dev eth0  FAILED

2016-10-31 03:40:39.980503 | fe80::def dev eth0 lladdr 00:05:73:a0:00:06 
router DELAY

2016-10-31 03:40:39.980519 | 10.0.0.1 dev eth0 lladdr fa:16:3e:1e:ff:49 
STALE

2016-10-31 03:40:39.980530 | Route to Git mirror...

and this：

2016-10-31 03:43:09.162879 | Running devstack

2016-10-31 03:43:09.162935 | ... this takes 10 - 15 minutes (logs in 
logs/devstacklog.txt.gz)

2016-10-31 03:58:17.787588 | + ./safe-devstack-vm-gate-wrap.sh:main:L590:  
GATE_RETVAL=1

2016-10-31 03:58:17.787645 | + ./safe-devstack-vm-gate-wrap.sh:main:L591:  
'[' 1 -ne 0 ']'

2016-10-31 03:58:17.787702 | + ./safe-devstack-vm-gate-wrap.sh:main:L592:  
echo 'ERROR: the main setup script run by this job failed - exit code: 1'

2016-10-31 03:58:17.787728 | ERROR: the main setup script run by this job 
failed - exit code: 1

2016-10-31 03:58:17.787748 | + ./safe-devstack-vm-gate-wrap.sh:main:L595:  
RETVAL=1

2016-10-31 03:58:17.787768 | + ./safe-devstack-vm-gate-wrap.sh:main:L597:  
'[' 1 -ne 0 ']'

It would be a great help of you to spend some spare time to look into this 
commit and give me some advice about what caused this problem.


Thank you very much.

Looking forward for your response.
Regards
zhouya

__
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