Re: [openstack-dev] [Neutron][QoS] Pod time at Paris Summit
Hi Sean, Will be great to meet in person and discuss QoS adoption path. Count me in, Irena -Original Message- From: Collins, Sean [mailto:sean_colli...@cable.comcast.com] Sent: Tuesday, October 28, 2014 8:17 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][QoS] Pod time at Paris Summit Hi, Like Atlanta, I will be at the summit. If there is interest, I can schedule a time to talk about the QoS API extension. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][QoS] Pod time at Paris Summit
I believe Déjà vu is an appropriate term here. :-) Count me in. On Tue, Oct 28, 2014 at 1:16 PM, Collins, Sean sean_colli...@cable.comcast.com wrote: Hi, Like Atlanta, I will be at the summit. If there is interest, I can schedule a time to talk about the QoS API extension. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading
This is very interesting problem to solve. I am curious to know how the reachability is provided across different Datacenter. How to know which VM is part of which Datacenter? VM may be in different Zone but under same DC or in different DC itself. How this problem is solved? thanks regards, keshava -- View this message in context: http://openstack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-tp54115p56323.html Sent from the Developer mailing list archive at Nabble.com. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][nova] New specs on routed networking
Some of us are looking at a different model. I’d be interested in your thoughts. The premise in this is that a great deal of the complexity in OpenStack is basically working around the deficiencies of IPv4, especially its address space and issues in multicast deployment. IPv6 actually addresses a lot of that. So I would posit that we can use a label to isolate tenants, use IPv6 Multicast for the cases in which IPv4 and Ethernet use broadcast, and wind up with some much simpler and more scalable. https://tools.ietf.org/html/draft-baker-openstack-ipv6-model A Model for IPv6 Operation in OpenStack, Fred Baker, Chris Marino, Ian Wells, 2014-10-17 https://tools.ietf.org/html/draft-baker-openstack-rbac-federated-identity Federated Identity for IPv6 Role-base Access Control, Fred Baker, 2014-10-17 signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron]issue about dvr flows and port timestamp
Hi, I'm not sure whether following issue is problematic, and both, our team do some effort, so I submit two blueprints: [1.] optimize dvr flows: Currently, accurate ovs flows in terms of full mac are used to communicate among distributed router, but here comes problem : (1)the more distributed router node, the more flows; (2)different distributed router across DC cannot communicate through tunnel and additional operation under same mac prefix configuration. So it would be useful to shift the complete-matching of mac to fuzzy Matching, like prefix matching, reducing the number of flows and leading to communicate among different DC though configuring same mac prefix through tunnel. Link: https://blueprints.launchpad.net/neutron/+spec/optimize-dvr-flows [2.]add port timestamp: It would be worth adding timestamp fields including create_at, update_at and delete_at in the table of port in neutron, so users can monitor port change conveniently, for example portal or management center wants to query the ports that have changed or refreshed during the latest 5sec in a large scale application. If not, it's time-consuming and low effectiveness. Link: https://blueprints.launchpad.net/neutron/+spec/add-port-timestamp Any response I will appreciate. Thanks, Xurong Yang ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] Feature Freeze Fuel Technical Preview
Hi all, first of all, it was bad idea to get FF and TechPreview at the same day. We are in rush with merging last features, so master often becomes unstable. Tech Preview still implies that there is something deployable at least to see Juno in action. As we planned to do a tech preview on this Thursday (Oct, 30), my suggestion is to focus on: - merge all remaining pieces of stats collection feature into Fuel, as we want to start receiving stats even from TechPreview - make sure TechPreview is properly versioned, so we are Ok later with 6.0 GA (build system changes) - bug fixes over upcoming 24 hours. Let's wait with other features, and extend FF to Monday, 03 of November. As we are in green in almost all the features we planned to land in, it should be fine. Thanks, -- Mike Scherbakov #mihgen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][nova] New specs on routed networking
On Tue, Oct 28, 2014 at 20:01:40, Kevin Benton wrote: I think the simplest use case is just that a provider doesn't want to deal with extending L2 domains all over their datacenter. This is the core motivation. As mentioned in Fred Baker's internet draft[0], extending layer 2 domains can be extremely challenging, and we've found it to be problematic to debug at setup time, let alone to operate. If your tenants have no need of layer 2 networks (i.e. their workload is all-IP), the datacenter network becomes much simpler in a routed model. Generally speaking, simpler is better! Cory [0]: https://tools.ietf.org/html/draft-baker-openstack-ipv6-model-00 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Finalizing cross-project design summit track
joehuang wrote: Is the cascading included in the session Approaches for scaling out [1] ? Yes it is. The goal of the session is to get the proponents of the various scaling out approaches in the same room so that they compare notes and potentially converge. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Bringing some DevOps love to Openstack
On 28/10/14 21:23 +0100, Philip Cheong wrote: Hi all, In preparation of the OpenStack Summit in Paris next week, I'm hoping to speak to some people in the OpenStack foundation about the benefits of a partnership with Hashicorp, who make fantastic tools like Vagrant and Packer (and others). As a n00b aspiring to become an OpenStack contributor, the variety of Vagrant devstack environments is pretty overwhelming. It appears to me that it really depends on what project you are contributing to, which denotes which devstack you should use. The ones I have tried take a long time (45 mins+) to provision from scratch. One aspect which I am acutely aware of is developer productivity and 45 minutes is a lot of time. Packer was designed to help alleviate bottleneck, and Vagrantcloud has inbuilt support for the versioning of Vagrant boxes. It would be a pretty straight forward exercise to use Packer to do a daily (or however often) build of a devstack box and upload it to Vagrantcloud for developers to download. With a decent internet connection that time would be significantly less than 45 minutes. I would really like to think that this community should also be able to come to a consensus over what to include in a standard devstack. That there currently seems to be many different flavours cannot help with issues of fragmentation between so many different moving parts to build an OpenStack environment. Another big issue that I hope to address with the foundation, is the integration of Hashicorp's tools with OpenStack. The various Vagrant plugins to add OpenStack as a provider is a mess. There is one specific for Rackspace who have a different Keystone API, and at least 3 others for the vanilla OpenStack: https://github.com/mitchellh/vagrant-rackspace https://github.com/ggiamarchi/vagrant-openstack-provider https://github.com/cloudbau/vagrant-openstack-plugin https://github.com/FlaPer87/vagrant-openstack I'm pretty sure mine doesn't even work any more, I don't even know ruby ;) I do see a value in having a vagrant-openstack provider but I don't think we should pick one and mark it as blessed. We're trying very hard to move away from 'blessing' projecs, at the very least depend less on it. Anyone should feel free to create the provider on stackforge and maintain it. What would be even better is to have Hashicorp itself creating and maintaining this provider. Cheers, Flavio The significance of not having an official provider, for one example, is when you use Packer to build an image in OpenStack and try to post-process it into a Vagrant box, it bombs with this error: == openstack: Running post-processor: vagrant Build 'openstack' errored: 1 error(s) occurred: * Post-processor failed: Unknown artifact type, can't build box: mitchellh.openstack Because Packer doesn't know what Vagrant expects the provider to be, as explained here. In my opinion this a pretty big issue holding back the wider acceptance of OpenStack. When I am at a customer and introduce them to tools like Vagrant and Packer and how well they work with AWS, I still avoid the conversation about OpenStack when I would really love to put them on our (Elastx's) public cloud. What say you? Could I get a +1 from those who see this as a worthwhile issue? Cheers, Phil. -- Philip Cheong Elastx | Public and Private PaaS email: philip.che...@elastx.se office: +46 8 557 728 10 mobile: +46 702 870 814 twitter: @Elastx http://elastx.se ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco pgpJKR8bOPu2l.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra][all] Synchronizing local Git and Gerrit repositories
Hi Ricardo, thanks a lot for your help and detailed instructions. It will surely come in handy when I will need to do something like that. I am looking also into this possibility. But the actual reason I need to sync our central developer repo with the Gerrit repo is a problem when the developer tries to submit code for review to Gerrit. Since the central developer repo is periodically updated from upstream and the developers pull these changes into their own local repos before branching off the feature branch, then this feature branch contains commits from upstream that Gerrit doesn't know about. So submitting this feature branch to code review will include lots of commits which are not the developers. I have now solved this issue by granting each developer the right to push the master branch to refs/heads/master in the Gerrit repo. This makes sure that the Gerrit repos master branch is updated with the latest commits and when the developer submits his feature branch for review, only his own commits will be reviewed. Regards, Ondrej /On 10/27/2014 05:11 PM, Ricardo Carrillo Cruz wrote:// / I think what you are trying to achieve is to have a branch that tracks upstream for the upstream projects, and another branch that tracks local development in your Gerrit project. You may want to check Jeepyb: http://ci.openstack.org/jeepyb.html That tool is what Openstack CI uses to manage gerrit repo creation. Let's take as an example that you wanted to have python-neutronclient project in your Gerrit, that tracks upstream. You would do something like this: 1. Install jeepyb and configure the projects.ini file according to your environment. 1. Add python-neutronclient.config file to the folder your manage-projects expect it to find (acl-dir parameter from previous step), with contents similar to : [access refs/heads/*] abandon = group neutron-core label-Code-Review = -2..+2 group neutron-core label-Workflow = -1..+1 group neutron-core [access refs/heads/proposed/*] abandon = group neutron-milestone label-Code-Review = -2..+2 group neutron-milestone label-Workflow = -1..+1 group neutron-milestone [access refs/tags/*] pushSignedTag = group neutron-release [receive] requireChangeId = true requireContributorAgreement = true [submit] mergeContent = true 2. Create an entry in gerrit/projects.yaml file from project-config repo like: - project: openstack/python-neutronclient upstream: https://git.openstack.org/openstack/python-neutronclient options: - track-upstream 3. Run 'manage-projects python-neutronclient' After this, the tool would create the project 'python-neutronclient' with the acl defined from step 1 and set it to track upstream (as per the option depicted on step 2). After this, you could just create branches off master from the Gerrit UI (or define them upfront in the acl in step 1, but this way would get you started faster). If you use the upstream openstack_project::review.pp manifest the configuration to get this going is greatly reduced (it's a mega manifest that installs gerrit, jeepyb and other things), I can help you with that. Regards ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][CI] nova-networking or neutron netwokring for CI
Thanks for the feedback. OK, got it, nova networking is not a requirement for a CI. Then I'll see not a single reason to support it. We will investigate in the neutron way for our CI and also for production. Now coming back to the Hypervisorsupportmatrix ( https://wiki.openstack.org/wiki/HypervisorSupportMatrix ). I guess the scope of this matrix is only nova and not neutron,cinder,.. isn't it? So in this matrix I have to tick the networking lines (vlan, routing,..) as NOT supported, right? (as scope is neutron-networking, altough we would support it with neutron). Thanks, Andreas -- Andreas (irc: scheuran) On Tue, 2014-10-28 at 11:06 -0700, Joe Gordon wrote: On Tue, Oct 28, 2014 at 6:44 AM, Dan Smith d...@danplanet.com wrote: Are current nova CI platforms configured with nova-networking or with neutron networking? Or is networking in general not even a part of the nova CI approach? I think we have several that only run on Neutron, so I think it's fine to just do that. Agreed, neutron should be considered required for all of the reasons listed above. --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] How to connect to a serial port of an instance via websocket?
On Tue, Oct 28, 2014 at 03:09:44PM +0100, Markus Zoeller wrote:
The API provides an endpoint for querying the serial console of an
instance ('os-getSerialConsole'). The nova-client interacts with this
API endpoint via the command `get-serial-console`.
nova get-serial-console myInstance
It returns a string like:
ws://127.0.0.1:6083/?token=e2b42240-375d-41fe-a166-367e4bbdce35
Q: How is one supposed to connect to such a websocket?
The aim of the feature is exposing an interactive web-based serial
consoles through a websocket proxy. The API returns an URL with a
valid token that should be used with a websocket client to read/write
on the stream.
Considering the service nova-serialproxy is running and well
configured you can use this simple test purpose client to connect
yourself on the URL returned by the API:
https://gist.github.com/sahid/894c31f306bebacb2207
The general idea behind this service is for example to help debugging
VMs when something was wrong with the network configuration.
s.
[1]
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/consoles.py#L111
[2]
https://ask.openstack.org/en/question/50671/how-to-connect-to-a-serial-port-of-an-instance-via-websocket/
Regards,
Markus Zoeller
IRC: markus_z
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer][Heat]Defining a webhook URL for alarm-actions
Hi, I am using all-in-one Havana on Ubuntu 12.04 LTS, working on Ceilometer and Heat. I want to launch an instance based on a threshold defined in alarm. My question is where and how am I supposed to define the webhook URL for --alarm-actions argument. I am creating threshold alarm with the following command: ceilometer -k alarm-threshold-create --name tester_cpu_high --description 'instance_too_high' --meter-name cpu_util --threshold 20.0 --comparison-operator ge --statistic avg --period 30 --evaluation-periods 1 --query resource_id=bd4ec331-dfc5-4a75-b928-6d0988dfc369 -- Regards, David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat][nova] Changing default replacement_policy for Neutron port?
On Wed, Oct 29, 2014 at 09:52:34AM +1300, Steve Baker wrote: On 29/10/14 09:28, Steve Baker wrote: snip I've looked at the tripleo templates now, and they create ports which are resources in their own right, so switching to replacement_policy:AUTO is entirely appropriate. However in most templates the vast majority of port resources are just to define a simple server/port/floating-IP combo. Therefore I think there is a good argument for the default REPLACE_ALWAYS causing the least problems for the majority of cases. Thanks for the information Steve, I've posted a patch moving the tripleo templates to AUTO, which should work around the immediate problem there. So, let me just try to clarify how we expect updates to work with the current default, lets take a simple example template: https://github.com/openstack/heat-templates/blob/master/hot/servers_in_new_neutron_net.yaml#L75 Here, we have two servers, both referencing ports, with both having a floating IP referencing the ports. Am I reading this right, it's impossible to update that template, as it's currently written, without always replacing both servers? If true, that to me is an indicator that REPLACE_ALWAYS is not a sane default. Can you clarify how updates are expected to work when you have the simple server/port/floating-IP combo, other than perhaps hiding the combo in a nested stack so we don't try to update it? It seems like we should be able to do the following (on a template containing a simple server/port/floating-IP combo): 1. Update the stack without changing the template. This shouldn't change anything. 2. Add another resource (e.g maybe another server/port/floating-IP) without destroying the first. If we can't support both of those by default, updates are terminally broken for nearly all users IMO - but are we saying the rich network properties will solve that? Thanks for any further insight you can provide :) Cheers, Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV] Patches tagging with NFVImpact
Am I the only one wondering whether introducing arbitrary tagging into our commit messages sets a bad precedent? Or was there a discussion on this topic that I missed? Maru On Jun 17, 2014, at 2:27 PM, Sylvain Bauza sba...@redhat.com wrote: Hi, There is an action for creating a Gerrit dashboard to show all NFV-related specs and patches. As it requires to have a specific label for discriminating them, I'm adding NFVImpact in all the patches proposed in [1]. The side effect is that it creates another patchset and so runs another Jenkins check so don't worry about it. I'll do a team status by tomorrow but meanwhile, please make sure that if you upload a new patch to Gerrit, it will be marked as NFVImpact in the commit message. Many thanks, -Sylvain [1] https://wiki.openstack.org/wiki/Teams/NFV#Active_Blueprints ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron]issue about dvr flows and port timestamp
On Oct 29, 2014, at 8:12 AM, Yangxurong yangxur...@huawei.com wrote: Hi, I’m not sure whether following issue is problematic, and both, our team do some effort, so I submit two blueprints: [1.] optimize dvr flows: Currently, accurate ovs flows in terms of full mac are used to communicate among distributed router, but here comes problem : (1)the more distributed router node, the more flows; (2)different distributed router across DC cannot communicate through tunnel and additional operation under same mac prefix configuration. So it would be useful to shift the complete-matching of mac to fuzzy Matching, like prefix matching, reducing the number of flows and leading to communicate among different DC though configuring same mac prefix through tunnel. Link: https://blueprints.launchpad.net/neutron/+spec/optimize-dvr-flows I think we need to focus on paying down technical debt (both in the code and on the testing side) related to dvr before we seriously consider the kind of optimization that you are proposing. I’m also unclear as to why we would want to pursue a solution to a problem whose severity doesn’t appear to be clear (I’m not sure whether the following issue is problematic…). Maru [2.]add port timestamp: It would be worth adding timestamp fields including create_at, update_at and delete_at in the table of port in neutron, so users can monitor port change conveniently, for example portal or management center wants to query the ports that have changed or refreshed during the latest 5sec in a large scale application. If not, it's time-consuming and low effectiveness. Link: https://blueprints.launchpad.net/neutron/+spec/add-port-timestamp Any response I will appreciate. Thanks, Xurong Yang ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer][Heat]Defining a webhook URL for alarm-actions
On Wed, Oct 29, 2014 at 03:19:49PM +0500, david jhon wrote: Hi, I am using all-in-one Havana on Ubuntu 12.04 LTS, working on Ceilometer and Heat. I want to launch an instance based on a threshold defined in alarm. My question is where and how am I supposed to define the webhook URL for --alarm-actions argument. I am creating threshold alarm with the following command: ceilometer -k alarm-threshold-create --name tester_cpu_high --description 'instance_too_high' --meter-name cpu_util --threshold 20.0 --comparison-operator ge --statistic avg --period 30 --evaluation-periods 1 --query resource_id=bd4ec331-dfc5-4a75-b928-6d0988dfc369 Hi, you may want to use the general mailing list for future usage questions like this, as it's not really related to development: https://wiki.openstack.org/wiki/Mailing_Lists#General_List The answer to your question is you must create the alarm inside your heat template, and reference a resource which provides a pre-signed URL, such as a ScalingPolicy resource. Here's an example template: https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml#L121 If you really want to create the alarm via the ceilometer CLI for testing, you'll need to expose the URL of the ScalingPolicy via a stack output, like this: https://github.com/openstack/heat-templates/blob/master/hot/asg_of_servers.yaml#L78 And get the output URL via heat stack-show stack name Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV] Patches tagging with NFVImpact
Yeh, this seems incredibly poluting, don't do this. That's not something I want in our long term git history without conversation about the policy. Every other Impact flag that we use in OpenStack had a pretty long conversation about it's addition. The issue arrises because the NFV team has created *so* many blueprints that they believe are critical to them that it creates a query string too long for browsers to handle. Which I think is it's own issue. I'm liable to start -1ing for commit message pollution if I see this tag. Especially as a bunch of the NFV related features that got jammed through on feature freeze without sufficient testing are currently now breaking (as one would expect without sufficient testing). So I feel this project management dashboard / drum beat is not serving anyone well. Not OpenStack, not the NFV team, not anyone. -Sean On 10/29/2014 06:25 AM, Maru Newby wrote: Am I the only one wondering whether introducing arbitrary tagging into our commit messages sets a bad precedent? Or was there a discussion on this topic that I missed? Maru On Jun 17, 2014, at 2:27 PM, Sylvain Bauza sba...@redhat.com wrote: Hi, There is an action for creating a Gerrit dashboard to show all NFV-related specs and patches. As it requires to have a specific label for discriminating them, I'm adding NFVImpact in all the patches proposed in [1]. The side effect is that it creates another patchset and so runs another Jenkins check so don't worry about it. I'll do a team status by tomorrow but meanwhile, please make sure that if you upload a new patch to Gerrit, it will be marked as NFVImpact in the commit message. Many thanks, -Sylvain [1] https://wiki.openstack.org/wiki/Teams/NFV#Active_Blueprints ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [bashate] towards inbox zero on bashate changes, release?
On 10/28/2014 10:03 PM, Ian Wienand wrote: On 10/14/2014 04:03 PM, Ian Wienand wrote: Maybe it is time for a release? One thing; does the pre-release check run over TOT devstack and ensure there are no errors? We don't want to release and then 10 minutes later gate jobs start failing. Just to loop back on this ... Our main goal here should be to get [1] merged so we don't further regress on any checks. TOT bashate currently passes against devstack; so we can release as is. Two extra changes we might consider as useful in a release: - https://review.openstack.org/131611 (Remove automagic file finder) I think we've agreed to just let test-frameworks find their own files, so get rid of this - https://review.openstack.org/131616 (Add man page) Doesn't say much, but it can't hurt As future work, we can do things like add warning-level checks, automatically generate the documentation on errors being checked, etc. -i [1] https://review.openstack.org/128809 (Fix up file-matching in bashate tox test) Looks great, I approved the 2 bashate checks. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][nova] New specs on routed networking
I have also started to capture some of our discussions here. https://etherpad.openstack.org/p/RoutedNetworking Thanks Rohit On 10/29/14 1:32 AM, Cory Benfield cory.benfi...@metaswitch.com wrote: On Tue, Oct 28, 2014 at 20:01:40, Kevin Benton wrote: I think the simplest use case is just that a provider doesn't want to deal with extending L2 domains all over their datacenter. This is the core motivation. As mentioned in Fred Baker's internet draft[0], extending layer 2 domains can be extremely challenging, and we've found it to be problematic to debug at setup time, let alone to operate. If your tenants have no need of layer 2 networks (i.e. their workload is all-IP), the datacenter network becomes much simpler in a routed model. Generally speaking, simpler is better! Cory [0]: https://tools.ietf.org/html/draft-baker-openstack-ipv6-model-00 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Finalizing cross-project design summit track
On 10/28/2014 05:22 PM, Russell Bryant wrote: A draft schedule has been posted for the cross-project design summit track: http://kilodesignsummit.sched.org/overview/type/cross-project+workshops#.VFAFFXVGjUa If you have any schedule changes to propose for really bad conflicts, please let me know. We really tried to minimize conflicts, but it's impossible to resolve them all. The next steps are to identify session leads and get the leads to write session descriptions to put on the schedule. We're collecting both at the top of the proposals etherpad: https://etherpad.openstack.org/p/kilo-crossproject-summit-topics If you were the proposer of one of these sessions and are not already listed as the session lead, please add yourself. If you'd like to volunteer to lead a session that doesn't have a lead, please speak up. For the sessions you are leading, please draft a description on the etherpad that can be used for the session on sched.org. Thank you! I was trying to track down the origin of the Debugging Gate Failures submission - http://kilodesignsummit.sched.org/event/5cfc92906adc5830355ddcedbb95d977 (through matching hex author colors in etherpad... fun!) It looks like John G copied it over because someone (lost to the mists of time) put it in the Nova ideas etherpad. I'd actually argue that a 40 minute interactive session without much prep isn't going to be all that useful (and honestly probably a terrible experience for all parties involved). This is a topic that Jay, Dan, and I have discussed for doing an upcoming bootstrapping hour on (which also means it would have a long term archived version), and I think that's probably a better way to do a thing like this. As there is no owner for this, there is no one to pull it out of the agenda. But I think it's something that should be considered. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] BGP - VPN BoF session in Kilo design summit
Hello, it seems like the BGP dynamic routing it is in a good shape to be included in Neutron during Kilo[1]. There is quite interest in offer BGP-VPN too. Mathieu Rohon's spec[2] goes in this direction. Of course it makes sense that his development leverages the BGP one. I would like to have a BoF session and invite anyone interested on these blueprints to join us or even add a new related one. I've created an etherpad[3] to share ideas and agree with session schedule. I propose Wednesday afternoon. If Carl Baldwin is agree, we can talk about it also during the open discussion of today's L3 subteam meeting. [1]: https://review.openstack.org/#/c/125401/ [ 2]: https://review.openstack.org/#/c/125401/ [3]: https://etherpad.openstack.org/p/bgp-vpn-dynamic-routing Cheers, -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV] Patches tagging with NFVImpact
- Original Message - From: Maru Newby ma...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Am I the only one wondering whether introducing arbitrary tagging into our commit messages sets a bad precedent? Or was there a discussion on this topic that I missed? Maru Any particular reason for digging this up from June? We already changed the process so that we did not need to do this. Thanks, Steve On Jun 17, 2014, at 2:27 PM, Sylvain Bauza sba...@redhat.com wrote: Hi, There is an action for creating a Gerrit dashboard to show all NFV-related specs and patches. As it requires to have a specific label for discriminating them, I'm adding NFVImpact in all the patches proposed in [1]. The side effect is that it creates another patchset and so runs another Jenkins check so don't worry about it. I'll do a team status by tomorrow but meanwhile, please make sure that if you upload a new patch to Gerrit, it will be marked as NFVImpact in the commit message. Many thanks, -Sylvain [1] https://wiki.openstack.org/wiki/Teams/NFV#Active_Blueprints ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV] Patches tagging with NFVImpact
On 10/29/2014 07:25 AM, Steve Gordon wrote: - Original Message - From: Maru Newby ma...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Am I the only one wondering whether introducing arbitrary tagging into our commit messages sets a bad precedent? Or was there a discussion on this topic that I missed? Maru Any particular reason for digging this up from June? We already changed the process so that we did not need to do this. Thanks, Steve Steve, et all, sorry for piling on. I didn't read dates earlier than Maru's post. Glad there is a different solution here. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV] Patches tagging with NFVImpact
On Oct 29, 2014, at 12:25 PM, Steve Gordon sgor...@redhat.com wrote: - Original Message - From: Maru Newby ma...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Am I the only one wondering whether introducing arbitrary tagging into our commit messages sets a bad precedent? Or was there a discussion on this topic that I missed? Maru Any particular reason for digging this up from June? We already changed the process so that we did not need to do this. Thanks, Steve I had a mail filter applied when I looked at the list this morning and I failed to notice that this was an old thread until I had already sent my reply. That said, we have Neutron specs up for review that still include this tag in the commit message and now I know at least that I can ask for their removal. Maru On Jun 17, 2014, at 2:27 PM, Sylvain Bauza sba...@redhat.com wrote: Hi, There is an action for creating a Gerrit dashboard to show all NFV-related specs and patches. As it requires to have a specific label for discriminating them, I'm adding NFVImpact in all the patches proposed in [1]. The side effect is that it creates another patchset and so runs another Jenkins check so don't worry about it. I'll do a team status by tomorrow but meanwhile, please make sure that if you upload a new patch to Gerrit, it will be marked as NFVImpact in the commit message. Many thanks, -Sylvain [1] https://wiki.openstack.org/wiki/Teams/NFV#Active_Blueprints ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV] Patches tagging with NFVImpact
- Original Message - From: Sean Dague s...@dague.net To: openstack-dev@lists.openstack.org On 10/29/2014 07:25 AM, Steve Gordon wrote: - Original Message - From: Maru Newby ma...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Am I the only one wondering whether introducing arbitrary tagging into our commit messages sets a bad precedent? Or was there a discussion on this topic that I missed? Maru Any particular reason for digging this up from June? We already changed the process so that we did not need to do this. Thanks, Steve Steve, et all, sorry for piling on. I didn't read dates earlier than Maru's post. Glad there is a different solution here. -Sean We pretty quickly came to basically the same conclusion as you and Maru are suggesting [1], that doing this was too invasive and created unnecessary noise. Thanks, Steve [1] http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-06-18-14.03.log.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV] Patches tagging with NFVImpact
- Original Message - From: Maru Newby ma...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org On Oct 29, 2014, at 12:25 PM, Steve Gordon sgor...@redhat.com wrote: - Original Message - From: Maru Newby ma...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Am I the only one wondering whether introducing arbitrary tagging into our commit messages sets a bad precedent? Or was there a discussion on this topic that I missed? Maru Any particular reason for digging this up from June? We already changed the process so that we did not need to do this. Thanks, Steve I had a mail filter applied when I looked at the list this morning and I failed to notice that this was an old thread until I had already sent my reply. That said, we have Neutron specs up for review that still include this tag in the commit message and now I know at least that I can ask for their removal. Maru Yes, I was thinking after replying that some of the proposals still in flight are quite old and may still have the tag. It can and should be removed. Thanks, Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate
Hi Alex, You can continue the work https://review.openstack.org/#/c/88983/ from here ;-) 2014-10-29 13:42 GMT+08:00 Chen CH Ji jiche...@cn.ibm.com: Yes, I remember that spec might talk about local storage (in local db?) and it can be the root cause And I think we need persistent storage otherwise the scheduler hints can't survive in some conditions such as system reboot or upgrade ? Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC [image: Inactive hide details for Alex Xu ---10/29/2014 01:34:13 PM---On 2014年10月29日 12:37, Chen CH Ji wrote: ]Alex Xu ---10/29/2014 01:34:13 PM---On 2014年10月29日 12:37, Chen CH Ji wrote: From: Alex Xu x...@linux.vnet.ibm.com To: openstack-dev@lists.openstack.org Date: 10/29/2014 01:34 PM Subject: Re: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate -- On 2014年10月29日 12:37, Chen CH Ji wrote: I think we already support to specify the host when doing evacuate and migration ? Yes, we support to specify the host, but schedule-hints is different thing. if we need use hints that passed from creating instance, that means we need to persistent schedule hints I remember we used to have a spec for store it locally ... I also remember we have one spec for persistent before, but I don't know why it didn't continue. And I think maybe we needn't persistent schedule-hints, just add pass new schedule-hints when migration the instance. Nova just need provide the mechanism. Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: *jiche...@cn.ibm.com* jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC [image: Inactive hide details for Alex Xu ---10/29/2014 12:19:35 PM---Hi, Currently migration/rebuild/evacuate didn't support pass]Alex Xu ---10/29/2014 12:19:35 PM---Hi, Currently migration/rebuild/evacuate didn't support pass From: Alex Xu *x...@linux.vnet.ibm.com* x...@linux.vnet.ibm.com To: *openstack-dev@lists.openstack.org* openstack-dev@lists.openstack.org Date: 10/29/2014 12:19 PM Subject: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate -- Hi, Currently migration/rebuild/evacuate didn't support pass scheduler-hints, that means any migration can't use schedule-hints that passed when creating instance. Can we add scheduler-hints support when migration/rebuild/evacuate? That also can enable user move in/out instance to/from an server group. Thanks Alex ___ OpenStack-dev mailing list *OpenStack-dev@lists.openstack.org* OpenStack-dev@lists.openstack.org *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev* http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list *OpenStack-dev@lists.openstack.org* OpenStack-dev@lists.openstack.org *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev* http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Clear all flows when ovs agent start? why and how avoid?
I find our current design is remove all flows then add flow by entry, this will cause every network node will break off all tunnels between other network node and all compute node. Perhaps a way around this would be to add a flag on agent startup which would have it skip reprogramming flows. This could be used for the upgrade case. I hit the same issue last week and filed a bug here: https://bugs.launchpad.net/neutron/+bug/1383674 From an operators perspective this is VERY annoying since you also cannot push any config changes that requires/triggers a restart of the agent. e.g. something simple like changing a log setting becomes a hassle. I would prefer the default behaviour to be to not clear the flows or at the least an config option to disable it. Cheers, Robert van Leeuwen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Finalizing cross-project design summit track
On 10/29/2014 07:22 AM, Sean Dague wrote: On 10/28/2014 05:22 PM, Russell Bryant wrote: A draft schedule has been posted for the cross-project design summit track: http://kilodesignsummit.sched.org/overview/type/cross-project+workshops#.VFAFFXVGjUa If you have any schedule changes to propose for really bad conflicts, please let me know. We really tried to minimize conflicts, but it's impossible to resolve them all. The next steps are to identify session leads and get the leads to write session descriptions to put on the schedule. We're collecting both at the top of the proposals etherpad: https://etherpad.openstack.org/p/kilo-crossproject-summit-topics If you were the proposer of one of these sessions and are not already listed as the session lead, please add yourself. If you'd like to volunteer to lead a session that doesn't have a lead, please speak up. For the sessions you are leading, please draft a description on the etherpad that can be used for the session on sched.org. Thank you! I was trying to track down the origin of the Debugging Gate Failures submission - http://kilodesignsummit.sched.org/event/5cfc92906adc5830355ddcedbb95d977 (through matching hex author colors in etherpad... fun!) It looks like John G copied it over because someone (lost to the mists of time) put it in the Nova ideas etherpad. I'd actually argue that a 40 minute interactive session without much prep isn't going to be all that useful (and honestly probably a terrible experience for all parties involved). This is a topic that Jay, Dan, and I have discussed for doing an upcoming bootstrapping hour on (which also means it would have a long term archived version), and I think that's probably a better way to do a thing like this. As there is no owner for this, there is no one to pull it out of the agenda. But I think it's something that should be considered. I'm fine with pulling it. If so, we can give something else 2 timeslots, or pull another topic back in. Any suggestions for one that could use 2 slots? On a related note, next time around, if we use etherpads for proposals again, we should really use some common formatting for proposals, and require a session lead listed. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Clear all flows when ovs agent start? why and how avoid?
Sent from my iPad On 2014-10-29, at 下午8:01, Robert van Leeuwen robert.vanleeu...@spilgames.com wrote: I find our current design is remove all flows then add flow by entry, this will cause every network node will break off all tunnels between other network node and all compute node. Perhaps a way around this would be to add a flag on agent startup which would have it skip reprogramming flows. This could be used for the upgrade case. I hit the same issue last week and filed a bug here: https://bugs.launchpad.net/neutron/+bug/1383674 From an operators perspective this is VERY annoying since you also cannot push any config changes that requires/triggers a restart of the agent. e.g. something simple like changing a log setting becomes a hassle. I would prefer the default behaviour to be to not clear the flows or at the least an config option to disable it. +1, we also suffered from this even when a very little patch is done Cheers, Robert van Leeuwen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Finalizing cross-project design summit track
On 10/29/2014 08:20 AM, Russell Bryant wrote: On 10/29/2014 07:22 AM, Sean Dague wrote: On 10/28/2014 05:22 PM, Russell Bryant wrote: A draft schedule has been posted for the cross-project design summit track: http://kilodesignsummit.sched.org/overview/type/cross-project+workshops#.VFAFFXVGjUa If you have any schedule changes to propose for really bad conflicts, please let me know. We really tried to minimize conflicts, but it's impossible to resolve them all. The next steps are to identify session leads and get the leads to write session descriptions to put on the schedule. We're collecting both at the top of the proposals etherpad: https://etherpad.openstack.org/p/kilo-crossproject-summit-topics If you were the proposer of one of these sessions and are not already listed as the session lead, please add yourself. If you'd like to volunteer to lead a session that doesn't have a lead, please speak up. For the sessions you are leading, please draft a description on the etherpad that can be used for the session on sched.org. Thank you! I was trying to track down the origin of the Debugging Gate Failures submission - http://kilodesignsummit.sched.org/event/5cfc92906adc5830355ddcedbb95d977 (through matching hex author colors in etherpad... fun!) It looks like John G copied it over because someone (lost to the mists of time) put it in the Nova ideas etherpad. I'd actually argue that a 40 minute interactive session without much prep isn't going to be all that useful (and honestly probably a terrible experience for all parties involved). This is a topic that Jay, Dan, and I have discussed for doing an upcoming bootstrapping hour on (which also means it would have a long term archived version), and I think that's probably a better way to do a thing like this. As there is no owner for this, there is no one to pull it out of the agenda. But I think it's something that should be considered. I'm fine with pulling it. If so, we can give something else 2 timeslots, or pull another topic back in. Any suggestions for one that could use 2 slots? On a related note, next time around, if we use etherpads for proposals again, we should really use some common formatting for proposals, and require a session lead listed. Agreed. I think proposals without a session lead specified should be nixed. Otherwise we play this giant game of telephone tag. :) -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron]issue about dvr flows and port timestamp
Sent from my iPad On 2014-10-29, at 下午6:33, Maru Newby ma...@redhat.com wrote: On Oct 29, 2014, at 8:12 AM, Yangxurong yangxur...@huawei.com wrote: Hi, I’m not sure whether following issue is problematic, and both, our team do some effort, so I submit two blueprints: [1.] optimize dvr flows: Currently, accurate ovs flows in terms of full mac are used to communicate among distributed router, but here comes problem : (1)the more distributed router node, the more flows; (2)different distributed router across DC cannot communicate through tunnel and additional operation under same mac prefix configuration. So it would be useful to shift the complete-matching of mac to fuzzy Matching, like prefix matching, reducing the number of flows and leading to communicate among different DC though configuring same mac prefix through tunnel. Link: https://blueprints.launchpad.net/neutron/+spec/optimize-dvr-flows I think we need to focus on paying down technical debt (both in the code and on the testing side) related to dvr before we seriously consider the kind of optimization that you are proposing. I’m also unclear as to why we would want to pursue a solution to a problem whose severity doesn’t appear to be clear (I’m not sure whether the following issue is problematic…). DVR stability is the first class for sure, but if the code and logic could be less and simpler, there is more chance of stability. By my understanding, since DVR mac range has been configured as a prefix, so prefix based judgement instead of one by one flow setup triggered by mesh-like message notifying would simplify the code logic, thus indirectly contribute to overall stability. Also, it would remove hundreds of flows in the ovs in a middle scale cluster, very helpful for trouble shooting. Wu Maru [2.]add port timestamp: It would be worth adding timestamp fields including create_at, update_at and delete_at in the table of port in neutron, so users can monitor port change conveniently, for example portal or management center wants to query the ports that have changed or refreshed during the latest 5sec in a large scale application. If not, it's time-consuming and low effectiveness. Link: https://blueprints.launchpad.net/neutron/+spec/add-port-timestamp Any response I will appreciate. Thanks, Xurong Yang ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate
Hah, thanks :), Let me see if I can help on that. 2014-10-29 19:59 GMT+08:00 Jay Lau jay.lau@gmail.com: Hi Alex, You can continue the work https://review.openstack.org/#/c/88983/ from here ;-) 2014-10-29 13:42 GMT+08:00 Chen CH Ji jiche...@cn.ibm.com: Yes, I remember that spec might talk about local storage (in local db?) and it can be the root cause And I think we need persistent storage otherwise the scheduler hints can't survive in some conditions such as system reboot or upgrade ? Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC [image: Inactive hide details for Alex Xu ---10/29/2014 01:34:13 PM---On 2014年10月29日 12:37, Chen CH Ji wrote: ]Alex Xu ---10/29/2014 01:34:13 PM---On 2014年10月29日 12:37, Chen CH Ji wrote: From: Alex Xu x...@linux.vnet.ibm.com To: openstack-dev@lists.openstack.org Date: 10/29/2014 01:34 PM Subject: Re: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate -- On 2014年10月29日 12:37, Chen CH Ji wrote: I think we already support to specify the host when doing evacuate and migration ? Yes, we support to specify the host, but schedule-hints is different thing. if we need use hints that passed from creating instance, that means we need to persistent schedule hints I remember we used to have a spec for store it locally ... I also remember we have one spec for persistent before, but I don't know why it didn't continue. And I think maybe we needn't persistent schedule-hints, just add pass new schedule-hints when migration the instance. Nova just need provide the mechanism. Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: *jiche...@cn.ibm.com* jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC [image: Inactive hide details for Alex Xu ---10/29/2014 12:19:35 PM---Hi, Currently migration/rebuild/evacuate didn't support pass]Alex Xu ---10/29/2014 12:19:35 PM---Hi, Currently migration/rebuild/evacuate didn't support pass From: Alex Xu *x...@linux.vnet.ibm.com* x...@linux.vnet.ibm.com To: *openstack-dev@lists.openstack.org* openstack-dev@lists.openstack.org Date: 10/29/2014 12:19 PM Subject: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate -- Hi, Currently migration/rebuild/evacuate didn't support pass scheduler-hints, that means any migration can't use schedule-hints that passed when creating instance. Can we add scheduler-hints support when migration/rebuild/evacuate? That also can enable user move in/out instance to/from an server group. Thanks Alex ___ OpenStack-dev mailing list *OpenStack-dev@lists.openstack.org* OpenStack-dev@lists.openstack.org *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev* http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list *OpenStack-dev@lists.openstack.org* OpenStack-dev@lists.openstack.org *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev* http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate
2014-10-29 13:42 GMT+08:00 Chen CH Ji jiche...@cn.ibm.com: Yes, I remember that spec might talk about local storage (in local db?) and it can be the root cause And I think we need persistent storage otherwise the scheduler hints can't survive in some conditions such as system reboot or upgrade ? Yeah, that's problem. And I have talk with Jay Lau, look like there already got agreement on persistent it. Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC [image: Inactive hide details for Alex Xu ---10/29/2014 01:34:13 PM---On 2014年10月29日 12:37, Chen CH Ji wrote: ]Alex Xu ---10/29/2014 01:34:13 PM---On 2014年10月29日 12:37, Chen CH Ji wrote: From: Alex Xu x...@linux.vnet.ibm.com To: openstack-dev@lists.openstack.org Date: 10/29/2014 01:34 PM Subject: Re: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate -- On 2014年10月29日 12:37, Chen CH Ji wrote: I think we already support to specify the host when doing evacuate and migration ? Yes, we support to specify the host, but schedule-hints is different thing. if we need use hints that passed from creating instance, that means we need to persistent schedule hints I remember we used to have a spec for store it locally ... I also remember we have one spec for persistent before, but I don't know why it didn't continue. And I think maybe we needn't persistent schedule-hints, just add pass new schedule-hints when migration the instance. Nova just need provide the mechanism. Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: *jiche...@cn.ibm.com* jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC [image: Inactive hide details for Alex Xu ---10/29/2014 12:19:35 PM---Hi, Currently migration/rebuild/evacuate didn't support pass]Alex Xu ---10/29/2014 12:19:35 PM---Hi, Currently migration/rebuild/evacuate didn't support pass From: Alex Xu *x...@linux.vnet.ibm.com* x...@linux.vnet.ibm.com To: *openstack-dev@lists.openstack.org* openstack-dev@lists.openstack.org Date: 10/29/2014 12:19 PM Subject: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate -- Hi, Currently migration/rebuild/evacuate didn't support pass scheduler-hints, that means any migration can't use schedule-hints that passed when creating instance. Can we add scheduler-hints support when migration/rebuild/evacuate? That also can enable user move in/out instance to/from an server group. Thanks Alex ___ OpenStack-dev mailing list *OpenStack-dev@lists.openstack.org* OpenStack-dev@lists.openstack.org *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev* http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list *OpenStack-dev@lists.openstack.org* OpenStack-dev@lists.openstack.org *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev* http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra][all] Synchronizing local Git and Gerrit repositories
On Wed, Oct 29, 2014 at 4:20 AM, Ondrej Wisniewski ondrej.wisniew...@dektech.com.au wrote: Hi Ricardo, thanks a lot for your help and detailed instructions. It will surely come in handy when I will need to do something like that. I am looking also into this possibility. But the actual reason I need to sync our central developer repo with the Gerrit repo is a problem when the developer tries to submit code for review to Gerrit. Since the central developer repo is periodically updated from upstream and the developers pull these changes into their own local repos before branching off the feature branch, then this feature branch contains commits from upstream that Gerrit doesn't know about. So submitting this feature branch to code review will include lots of commits which are not the developers. I have now solved this issue by granting each developer the right to push the master branch to refs/heads/master in the Gerrit repo. This makes sure that the Gerrit repos master branch is updated with the latest commits and when the developer submits his feature branch for review, only his own commits will be reviewed. I've been following the conversation, probably like many others, wondering why in the world you need such a complicated, high-maintenance workflow? What's the use case? Why can't your developers use review.openstack.org? In your first email, you used the phrase trying to set up an OpenStack development workflow in our company but what you're building is not an OpenStack development workflow at all - it's an expensive private island. The community's workflow is quite well documented here: https://wiki.openstack.org/wiki/Gerrit_Workflow Regards, Ondrej *On 10/27/2014 05:11 PM, Ricardo Carrillo Cruz wrote:* I think what you are trying to achieve is to have a branch that tracks upstream for the upstream projects, and another branch that tracks local development in your Gerrit project. You may want to check Jeepyb: http://ci.openstack.org/jeepyb.html That tool is what Openstack CI uses to manage gerrit repo creation. Let's take as an example that you wanted to have python-neutronclient project in your Gerrit, that tracks upstream. You would do something like this: 1. Install jeepyb and configure the projects.ini file according to your environment. 1. Add python-neutronclient.config file to the folder your manage-projects expect it to find (acl-dir parameter from previous step), with contents similar to : [access refs/heads/*] abandon = group neutron-core label-Code-Review = -2..+2 group neutron-core label-Workflow = -1..+1 group neutron-core [access refs/heads/proposed/*] abandon = group neutron-milestone label-Code-Review = -2..+2 group neutron-milestone label-Workflow = -1..+1 group neutron-milestone [access refs/tags/*] pushSignedTag = group neutron-release [receive] requireChangeId = true requireContributorAgreement = true [submit] mergeContent = true 2. Create an entry in gerrit/projects.yaml file from project-config repo like: - project: openstack/python-neutronclient upstream: https://git.openstack.org/openstack/python-neutronclient options: - track-upstream 3. Run 'manage-projects python-neutronclient' After this, the tool would create the project 'python-neutronclient' with the acl defined from step 1 and set it to track upstream (as per the option depicted on step 2). After this, you could just create branches off master from the Gerrit UI (or define them upfront in the acl in step 1, but this way would get you started faster). If you use the upstream openstack_project::review.pp manifest the configuration to get this going is greatly reduced (it's a mega manifest that installs gerrit, jeepyb and other things), I can help you with that. Regards ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] Enable LVM ephemeral storage for Nova
On 10/28/2014 02:50 PM, John Griffith wrote: On Tue, Oct 28, 2014 at 12:37 PM, Dan Genin daniel.ge...@jhuapl.edu mailto:daniel.ge...@jhuapl.edu wrote: Great, thank you, Duncan. I will then proceed with the shared volume group. Dan On 10/28/2014 02:06 PM, Duncan Thomas wrote: Cinder volumes are always (unless you go change the default) in the form: volume-uuid, and since the string 'volume-' is never a valid uuid, then I think we can work around nova volumes fine when we come to write our tests. Sorry for the repeated circling on this, but I think I'm now happy. Thanks On 28 October 2014 17:53, Dan Genin daniel.ge...@jhuapl.edu mailto:daniel.ge...@jhuapl.edu wrote: On 10/28/2014 11:56 AM, Dean Troyer wrote: On Tue, Oct 28, 2014 at 9:27 AM, Dan Genin daniel.ge...@jhuapl.edu mailto:daniel.ge...@jhuapl.edu wrote: So this brings us back to the original proposal of having separate backing files for Cinder and Nova which Dean thought might take too much space. Between Cinder, Nova and Swift (and Ceph, etc) everybody wants some loopback disk images. DevStack's Swift and Ceph configurations assume loopback devices and do no sharing. Duncan, could you please elaborate on the pain a single volume group is likely to cause for Cinder? Is it a show stopper? Back in the day, DevStack was built to configure Cinder (and Nova Volume before that) to use a specific existing volume group (VOLUME_GROUP_NAME) or create a loopback file if necessary. With the help of VOLUME_NAME_PREFIX and volume_name_template DevStack knew which logical volumes belong to Cinder and could Do The Right Thing. With three loopback files being created, all wanting larger and larger defaults, adding a fourth becomes Just One More Thing. If Nova's use of LVM is similar enough to Cinder's (uses deterministic naming for the LVs) I'm betting we could make it work. dt Nova's disk names are of the form instance-uuid_disk_type. So deterministic but, unfortunately, not necessarily predictable. It sounds like Duncan is saying that Cinder needs a fixed prefix for testing its functionality. I will be honest, I am not optimistic about convincing Nova to change their disk naming scheme for the sake of LVM testing. Far more important changes have lingered for months and sometimes longer. It sounds like you are concerned about two issues with regard to the separate volume groups approach: 1) potential loop device shortage and 2) growing space demand. The second issue, it seems to me, will arise no matter which of the two solutions we choose. More space will be required for testing Nova's LVM functionality one way or another, although, using a shared volume group would permit a more efficient use of the available space. The first issue is, indeed, a direct consequence of the choice to use distinct volume groups. However, the number of available loop devices can be increased by passing the appropriate boot parameter to the kernel, which can be easy or hard depending on how the test VMs are spun up. I am not saying that we should necessarily go the way of separate volume groups but, assuming for the moment that changing Nova's disk naming scheme is not an option, we need to figure out what will bring the least amount of pain forcing Cinder tests to work around Nova volumes or create separate volume groups. Let me know what you think. Dan -- Dean Troyer dtro...@gmail.com mailto:dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org
[openstack-dev] Kilo Design Summit schedule
Hi everyone, Less than one week from the Kilo design summit start, the schedule is almost final. You can start planning your week and access it at: http://kilodesignsummit.sched.org/ It should also be mirrored to the mobile Guidebook app. In doubt, sched is always more current. We still expect a number of changes (TripleO session schedule is still tbd, we might drop the gate debugging cross-project workshop...). If anyone pushes a change to the live schedule at this point, it would be nice to post a corresponding public service announcement to this thread to give everyone a heads-up. We also started collecting links to discussion etherpads at: https://wiki.openstack.org/wiki/Summit/Kilo/Etherpads Please add yours there. See you in Paris ! -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Finalizing cross-project design summit track
On 10/29/2014 07:22 AM, Sean Dague wrote: On 10/28/2014 05:22 PM, Russell Bryant wrote: A draft schedule has been posted for the cross-project design summit track: http://kilodesignsummit.sched.org/overview/type/cross-project+workshops#.VFAFFXVGjUa If you have any schedule changes to propose for really bad conflicts, please let me know. We really tried to minimize conflicts, but it's impossible to resolve them all. The next steps are to identify session leads and get the leads to write session descriptions to put on the schedule. We're collecting both at the top of the proposals etherpad: https://etherpad.openstack.org/p/kilo-crossproject-summit-topics If you were the proposer of one of these sessions and are not already listed as the session lead, please add yourself. If you'd like to volunteer to lead a session that doesn't have a lead, please speak up. For the sessions you are leading, please draft a description on the etherpad that can be used for the session on sched.org. Thank you! I was trying to track down the origin of the Debugging Gate Failures submission - http://kilodesignsummit.sched.org/event/5cfc92906adc5830355ddcedbb95d977 (through matching hex author colors in etherpad... fun!) It looks like John G copied it over because someone (lost to the mists of time) put it in the Nova ideas etherpad. I'd actually argue that a 40 minute interactive session without much prep isn't going to be all that useful (and honestly probably a terrible experience for all parties involved). This is a topic that Jay, Dan, and I have discussed for doing an upcoming bootstrapping hour on (which also means it would have a long term archived version), and I think that's probably a better way to do a thing like this. As there is no owner for this, there is no one to pull it out of the agenda. But I think it's something that should be considered. Actually, it was me who added that to the cross-project session proposal etherpad :) But, that said, I agree with you that the format of the cross-project sessions are not ideal for this topic and it would be better as an archived OBH session. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra][all] Synchronizing local Git and Gerrit repositories
Hi Dolph, I guess it sounds complicated but in the end our setup is really not much different from the community workflow, a least this is the intention. What I am trying to achieve is a possibility for the team of developers to share code among each other by using a central Git repository. This is according to the centralized workflow using distributed Git as described in the official Git documentation (see ref. [1]). If I understand correctly, we cannot use the OpenStack community Git servers as our central Git repository since developers cannot push to them. And we don't want to go through Gerrit and the code review procedure just to share a bit of code with somebody else in the team. Thus the need for a local mirror. Additionally also a local Gerrit server was set up to allow for internal code review within the team before submitting anything to the community server review.openstack.org http://review.openstack.org (which will be done eventually). This is also helpful in case our Internet connection goes down, as we will still be able to follow the complete workflow inside the LAN. Hope this explains a little better the motivation for the described setup. Ondrej [1] http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows /On 10/29/2014 02:14 PM, Dolph Mathews wrote:// / I've been following the conversation, probably like many others, wondering why in the world you need such a complicated, high-maintenance workflow? What's the use case? Why can't your developers use review.openstack.org http://review.openstack.org? In your first email, you used the phrase trying to set up an OpenStack development workflow in our company but what you're building is not an OpenStack development workflow at all - it's an expensive private island. The community's workflow is quite well documented here: https://wiki.openstack.org/wiki/Gerrit_Workflow ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tuskar] Puppet module
Nope, there isn't a puppet module for deploying Tuskar, but starting one makes sense. On 10/28/2014 06:04 PM, Emilien Macchi wrote: Hi, I was looking at deploying Tuskar API with Puppet and I was wondering if you guys have already worked on a Puppet module. If not, I think we could start something in stackforge like we already did for other OpenStack components. Thanks, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] ipv6 and ipv4 dual stack for floating IP
Hi
I want to use both ipv4 and ipv6 for floating ip at the same time. However,
I have the following issue when setting router gateway or associate
floating ip to an instance.
Is it supported in the first place? What should I do to make it work?
Thanks!
neutron router-list
+--++---+-+---+
| id | name |
external_gateway_info
| distributed | ha|
+--++---+-+---+
| b243c786-4648-4d69-b749-ee5fad02069b | default-router | {network_id:
02eca54a-420d-4d52-b045-1207e17994e5, enable_snat: true,
external_fixed_ips: [{subnet_id:
a188333f-77c3-40d9-9048-e733c4da30b1, ip_address: 162.3.123.51},
{subnet_id: 14d9dd91-b315-43bc-818d-ab21f62c1ebb, ip_address:
2001:470:1f0f:cb4::7}]} | False | False |
+--++---+-+---+
neutron-l3-agent log:
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
2014-10-29 14:10:08.941 30286 ERROR neutron.agent.l3_agent [-] Ignoring
multiple IPs on router port 18c8874c-f9a0-4274-8f38-fab3da754c2b
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
2014-10-29 14:10:08.941 30286 ERROR neutron.agent.l3_agent [-] 'subnet'
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
2014-10-29 14:10:08.941 30286 TRACE neutron.agent.l3_agent Traceback (most
recent call last):
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
2014-10-29 14:10:08.941 30286 TRACE neutron.agent.l3_agent File
/opt/stack/venvs/openstack/local/lib/python2.7/site-packages/neutron/common/utils.py,
line 341, in call
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
2014-10-29 14:10:08.941 30286 TRACE neutron.agent.l3_agent return
func(*args, **kwargs)
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
2014-10-29 14:10:08.941 30286 TRACE neutron.agent.l3_agent File
/opt/stack/venvs/openstack/local/lib/python2.7/site-packages/neutron/agent/l3_agent.py,
line 948, in process_router
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
2014-10-29 14:10:08.941 30286 TRACE neutron.agent.l3_agent
self._set_subnet_info(ex_gw_port)
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
2014-10-29 14:10:08.941 30286 TRACE neutron.agent.l3_agent File
/opt/stack/venvs/openstack/local/lib/python2.7/site-packages/neutron/agent/l3_agent.py,
line 864, in _set_subnet_info
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
2014-10-29 14:10:08.941 30286 TRACE neutron.agent.l3_agent prefixlen =
netaddr.IPNetwork(port['subnet']['cidr']).prefixlen
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
2014-10-29 14:10:08.941 30286 TRACE neutron.agent.l3_agent KeyError:
'subnet'
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
2014-10-29 14:10:08.941 30286 TRACE neutron.agent.l3_agent
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
Traceback (most recent call last):
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: File
/opt/stack/venvs/openstack/local/lib/python2.7/site-packages/eventlet/greenpool.py,
line 82, in _spawn_n_impl
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
func(*args, **kwargs)
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: File
/opt/stack/venvs/openstack/local/lib/python2.7/site-packages/neutron/agent/l3_agent.py,
line 1837, in _process_router_update
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
self._process_router_if_compatible(router)
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: File
/opt/stack/venvs/openstack/local/lib/python2.7/site-packages/neutron/agent/l3_agent.py,
line 1812, in _process_router_if_compatible
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
self.process_router(ri)
Oct 29 14:10:08 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: File
Re: [openstack-dev] [all] Bringing some DevOps love to Openstack
Yes, the aim is to get a vagrant-openstack provider plugin under Hashicorp's or Mitchellh's github account. Whether you call that official or blessed, doesn't really matter. In order for Vagrant to integrate with other tools such as Packer there needs to be a preferred plugin. Hopefully the owners of the other plugins will agree to deprecate theirs so that an end can be put to the fragmentation that has happened so far and direct contributors to the correct place. On 29 October 2014 10:04, Flavio Percoco fla...@redhat.com wrote: On 28/10/14 21:23 +0100, Philip Cheong wrote: Hi all, In preparation of the OpenStack Summit in Paris next week, I'm hoping to speak to some people in the OpenStack foundation about the benefits of a partnership with Hashicorp, who make fantastic tools like Vagrant and Packer (and others). As a n00b aspiring to become an OpenStack contributor, the variety of Vagrant devstack environments is pretty overwhelming. It appears to me that it really depends on what project you are contributing to, which denotes which devstack you should use. The ones I have tried take a long time (45 mins+) to provision from scratch. One aspect which I am acutely aware of is developer productivity and 45 minutes is a lot of time. Packer was designed to help alleviate bottleneck, and Vagrantcloud has inbuilt support for the versioning of Vagrant boxes. It would be a pretty straight forward exercise to use Packer to do a daily (or however often) build of a devstack box and upload it to Vagrantcloud for developers to download. With a decent internet connection that time would be significantly less than 45 minutes. I would really like to think that this community should also be able to come to a consensus over what to include in a standard devstack. That there currently seems to be many different flavours cannot help with issues of fragmentation between so many different moving parts to build an OpenStack environment. Another big issue that I hope to address with the foundation, is the integration of Hashicorp's tools with OpenStack. The various Vagrant plugins to add OpenStack as a provider is a mess. There is one specific for Rackspace who have a different Keystone API, and at least 3 others for the vanilla OpenStack: https://github.com/mitchellh/vagrant-rackspace https://github.com/ggiamarchi/vagrant-openstack-provider https://github.com/cloudbau/vagrant-openstack-plugin https://github.com/FlaPer87/vagrant-openstack I'm pretty sure mine doesn't even work any more, I don't even know ruby ;) I do see a value in having a vagrant-openstack provider but I don't think we should pick one and mark it as blessed. We're trying very hard to move away from 'blessing' projecs, at the very least depend less on it. Anyone should feel free to create the provider on stackforge and maintain it. What would be even better is to have Hashicorp itself creating and maintaining this provider. Cheers, Flavio The significance of not having an official provider, for one example, is when you use Packer to build an image in OpenStack and try to post-process it into a Vagrant box, it bombs with this error: == openstack: Running post-processor: vagrant Build 'openstack' errored: 1 error(s) occurred: * Post-processor failed: Unknown artifact type, can't build box: mitchellh.openstack Because Packer doesn't know what Vagrant expects the provider to be, as explained here. In my opinion this a pretty big issue holding back the wider acceptance of OpenStack. When I am at a customer and introduce them to tools like Vagrant and Packer and how well they work with AWS, I still avoid the conversation about OpenStack when I would really love to put them on our (Elastx's) public cloud. What say you? Could I get a +1 from those who see this as a worthwhile issue? Cheers, Phil. -- Philip Cheong Elastx | Public and Private PaaS email: philip.che...@elastx.se office: +46 8 557 728 10 mobile: +46 702 870 814 twitter: @Elastx http://elastx.se ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Philip Cheong* *Elastx *| Public and Private PaaS email: philip.che...@elastx.se office: +46 8 557 728 10 mobile: +46 702 870 814 twitter: @Elastx https://twitter.com/Elastx http://elastx.se ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [QA] Meeting Thursday October 30th at 22:00 UTC
Hi everyone, Just a quick reminder that the weekly OpenStack QA team IRC meeting will be tomorrow Thursday, October 30th at 22:00 UTC in the #openstack-meeting channel. The agenda for tomorrow's meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Anyone is welcome to add an item to the agenda. It's also worth noting that a few weeks ago we started having a regular dedicated Devstack topic during the meetings. So if anyone is interested in Devstack development please join the meetings to be a part of the discussion. To help people figure out what time 22:00 UTC is in other timezones tomorrow's meeting will be at: 18:00 EDT 07:00 JST 08:30 ACDT 23:00 CET 17:00 CDT 15:00 PDT -Matt Treinish pgpVuSktxCGtI.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron]issue about dvr flows and port timestamp
Yes, actually, we have done some effort and practice to ensure that dvr has a better performance and stability, but i am not sure whether it would be accepted, so that's why i say : (I’m not sure whether the following issue is problematic…). in my opinion, i think it's very helpful. 2014-10-29 20:36 GMT+08:00 Hly henry4...@gmail.com: Sent from my iPad On 2014-10-29, at 下午6:33, Maru Newby ma...@redhat.com wrote: On Oct 29, 2014, at 8:12 AM, Yangxurong yangxur...@huawei.com wrote: Hi, I’m not sure whether following issue is problematic, and both, our team do some effort, so I submit two blueprints: [1.] optimize dvr flows: Currently, accurate ovs flows in terms of full mac are used to communicate among distributed router, but here comes problem : (1)the more distributed router node, the more flows; (2)different distributed router across DC cannot communicate through tunnel and additional operation under same mac prefix configuration. So it would be useful to shift the complete-matching of mac to fuzzy Matching, like prefix matching, reducing the number of flows and leading to communicate among different DC though configuring same mac prefix through tunnel. Link: https://blueprints.launchpad.net/neutron/+spec/optimize-dvr-flows I think we need to focus on paying down technical debt (both in the code and on the testing side) related to dvr before we seriously consider the kind of optimization that you are proposing. I’m also unclear as to why we would want to pursue a solution to a problem whose severity doesn’t appear to be clear (I’m not sure whether the following issue is problematic…). DVR stability is the first class for sure, but if the code and logic could be less and simpler, there is more chance of stability. By my understanding, since DVR mac range has been configured as a prefix, so prefix based judgement instead of one by one flow setup triggered by mesh-like message notifying would simplify the code logic, thus indirectly contribute to overall stability. Also, it would remove hundreds of flows in the ovs in a middle scale cluster, very helpful for trouble shooting. Wu Maru [2.]add port timestamp: It would be worth adding timestamp fields including create_at, update_at and delete_at in the table of port in neutron, so users can monitor port change conveniently, for example portal or management center wants to query the ports that have changed or refreshed during the latest 5sec in a large scale application. If not, it's time-consuming and low effectiveness. Link: https://blueprints.launchpad.net/neutron/+spec/add-port-timestamp Any response I will appreciate. Thanks, Xurong Yang ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][QoS] Pod time at Paris Summit
Hi, +1 thanks On Wed, Oct 29, 2014 at 7:19 AM, Kevin Benton blak...@gmail.com wrote: I believe Déjà vu is an appropriate term here. :-) Count me in. On Tue, Oct 28, 2014 at 1:16 PM, Collins, Sean sean_colli...@cable.comcast.com wrote: Hi, Like Atlanta, I will be at the summit. If there is interest, I can schedule a time to talk about the QoS API extension. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron]issue about dvr flows and port timestamp
On Oct 29, 2014, at 1:36 PM, Hly henry4...@gmail.com wrote: Sent from my iPad On 2014-10-29, at 下午6:33, Maru Newby ma...@redhat.com wrote: On Oct 29, 2014, at 8:12 AM, Yangxurong yangxur...@huawei.com wrote: Hi, I’m not sure whether following issue is problematic, and both, our team do some effort, so I submit two blueprints: [1.] optimize dvr flows: Currently, accurate ovs flows in terms of full mac are used to communicate among distributed router, but here comes problem : (1)the more distributed router node, the more flows; (2)different distributed router across DC cannot communicate through tunnel and additional operation under same mac prefix configuration. So it would be useful to shift the complete-matching of mac to fuzzy Matching, like prefix matching, reducing the number of flows and leading to communicate among different DC though configuring same mac prefix through tunnel. Link: https://blueprints.launchpad.net/neutron/+spec/optimize-dvr-flows I think we need to focus on paying down technical debt (both in the code and on the testing side) related to dvr before we seriously consider the kind of optimization that you are proposing. I’m also unclear as to why we would want to pursue a solution to a problem whose severity doesn’t appear to be clear (I’m not sure whether the following issue is problematic…). DVR stability is the first class for sure, but if the code and logic could be less and simpler, there is more chance of stability. By my understanding, since DVR mac range has been configured as a prefix, so prefix based judgement instead of one by one flow setup triggered by mesh-like message notifying would simplify the code logic, thus indirectly contribute to overall stability. Also, it would remove hundreds of flows in the ovs in a middle scale cluster, very helpful for trouble shooting. If we’re going to refactor/optimize/whatever any part of Neutron, the first requirement is that we can maintain the expectations of the code (i.e. ensure good test coverage) across changes. DVR is no different from any other feature in this regard. I would welcome any effort you want to devote to improving DVR’s testing story such that the kind of optimizations you are proposing would have less potential to cause regressions. In addition to baseline test coverage, I would also expect to see test additions validating flow generation such that reviewers would be able to easily identify the benefit of your proposed optimizations by comparing the results before and after. Maru Wu Maru [2.]add port timestamp: It would be worth adding timestamp fields including create_at, update_at and delete_at in the table of port in neutron, so users can monitor port change conveniently, for example portal or management center wants to query the ports that have changed or refreshed during the latest 5sec in a large scale application. If not, it's time-consuming and low effectiveness. Link: https://blueprints.launchpad.net/neutron/+spec/add-port-timestamp Any response I will appreciate. Thanks, Xurong Yang ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Commit flags
Based on the thread this morning around the NFVImpact flag [1], I saw this commit [2] into the neutron-specs repository to add an APIImpact flag. Given the discussion around NFVImpact, and the move away from it, I just wanted to bring this up in the broader community context and make sure everyone is on board with adding APIImpact before we start merging this and requiring specs to have this which change APIs. Thanks, Kyle [1] http://lists.openstack.org/pipermail/openstack-dev/2014-October/049438.html [2] https://review.openstack.org/#/c/131623/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] BGP - VPN BoF session in Kilo design summit
Hi, thanks jaume for planning this bof. the bgpvpn spec [2] has been initiated by nati ueno. I hope nati will attend this bof too. our proposal is to try to implement this spec with existing Neutron components [4]. Me and thomas will also have a tech talk about BGPVPN on tuesday, 1:15 PM. [5] [4]https://docs.google.com/drawings/d/1NN4tDgnZlBRr8ZUf5-6zzUcnDOUkWSnSiPm8LuuAkoQ/edit [5]http://openstack.prov12n.com/vbrownbag-techtalk-schedule-at-openstack-summit-paris-2/ On Wed, Oct 29, 2014 at 12:26 PM, Jaume Devesa devv...@gmail.com wrote: Hello, it seems like the BGP dynamic routing it is in a good shape to be included in Neutron during Kilo[1]. There is quite interest in offer BGP-VPN too. Mathieu Rohon's spec[2] goes in this direction. Of course it makes sense that his development leverages the BGP one. I would like to have a BoF session and invite anyone interested on these blueprints to join us or even add a new related one. I've created an etherpad[3] to share ideas and agree with session schedule. I propose Wednesday afternoon. If Carl Baldwin is agree, we can talk about it also during the open discussion of today's L3 subteam meeting. [1]: https://review.openstack.org/#/c/125401/ [ 2]: https://review.openstack.org/#/c/125401/ [3]: https://etherpad.openstack.org/p/bgp-vpn-dynamic-routing Cheers, -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Clear all flows when ovs agent start? why and how avoid?
On Wed, Oct 29, 2014 at 7:25 AM, Hly henry4...@gmail.com wrote: Sent from my iPad On 2014-10-29, at 下午8:01, Robert van Leeuwen robert.vanleeu...@spilgames.com wrote: I find our current design is remove all flows then add flow by entry, this will cause every network node will break off all tunnels between other network node and all compute node. Perhaps a way around this would be to add a flag on agent startup which would have it skip reprogramming flows. This could be used for the upgrade case. I hit the same issue last week and filed a bug here: https://bugs.launchpad.net/neutron/+bug/1383674 From an operators perspective this is VERY annoying since you also cannot push any config changes that requires/triggers a restart of the agent. e.g. something simple like changing a log setting becomes a hassle. I would prefer the default behaviour to be to not clear the flows or at the least an config option to disable it. +1, we also suffered from this even when a very little patch is done I'd really like to get some input from the tripleo folks, because they were the ones who filed the original bug here and were hit by the agent NOT reprogramming flows on agent restart. It does seem fairly obvious that adding an option around this would be a good way forward, however. Thanks, Kyle Cheers, Robert van Leeuwen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][nova] New specs on routed networking
On Oct 28, 2014, at 12:44 AM, A, Keshava keshav...@hp.com wrote: Here thinking OpenStack cloud as hierarchical network instead of Flat network ? A routed network has one lookup just like a bridged network. The difference is that the router operates as a host in the L2 domain - it only receives or operates on messages sent to its MAC address or to multicast addresses it accepts. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Bringing some DevOps love to Openstack
On 29/10/14 15:30 +0100, Philip Cheong wrote: Yes, the aim is to get a vagrant-openstack provider plugin under Hashicorp's or Mitchellh's github account. Whether you call that official or blessed, doesn't really matter. In order for Vagrant to integrate with other tools such as Packer there needs to be a preferred plugin. Hopefully the owners of the other plugins will agree to deprecate theirs so that an end can be put to the fragmentation that has happened so far and direct contributors to the correct place. FWIW, I'm happy to deprecate mine! Flavio On 29 October 2014 10:04, Flavio Percoco fla...@redhat.com wrote: On 28/10/14 21:23 +0100, Philip Cheong wrote: Hi all, In preparation of the OpenStack Summit in Paris next week, I'm hoping to speak to some people in the OpenStack foundation about the benefits of a partnership with Hashicorp, who make fantastic tools like Vagrant and Packer (and others). As a n00b aspiring to become an OpenStack contributor, the variety of Vagrant devstack environments is pretty overwhelming. It appears to me that it really depends on what project you are contributing to, which denotes which devstack you should use. The ones I have tried take a long time (45 mins+) to provision from scratch. One aspect which I am acutely aware of is developer productivity and 45 minutes is a lot of time. Packer was designed to help alleviate bottleneck, and Vagrantcloud has inbuilt support for the versioning of Vagrant boxes. It would be a pretty straight forward exercise to use Packer to do a daily (or however often) build of a devstack box and upload it to Vagrantcloud for developers to download. With a decent internet connection that time would be significantly less than 45 minutes. I would really like to think that this community should also be able to come to a consensus over what to include in a standard devstack. That there currently seems to be many different flavours cannot help with issues of fragmentation between so many different moving parts to build an OpenStack environment. Another big issue that I hope to address with the foundation, is the integration of Hashicorp's tools with OpenStack. The various Vagrant plugins to add OpenStack as a provider is a mess. There is one specific for Rackspace who have a different Keystone API, and at least 3 others for the vanilla OpenStack: https://github.com/mitchellh/vagrant-rackspace https://github.com/ggiamarchi/vagrant-openstack-provider https://github.com/cloudbau/vagrant-openstack-plugin https://github.com/FlaPer87/vagrant-openstack I'm pretty sure mine doesn't even work any more, I don't even know ruby ;) I do see a value in having a vagrant-openstack provider but I don't think we should pick one and mark it as blessed. We're trying very hard to move away from 'blessing' projecs, at the very least depend less on it. Anyone should feel free to create the provider on stackforge and maintain it. What would be even better is to have Hashicorp itself creating and maintaining this provider. Cheers, Flavio The significance of not having an official provider, for one example, is when you use Packer to build an image in OpenStack and try to post-process it into a Vagrant box, it bombs with this error: == openstack: Running post-processor: vagrant Build 'openstack' errored: 1 error(s) occurred: * Post-processor failed: Unknown artifact type, can't build box: mitchellh.openstack Because Packer doesn't know what Vagrant expects the provider to be, as explained here. In my opinion this a pretty big issue holding back the wider acceptance of OpenStack. When I am at a customer and introduce them to tools like Vagrant and Packer and how well they work with AWS, I still avoid the conversation about OpenStack when I would really love to put them on our (Elastx's) public cloud. What say you? Could I get a +1 from those who see this as a worthwhile issue? Cheers, Phil. -- Philip Cheong Elastx | Public and Private PaaS email: philip.che...@elastx.se office: +46 8 557 728 10 mobile: +46 702 870 814 twitter: @Elastx http://elastx.se ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco ___
[openstack-dev] [Solum] Solum Design Session at OpenStack Summit
Team, See below. For those of us attending the OpenStack Summit in Paris, please be sure to plan your schedule so you can attend this session. Thanks, Adrian Begin forwarded message: From: Chris Hoge ch...@openstack.org Subject: Solum Design Session at OpenStack Summit Date: October 22, 2014 at 11:09:55 AM PDT To: Adrian Otto adrian.o...@rackspace.com Hi, Here is the latest schedule information for the Solum Design Session at the OpenStack Summit. Thanks, Chris http://kilodesignsummit.sched.org/event/4e2033ced61b8dadf7a2db1aee6d8123 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] No meeting this week
Hey, this is just a friendly reminder that we're skipping the meeting this week as it is so close to the summit and many are travelling already. We also wont have one the week of the summit for obvious reasons. See you all in Paris! Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [QA][All] Prelude to functional testing summit discussions
Hi everyone, Before we start the larger discussion at summit next week about the future of testing in OpenStack - specifically about spinning up functional testing and how it relates to tempest - I would like to share some of my thoughts on how we can get things started and how I think they'll eventually come together. Currently in tempest we have a large number of tests (mostly api-focused) which are probably a better fit for a project's functional test suite. The best example I can think of is the nova flavors tests. Validation of flavor manipulation doesn't need to run in the integrated test suite on every commit to every project because it only requires Nova. A simple win for initiating in-tree functional testing would be to move these kinds of tests into the projects and run the tests from the project repos instead of from tempest. This would have the advantage of making tempest slimmer for every project and begin the process of getting projects to take responsibility for their functional testing rather than relying on tempest. As tests are moved tempest can start to become the integration test suite it was meant to be. It would retain only tests that involve multiple projects and stop being the OpenStack black box testing suite. I think that this is the right direction for tempest moving forward, especially as we move to having project-specific functional testing. Doing this migration is dependent on some refactors in tempest and moving the required bits to tempest-lib so they can be easily consumed by the other projects. This will be discussed at summit, is being planned for implementation this cycle, and is similar to what is currently in progress for the cli tests. The only reason this testing existed in tempest in the first place was as mechanism to block and then add friction against breaking api changes. Tempest's api testing has been been pretty successful at achieving these goals. We'll want to ensure that migrated tests retain these characteristics. If we are using clients from tempest-lib we should get this automatically since to break the api you'd have to change the api client. Another option proposed was to introduce a hacking rule that would block changes to api tests at the same time other code was being changed. There is also a concern for external consumers of tempest if we move the tests out of the tempest tree (I'm thinking refstack). I think the solution is to maintain a load_tests discovery method inside of tempest or elsewhere that will run the appropriate tests from the other repos for something like refstack. Assuming that things are built in a compatible way using the same framework then running the tests from separate repos should be a simple matter of pointing the test runner in the right direction. I also want to comment on the role of functional testing. What I've proposed here is only one piece of what project specific functional testing should be and just what I feel is a good/easy start. I don't feel that this should be the only testing done in the projects. I'm suggesting this as a first step because the tests already exist and it should be a relatively simple task. I also feel that using tempest-lib like this shouldn't be a hard requirement. Ideally the client definitions shouldn't have to live externally, or if they did they would be the official clients, but I am suggesting this as a first step to start a migration out of tempest. I don't want anyone to feel that they need block their functional testing efforts until tempest-lib becomes more useable. The larger value from functional testing is actually in enabling testing more tightly coupled to the projects (e.g. whitebox testing). I feel that any work necessary to enable functional testing should be prioritized. -Matt Treinish pgpE5i_OwYONG.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] periodic jobs for master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 25/10/14 00:16, James E. Blair wrote: Andrea Frittoli andrea.fritt...@gmail.com writes: I also believe we can find ways to make post-merge / periodic checks useful. We need to do that to keep the gate to a sane scale. Yes, we have a plan to do that that we outlined at the infra/QA meetup this summer and described to this list in this email: http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html Particularly this part, but please read the whole message if you have not already, or have forgotten it: * For all non gold standard configurations, we'll dedicate a part of our infrastructure to running them in a continuous background loop, as well as making these configs available as experimental jobs. The idea here is that we'll actually be able to provide more configurations that are operating in a more traditional CI (post merge) context. People that are interested in keeping these bits functional can monitor those jobs and help with fixes when needed. The experimental jobs mean that if developers are concerned about the effect of a particular change on one of these configs, it's easy to request a pre-merge test run. In the near term we might imagine this would allow for things like ceph, mongodb, docker, and possibly very new libvirt to be validated in some way upstream. * Provide some kind of easy to view dashboards of these jobs, as well as a policy that if some job is failing for some period of time, it's removed from the system. We want to provide whatever feedback we can to engaged parties, but people do need to realize that engagement is key. The biggest part of putting tests into OpenStack isn't landing the tests, but dealing with their failures. I'm glad to see people interested in this. If you're ready to contribute to it, please stop by #openstack-infra or join our next team meeting[1] to discuss how you can help. I'm sorry I've missed the email that you referred to before. Indeed, it looks like I'm not the first one who started to think about the matter. Summit wise, will there be any sessions where the subject will be discussed? -Jim [1] https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUUReJAAoJEC5aWaUY1u57H6QH/17FbSgU5vvwM03OzfSCpsZi IAG6T/UThfVQ8H08cHk6R+US9TkKdrl1QTJCDr70QhKbzLy+7OKp/H3B/PIuhaaN enqDp7ku3XQotxRTw6AW/ksLb9LCZCMMRtDiFOemC2TI6jqNXBKRz+TwFh2terY3 a9YH8IoYk2qYyLZ0fcv+OXdS7If+zD3u0PGOAJCBwKWbpUv82STdzjbDCATM779g rBC9BgYheSYPYfNjxpPKb/UN7aJZ/4TRPgK6MWktHGmqhZzZmlFPme+7x0rLdMvz 5/4m2Oh6k6Th/y1TV65jYcZID50w1esMO7tGdvmtX6Drc9lB9Y0r3fQF7R2eYpE= =FmKW -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] periodic jobs for master
I'm sorry I've missed the email that you referred to before. Indeed, it looks like I'm not the first one who started to think about the matter. Summit wise, will there be any sessions where the subject will be discussed? Yes. About post merge CI: http://kilodesignsummit.sched.org/event/1e33d1f4896a52e2c02b062cfc18ba39#.VFEZqvmsV8E About moving functional test to projects: http://kilodesignsummit.sched.org/event/575938e4837e8293615845582d7e3e7f#.VFEaM_msV8E Andrea Frittoli (andreaf) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] Summit track scheduling tweak
Hi, I've just swapped the functional testing and object status sessions in our track. This was done so that the QA team could attend the functional testing session, which originally conflicted with their sessions. Hopefully this doesn't create problems for anyone else, but I figured an announcement here was a good idea. I've pushed an update to sched.org, but it might take a few minutes to propagate. Cheers, Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Solum Design Session at OpenStack Summit
Noted. Looking forward to the face time. Lee On 10/29/14, 9:30 AM, Adrian Otto adrian.o...@rackspace.com wrote: Team, See below. For those of us attending the OpenStack Summit in Paris, please be sure to plan your schedule so you can attend this session. Thanks, Adrian Begin forwarded message: From: Chris Hoge ch...@openstack.org Subject: Solum Design Session at OpenStack Summit Date: October 22, 2014 at 11:09:55 AM PDT To: Adrian Otto adrian.o...@rackspace.com Hi, Here is the latest schedule information for the Solum Design Session at the OpenStack Summit. Thanks, Chris http://kilodesignsummit.sched.org/event/4e2033ced61b8dadf7a2db1aee6d8123 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Commit flags
On 10/29/2014 11:05 AM, Kyle Mestery wrote: Based on the thread this morning around the NFVImpact flag [1], I saw this commit [2] into the neutron-specs repository to add an APIImpact flag. Given the discussion around NFVImpact, and the move away from it, I just wanted to bring this up in the broader community context and make sure everyone is on board with adding APIImpact before we start merging this and requiring specs to have this which change APIs. I'm OK with that flag. We approved the use of the same thing in Nova: https://review.openstack.org/#/c/129757/ I think the criteria should be around how broad the impact and interest in tracking is. I think tracking API changes has broad enough interest and support that the flag makes sense. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Solum Design Session at OpenStack Summit
+1 Thanks for the heads up! See you there! On 29 October 2014 19:15, Lee Calcote (lecalcot) lecal...@cisco.com wrote: Noted. Looking forward to the face time. Lee On 10/29/14, 9:30 AM, Adrian Otto adrian.o...@rackspace.com wrote: Team, See below. For those of us attending the OpenStack Summit in Paris, please be sure to plan your schedule so you can attend this session. Thanks, Adrian Begin forwarded message: From: Chris Hoge ch...@openstack.org Subject: Solum Design Session at OpenStack Summit Date: October 22, 2014 at 11:09:55 AM PDT To: Adrian Otto adrian.o...@rackspace.com Hi, Here is the latest schedule information for the Solum Design Session at the OpenStack Summit. Thanks, Chris http://kilodesignsummit.sched.org/event/4e2033ced61b8dadf7a2db1aee6d8123 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Philip Cheong* *Elastx *| Public and Private PaaS email: philip.che...@elastx.se office: +46 8 557 728 10 mobile: +46 702 870 814 twitter: @Elastx https://twitter.com/Elastx http://elastx.se ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Clear all flows when ovs agent start? why and how avoid?
I must admit I haven't digged up too much, but this might also look suspicious: https://review.openstack.org/#/c/96782/ Perhaps it's a combination of both? :) On 29 October 2014 08:17, Kyle Mestery mest...@mestery.com wrote: On Wed, Oct 29, 2014 at 7:25 AM, Hly henry4...@gmail.com wrote: Sent from my iPad On 2014-10-29, at 下午8:01, Robert van Leeuwen robert.vanleeu...@spilgames.com wrote: I find our current design is remove all flows then add flow by entry, this will cause every network node will break off all tunnels between other network node and all compute node. Perhaps a way around this would be to add a flag on agent startup which would have it skip reprogramming flows. This could be used for the upgrade case. I hit the same issue last week and filed a bug here: https://bugs.launchpad.net/neutron/+bug/1383674 From an operators perspective this is VERY annoying since you also cannot push any config changes that requires/triggers a restart of the agent. e.g. something simple like changing a log setting becomes a hassle. I would prefer the default behaviour to be to not clear the flows or at the least an config option to disable it. +1, we also suffered from this even when a very little patch is done I'd really like to get some input from the tripleo folks, because they were the ones who filed the original bug here and were hit by the agent NOT reprogramming flows on agent restart. It does seem fairly obvious that adding an option around this would be a good way forward, however. Thanks, Kyle Cheers, Robert van Leeuwen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][nova] New specs on routed networking
Some of us are looking at a different model. I’d be interested in your thoughts. Fred, Thanks for the link to the drafts. They look extremely similar to the approach we've been pursuing for Project Calico, and it's good to see that we're not the only people thinking in this direction. It looks like the main differences between our approach and yours are that we've tried to come up with a model that works both for IPv4 and IPv6 (although we agree that moving the data center fabric to IPv6 has a lot of advantages - e.g. we are planning on using 464XLAT as the mechanism to handle IPv4 overlap). Given this, we've focused our policy/security model on ACLs rather than flow labels. An interesting derivative effect of that choice is that any policy or security model can be enforced (such as intra-tenant controls, extra-cloud controls, etc). As a side note, we have been interested in using flow labels as namespace identifiers and for SFC. Recently, we have moved away from that thinking given the guidance that the flow label should be not be modified in flight. If you believe that such modifications will be acceptable, we would love to discuss that with you, and see where we can collaborate. As it is, I believe our proposed changes to Nova and Neutron should be generic enough to provide a basis for implementing your approach as well as supporting our Project Calico ML2 driver. If they aren't, we should work together to make whatever changes we have to make to achieve that generality. It might also be worth checking out our agent code[0]. It's in the middle of a rewrite at the minute so the code is unfinished, but it handles a lot of what you'd be doing with your proposed drafts. Hopefully it'd be a useful jumping off point. Cory [0]: https://github.com/Metaswitch/calico/tree/master/calico/felix ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][CI] nova-networking or neutron netwokring for CI
On Wed, Oct 29, 2014 at 2:23 AM, Andreas Scheuring scheu...@linux.vnet.ibm.com wrote: Thanks for the feedback. OK, got it, nova networking is not a requirement for a CI. Then I'll see not a single reason to support it. We will investigate in the neutron way for our CI and also for production. I wouldn't go so far as to say there is no reason to support nova-networking in your CI system, and we are working on deprecating it. It hasn't been deprecated yet. Ideally you could test both neutron and nova-network, but if you had to choose one it should be neutron. Now coming back to the Hypervisorsupportmatrix ( https://wiki.openstack.org/wiki/HypervisorSupportMatrix ). I guess the scope of this matrix is only nova and not neutron,cinder,.. isn't it? So in this matrix I have to tick the networking lines (vlan, routing,..) as NOT supported, right? (as scope is neutron-networking, altough we would support it with neutron). Correct, if you don' support nova-network at all, then you should have an 'X' in those boxes. Thanks, Andreas -- Andreas (irc: scheuran) On Tue, 2014-10-28 at 11:06 -0700, Joe Gordon wrote: On Tue, Oct 28, 2014 at 6:44 AM, Dan Smith d...@danplanet.com wrote: Are current nova CI platforms configured with nova-networking or with neutron networking? Or is networking in general not even a part of the nova CI approach? I think we have several that only run on Neutron, so I think it's fine to just do that. Agreed, neutron should be considered required for all of the reasons listed above. --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][nova] New specs on routed networking
Certainly, let’s talk next week in Paris. On Oct 29, 2014, at 12:11 PM, Cory Benfield cory.benfi...@metaswitch.com wrote: Some of us are looking at a different model. I’d be interested in your thoughts. Fred, Thanks for the link to the drafts. They look extremely similar to the approach we've been pursuing for Project Calico, and it's good to see that we're not the only people thinking in this direction. It looks like the main differences between our approach and yours are that we've tried to come up with a model that works both for IPv4 and IPv6 (although we agree that moving the data center fabric to IPv6 has a lot of advantages - e.g. we are planning on using 464XLAT as the mechanism to handle IPv4 overlap). Given this, we've focused our policy/security model on ACLs rather than flow labels. An interesting derivative effect of that choice is that any policy or security model can be enforced (such as intra-tenant controls, extra-cloud controls, etc). As a side note, we have been interested in using flow labels as namespace identifiers and for SFC. Recently, we have moved away from that thinking given the guidance that the flow label should be not be modified in flight. If you believe that such modifications will be acceptable, we would love to discuss that with you, and see where we can collaborate. As it is, I believe our proposed changes to Nova and Neutron should be generic enough to provide a basis for implementing your approach as well as supporting our Project Calico ML2 driver. If they aren't, we should work together to make whatever changes we have to make to achieve that generality. It might also be worth checking out our agent code[0]. It's in the middle of a rewrite at the minute so the code is unfinished, but it handles a lot of what you'd be doing with your proposed drafts. Hopefully it'd be a useful jumping off point. Cory [0]: https://github.com/Metaswitch/calico/tree/master/calico/felix ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat][nova] Changing default replacement_policy for Neutron port?
On 29/10/14 23:22, Steven Hardy wrote: On Wed, Oct 29, 2014 at 09:52:34AM +1300, Steve Baker wrote: On 29/10/14 09:28, Steve Baker wrote: snip I've looked at the tripleo templates now, and they create ports which are resources in their own right, so switching to replacement_policy:AUTO is entirely appropriate. However in most templates the vast majority of port resources are just to define a simple server/port/floating-IP combo. Therefore I think there is a good argument for the default REPLACE_ALWAYS causing the least problems for the majority of cases. Thanks for the information Steve, I've posted a patch moving the tripleo templates to AUTO, which should work around the immediate problem there. So, let me just try to clarify how we expect updates to work with the current default, lets take a simple example template: https://github.com/openstack/heat-templates/blob/master/hot/servers_in_new_neutron_net.yaml#L75 Here, we have two servers, both referencing ports, with both having a floating IP referencing the ports. Am I reading this right, it's impossible to update that template, as it's currently written, without always replacing both servers? If true, that to me is an indicator that REPLACE_ALWAYS is not a sane default. Not at all. The networks property of OS::Nova::Server is update_allowed=True (sub-properties of networks are not, but that only affects the generated documentation. This should be fixed) Can you clarify how updates are expected to work when you have the simple server/port/floating-IP combo, other than perhaps hiding the combo in a nested stack so we don't try to update it? It seems like we should be able to do the following (on a template containing a simple server/port/floating-IP combo): 1. Update the stack without changing the template. This shouldn't change anything. AUTO: nothing changes, all good REPLACE_ALWAYS: all ports are replaced, Server and FloatingIP are updated without replacement. The port churn is not ideal, but it does work. rich network property: same as AUTO, nothing changes, all good 2. Add another resource (e.g maybe another server/port/floating-IP) without destroying the first. Same as above for the existing resources. New resources are created as normal If we can't support both of those by default, updates are terminally broken for nearly all users IMO - but are we saying the rich network properties will solve that? Thanks for any further insight you can provide :) Here are some other update scenarios 3. Update the stack with a change which causes server replacement AUTO: new server is created while old server still exists. Attempt to attach port to new server which fails due to port still in use. If this was fixed then the port will disappear anyway, as nova will delete it when the old server is deleted REPLACE_ALWAYS: new port is attached to new server, old port is deleted when old server is deleted (whether by nova or heat) rich network property: same as REPLACE_ALWAYS 4. port with fixed IP address. Update the stack without changing the template AUTO: nothing changes, all good REPLACE_ALWAYS: new port with same fixed IP is created, fails since IP address is already claimed by old port rich network property: same as AUTO, nothing changes, all good 5. port with fixed IP address. Update the stack and change the fixed IP AUTO: port is replaced, Server and FloatingIP are updated without replacement. REPLACE_ALWAYS: same as AUTO rich network property: same as AUTO 6. port with fixed IP address. Update the stack with a change which causes server replacement, but no change to fixed IP address AUTO: same problems as 3. AUTO REPLACE_ALWAYS: Same problem as 4. REPLACE_ALWAYS rich network property: server create/update/delete logic also manages port create/update/delete, so it can do the required juggle to move the fixed IP from the old port to the new port So to summarize these scenarios Works fine -- AUTO: scenarios where the server isn't replaced and no fixed IP is defined on the port REPLACE_ALWAYS: scenarios where the server is replaced and no fixed IP is defined on the port rich network property: all scenarios Sub-optimal but works - REPLACE_ALWAYS: scenarios where the server isn't replaced and no fixed IP is defined on the port Doesn't work AUTO: all scenarios where the server is replaced REPLACE_ALWAYS: all scenarios where the port has a fixed IP address which doesn't change on stack update So I still think REPLACE_ALWAYS is still the least worst default, and rich network property will improve the situation. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra][all] Synchronizing local Git and Gerrit repositories
On 10/29/2014 07:02 AM, Ondrej Wisniewski wrote: If I understand correctly, we cannot use the OpenStack community Git servers as our central Git repository since developers cannot push to them. And we don't want to go through Gerrit and the code review procedure just to share a bit of code with somebody else in the team. Thus the need for a local mirror. I have been having similar questions as Dolph. Are you going to Paris by chance? It'd be great to have a chat in person and understand exactly your needs. Additionally also a local Gerrit server was set up to allow for internal code review within the team before submitting anything to the community server review.openstack.org http://review.openstack.org (which will be done eventually). As Dolph mentioned, you may be able to use review.openstack.org for that, keeping the patches as Work In Progress (workflow-1): your developers can all participate in the reviews and mark the change as 'Ready for review' when ready. This will allow you to stay close to trunk and avoid complex setup on your side. It also allows your developers to participate more in the 'openstack way' of doing things, maybe even do some code reviews for other patches while they're on review.openstack.org, it's less likely that your team will show up with a large patch after a long internal conversation. This is also helpful in case our Internet connection goes down, as we will still be able to follow the complete workflow inside the LAN. Fair enough: how often does your Internet connection drop? /stef -- Ask and answer questions on https://ask.openstack.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] TC election by the numbers
Folks, I haven't seen the customary number-crunching on the recent TC election, so I quickly ran the numbers myself. Voter Turnout = The turnout rate continues to decline, in this case from 29.7% to 26.7%. Here's how the participation rates have shaped up since the first TC2.0 election: Election | Electorate | Voted | Turnout | Change 10/2013 | 1106 | 342 | 30.9% | -8.0% 04/2014 | 1510 | 448 | 29.7% | -4.1% 10/2014 | 1892 | 506 | 26.7% | -9.9% Partisan Voting === As per the usual analysis done by ttx, the number of ballots that strictly preferred candidates from an individual company (with multiple candidates) above all others: HP ahead in 30 ballots (5.93%) RHAT ahead in 18 ballots (3.56%) RAX ahead in 8 ballots (1.58%) The top 6 pairings strictly preferred above all others were: 35 voters (6.92%) preferred Monty Taylor Doug Hellmann (HP/HP) 34 voters (6.72%) preferred Monty Taylor Sean Dague (HP/HP) 26 voters (5.14%) preferred Anne Gentle Monty Taylor(RAX/HP) 21 voters (4.15%) preferred Russell Bryant Sean Dague (RHAT/HP) 21 voters (4.15%) preferred Russell Bryant Eoghan Glynn (RHAT/RHAT) 16 voters (3.16%) preferred Doug Hellmann Sean Dague(HP/HP) Conclusion == The rate of potentially partisan voting didn't diverge significantly from the norms we've seen in previous elections. The continuing decline in the turnout rate is a concern however, as the small-scale changes tried (blogging on TC activity, standardized questions in the TC nomination mails) have not arrested the fall-off in participation. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Bringing some DevOps love to Openstack
On Oct 29, 2014, at 7:30 AM, Philip Cheong philip.che...@elastx.se wrote: Yes, the aim is to get a vagrant-openstack provider plugin under Hashicorp's or Mitchellh's github account. Whether you call that official or blessed, doesn't really matter. In order for Vagrant to integrate with other tools such as Packer there needs to be a preferred plugin. Hopefully the owners of the other plugins will agree to deprecate theirs so that an end can be put to the fragmentation that has happened so far and direct contributors to the correct place. My advice would be: get started now; worry about others deprecating at the Vancouver summit. ;] My experience has been that people who care look for people they know involved, popularity, and currency/signs-of-life. I'd bet that if you: * Provide the plugin under a clearly related, official github account which has good reputation (either hashicorp or mitchellh work for this) * Actively maintain it so the commit history shows signs of life * Publicize it widely, from their blog as well as others ... you'll gain the momentum you want within 3-6 months. --j ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Finalizing cross-project design summit track
Any chance we could use the opening to move either the Refstack session or the logging session from their current joint (and conflicting) time (15:40)? QA really would be appreciated at both. And I'd really like to be at both. I'd say the Refstack one would go better in the debug slot, as the API stuff is sort of related to the logging. Switching with one of the 14:50 sessions might also work. Just hoping. I really want great participation at all of these sessions. --rocky -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: Wednesday, October 29, 2014 6:35 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [All] Finalizing cross-project design summit track On 10/29/2014 07:22 AM, Sean Dague wrote: On 10/28/2014 05:22 PM, Russell Bryant wrote: A draft schedule has been posted for the cross-project design summit track: http://kilodesignsummit.sched.org/overview/type/cross-project+workshops#.VFAFFXVGjUa If you have any schedule changes to propose for really bad conflicts, please let me know. We really tried to minimize conflicts, but it's impossible to resolve them all. The next steps are to identify session leads and get the leads to write session descriptions to put on the schedule. We're collecting both at the top of the proposals etherpad: https://etherpad.openstack.org/p/kilo-crossproject-summit-topics If you were the proposer of one of these sessions and are not already listed as the session lead, please add yourself. If you'd like to volunteer to lead a session that doesn't have a lead, please speak up. For the sessions you are leading, please draft a description on the etherpad that can be used for the session on sched.org. Thank you! I was trying to track down the origin of the Debugging Gate Failures submission - http://kilodesignsummit.sched.org/event/5cfc92906adc5830355ddcedbb95d977 (through matching hex author colors in etherpad... fun!) It looks like John G copied it over because someone (lost to the mists of time) put it in the Nova ideas etherpad. I'd actually argue that a 40 minute interactive session without much prep isn't going to be all that useful (and honestly probably a terrible experience for all parties involved). This is a topic that Jay, Dan, and I have discussed for doing an upcoming bootstrapping hour on (which also means it would have a long term archived version), and I think that's probably a better way to do a thing like this. As there is no owner for this, there is no one to pull it out of the agenda. But I think it's something that should be considered. Actually, it was me who added that to the cross-project session proposal etherpad :) But, that said, I agree with you that the format of the cross-project sessions are not ideal for this topic and it would be better as an archived OBH session. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
On Oct 29, 2014, at 3:32 PM, Eoghan Glynn egl...@redhat.com wrote: Folks, I haven't seen the customary number-crunching on the recent TC election, so I quickly ran the numbers myself. Voter Turnout = The turnout rate continues to decline, in this case from 29.7% to 26.7%. Here's how the participation rates have shaped up since the first TC2.0 election: Election | Electorate | Voted | Turnout | Change 10/2013 | 1106 | 342 | 30.9% | -8.0% 04/2014 | 1510 | 448 | 29.7% | -4.1% 10/2014 | 1892 | 506 | 26.7% | -9.9% Overall percentage of the electorate voting is declining, but absolute numbers of voters has increased. And in fact, the electorate has grown more than the turnout has declined. Partisan Voting === As per the usual analysis done by ttx, the number of ballots that strictly preferred candidates from an individual company (with multiple candidates) above all others: HP ahead in 30 ballots (5.93%) RHAT ahead in 18 ballots (3.56%) RAX ahead in 8 ballots (1.58%) The top 6 pairings strictly preferred above all others were: 35 voters (6.92%) preferred Monty Taylor Doug Hellmann (HP/HP) 34 voters (6.72%) preferred Monty Taylor Sean Dague (HP/HP) 26 voters (5.14%) preferred Anne Gentle Monty Taylor(RAX/HP) 21 voters (4.15%) preferred Russell Bryant Sean Dague (RHAT/HP) 21 voters (4.15%) preferred Russell Bryant Eoghan Glynn (RHAT/RHAT) 16 voters (3.16%) preferred Doug Hellmann Sean Dague(HP/HP) Conclusion == The rate of potentially partisan voting didn't diverge significantly from the norms we've seen in previous elections. The continuing decline in the turnout rate is a concern however, as the small-scale changes tried (blogging on TC activity, standardized questions in the TC nomination mails) have not arrested the fall-off in participation. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
On Oct 29, 2014, at 3:32 PM, Eoghan Glynn egl...@redhat.com wrote: Folks, I haven't seen the customary number-crunching on the recent TC election, so I quickly ran the numbers myself. Voter Turnout = The turnout rate continues to decline, in this case from 29.7% to 26.7%. Here's how the participation rates have shaped up since the first TC2.0 election: Election | Electorate | Voted | Turnout | Change 10/2013 | 1106 | 342 | 30.9% | -8.0% 04/2014 | 1510 | 448 | 29.7% | -4.1% 10/2014 | 1892 | 506 | 26.7% | -9.9% Overall percentage of the electorate voting is declining, but absolute numbers of voters has increased. And in fact, the electorate has grown more than the turnout has declined. True that, but AFAIK the generally accepted metric on participation rates in elections is turnout as opposed to absolute voter numbers. Cheers, Eoghan Partisan Voting === As per the usual analysis done by ttx, the number of ballots that strictly preferred candidates from an individual company (with multiple candidates) above all others: HP ahead in 30 ballots (5.93%) RHAT ahead in 18 ballots (3.56%) RAX ahead in 8 ballots (1.58%) The top 6 pairings strictly preferred above all others were: 35 voters (6.92%) preferred Monty Taylor Doug Hellmann (HP/HP) 34 voters (6.72%) preferred Monty Taylor Sean Dague (HP/HP) 26 voters (5.14%) preferred Anne Gentle Monty Taylor(RAX/HP) 21 voters (4.15%) preferred Russell Bryant Sean Dague (RHAT/HP) 21 voters (4.15%) preferred Russell Bryant Eoghan Glynn (RHAT/RHAT) 16 voters (3.16%) preferred Doug Hellmann Sean Dague(HP/HP) Conclusion == The rate of potentially partisan voting didn't diverge significantly from the norms we've seen in previous elections. The continuing decline in the turnout rate is a concern however, as the small-scale changes tried (blogging on TC activity, standardized questions in the TC nomination mails) have not arrested the fall-off in participation. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Finalizing cross-project design summit track
On 10/29/2014 06:46 PM, Rochelle Grober wrote: Any chance we could use the opening to move either the Refstack session or the logging session from their current joint (and conflicting) time (15:40)? QA really would be appreciated at both. And I'd really like to be at both. I'd say the Refstack one would go better in the debug slot, as the API stuff is sort of related to the logging. Switching with one of the 14:50 sessions might also work. Just hoping. I really want great participation at all of these sessions. The gate debugging session is most likely going to be dropped at this point. I don't see a big problem with moving the refstack one to that slot (the first time). Anyone else have a strong opinion on this? -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
Excerpts from Eoghan Glynn's message of 2014-10-29 16:37:42 -0700: On Oct 29, 2014, at 3:32 PM, Eoghan Glynn egl...@redhat.com wrote: Folks, I haven't seen the customary number-crunching on the recent TC election, so I quickly ran the numbers myself. Voter Turnout = The turnout rate continues to decline, in this case from 29.7% to 26.7%. Here's how the participation rates have shaped up since the first TC2.0 election: Election | Electorate | Voted | Turnout | Change 10/2013 | 1106 | 342 | 30.9% | -8.0% 04/2014 | 1510 | 448 | 29.7% | -4.1% 10/2014 | 1892 | 506 | 26.7% | -9.9% Overall percentage of the electorate voting is declining, but absolute numbers of voters has increased. And in fact, the electorate has grown more than the turnout has declined. True that, but AFAIK the generally accepted metric on participation rates in elections is turnout as opposed to absolute voter numbers. IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two elections prior to this one filtered out. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate
+1, the hint should be persistent as other server instance metadata. From: Alex Xu [sou...@gmail.com] Sent: Wednesday, October 29, 2014 9:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate 2014-10-29 13:42 GMT+08:00 Chen CH Ji jiche...@cn.ibm.commailto:jiche...@cn.ibm.com: Yes, I remember that spec might talk about local storage (in local db?) and it can be the root cause And I think we need persistent storage otherwise the scheduler hints can't survive in some conditions such as system reboot or upgrade ? Yeah, that's problem. And I have talk with Jay Lau, look like there already got agreement on persistent it. Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.commailto:jiche...@cn.ibm.com Phone: +86-10-82454158tel:%2B86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC [Inactive hide details for Alex Xu ---10/29/2014 01:34:13 PM---On 2014年10月29日 12:37, Chen CH Ji wrote: ]Alex Xu ---10/29/2014 01:34:13 PM---On 2014年10月29日 12:37, Chen CH Ji wrote: From: Alex Xu x...@linux.vnet.ibm.commailto:x...@linux.vnet.ibm.com To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: 10/29/2014 01:34 PM Subject: Re: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate On 2014年10月29日 12:37, Chen CH Ji wrote: I think we already support to specify the host when doing evacuate and migration ? Yes, we support to specify the host, but schedule-hints is different thing. if we need use hints that passed from creating instance, that means we need to persistent schedule hints I remember we used to have a spec for store it locally ... I also remember we have one spec for persistent before, but I don't know why it didn't continue. And I think maybe we needn't persistent schedule-hints, just add pass new schedule-hints when migration the instance. Nova just need provide the mechanism. Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.commailto:jiche...@cn.ibm.com Phone: +86-10-82454158tel:%2B86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC [Inactive hide details for Alex Xu ---10/29/2014 12:19:35 PM---Hi, Currently migration/rebuild/evacuate didn't support pass]Alex Xu ---10/29/2014 12:19:35 PM---Hi, Currently migration/rebuild/evacuate didn't support pass From: Alex Xu x...@linux.vnet.ibm.commailto:x...@linux.vnet.ibm.com To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: 10/29/2014 12:19 PM Subject: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate Hi, Currently migration/rebuild/evacuate didn't support pass scheduler-hints, that means any migration can't use schedule-hints that passed when creating instance. Can we add scheduler-hints support when migration/rebuild/evacuate? That also can enable user move in/out instance to/from an server group. Thanks Alex ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
On 2014-10-29 18:27:48 -0700 (-0700), Clint Byrum wrote: IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two elections prior to this one filtered out. Well, the base electorate for the TC are active contributors with patches landed to official projects within the past year, so these are devs getting their code merged but not interested in voting. This is somewhat different from (though potentially related to) the dead weight foundation membership on the rolls for board elections. Also, foundation members who have not voted in two board elections are being removed from the membership now, from what I understand (we just needed to get to the point where we had two years worth of board elections in the first place). -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][All] Prelude to functional testing summit discussions
Hi Matt, Thanks for bringing this up, I am so interested in. 2014-10-30 1:30 GMT+09:00 Matthew Treinish mtrein...@kortar.org: Before we start the larger discussion at summit next week about the future of testing in OpenStack - specifically about spinning up functional testing and how it relates to tempest - I would like to share some of my thoughts on how we can get things started and how I think they'll eventually come together. Currently in tempest we have a large number of tests (mostly api-focused) which are probably a better fit for a project's functional test suite. The best example I can think of is the nova flavors tests. Validation of flavor manipulation doesn't need to run in the integrated test suite on every commit to every project because it only requires Nova. A simple win for initiating in-tree functional testing would be to move these kinds of tests into the projects and run the tests from the project repos instead of from tempest. I completely agree with the above comment. There is a lot of hard-coded negative tests in Tempest and most projects block these negative cases at their surfaces, these cases don't seem integrated tests. In addition, sometimes there are more corner cases in Tempest than each project. So it would be very nice to move this kind of tests from Tempest to each project and review them on the project. This would have the advantage of making tempest slimmer for every project and begin the process of getting projects to take responsibility for their functional testing rather than relying on tempest. As tests are moved tempest can start to become the integration test suite it was meant to be. It would retain only tests that involve multiple projects and stop being the OpenStack black box testing suite. I think that this is the right direction for tempest moving forward, especially as we move to having project-specific functional testing. +1 Doing this migration is dependent on some refactors in tempest and moving the required bits to tempest-lib so they can be easily consumed by the other projects. This will be discussed at summit, is being planned for implementation this cycle, and is similar to what is currently in progress for the cli tests. The only reason this testing existed in tempest in the first place was as mechanism to block and then add friction against breaking api changes. Tempest's api testing has been been pretty successful at achieving these goals. We'll want to ensure that migrated tests retain these characteristics. If we are using clients from tempest-lib we should get this automatically since to break the api you'd have to change the api client. Another option proposed was to introduce a hacking rule that would block changes to api tests at the same time other code was being changed. There is also a concern for external consumers of tempest if we move the tests out of the tempest tree (I'm thinking refstack). I think the solution is to maintain a load_tests discovery method inside of tempest or elsewhere that will run the appropriate tests from the other repos for something like refstack. Assuming that things are built in a compatible way using the same framework then running the tests from separate repos should be a simple matter of pointing the test runner in the right direction. I also want to comment on the role of functional testing. What I've proposed here is only one piece of what project specific functional testing should be and just what I feel is a good/easy start. I don't feel that this should be the only testing done in the projects. I'm suggesting this as a first step because the tests already exist and it should be a relatively simple task. I also feel that using tempest-lib like this shouldn't be a hard requirement. Ideally the client definitions shouldn't have to live externally, or if they did they would be the official clients, but I am suggesting this as a first step to start a migration out of tempest. +1 for moving functional tests which means non-cross projects tests to each project repo. I like to jump into this work, and I want to move negative tests to each project ASAP. Thanks Ken Ohmichi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
On Wed, Oct 29, 2014 at 6:27 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Eoghan Glynn's message of 2014-10-29 16:37:42 -0700: On Oct 29, 2014, at 3:32 PM, Eoghan Glynn egl...@redhat.com wrote: Folks, I haven't seen the customary number-crunching on the recent TC election, so I quickly ran the numbers myself. Voter Turnout = The turnout rate continues to decline, in this case from 29.7% to 26.7%. Here's how the participation rates have shaped up since the first TC2.0 election: Election | Electorate | Voted | Turnout | Change 10/2013 | 1106 | 342 | 30.9% | -8.0% 04/2014 | 1510 | 448 | 29.7% | -4.1% 10/2014 | 1892 | 506 | 26.7% | -9.9% Overall percentage of the electorate voting is declining, but absolute numbers of voters has increased. And in fact, the electorate has grown more than the turnout has declined. True that, but AFAIK the generally accepted metric on participation rates in elections is turnout as opposed to absolute voter numbers. IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two elections prior to this one filtered out. Sounds like you need to freshen up on your bylaws ;). There are methods to remove foundation members: Bylaws Appendix 1 Section 3 [0]. Also you have to be an ATC not just a Individual Member to vote, Appendix 4 Section 2 [1] [0] http://www.openstack.org/legal/individual-member-policy/ [1] http://www.openstack.org/legal/technical-committee-member-policy/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading
Hi keshava, Thanks for interested in Cascading. Here are some very simple explanation: Basically Datacenter is not in the 2-level tree of cascading. We use term POD to represent a cascaded child openstack (same meaning of your term Zone?). There may be single or multiple PODs in one Datacenter, Just like below: (A, B, C) ... (D, E) ... (F) ... (G) Each character represent a POD or child openstack, while parenthesis represent a Datacenter. Each POD has a corresponding virtual host node in the parent openstack, so when scheduler of any projects (nova/neutron/cinder...) locate a host node, the resource POD is determined, also with its geo-located Datacenter by side effect. Cascading don't schedule by Datacenter directly, DC is just an attribute of POD (for example we can configure host aggregate to identify a DC with multiple PODs). The upper scale of POD is fixed, maybe several hundreds, so a super large DC with tens of thousands servers could be built by modularized PODs, avoiding the difficult of tuning and maintaining such a huge monolithic openstack. Next do you mean networking reachability? Sorry for the limitation of mail post I can just give some very simple idea: in parent openstack the L2pop and DVR is used, so L2/L3 agent-proxy in each virtual host node can get all the vm reachability information of other POD, then they are set to local POD by Neutron REST API. However, cascading depends on some feature not exists yet in current Neutron, like L2GW, pluggable external network, WE Fwaas in DVR, centralized FIP in DVR... so we have to do some little patch in the front. In the future if these features is merged, these patch code can be removed. Indeed Neutron is the most challenge part of cascading, without considering those proxies in the parent openstack virtual host node, Neutron patchs account for 85% or more LOC in the whole project. Regards, Wu From: keshava [keshav...@hp.com] Sent: Wednesday, October 29, 2014 2:22 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading This is very interesting problem to solve. I am curious to know how the reachability is provided across different Datacenter. How to know which VM is part of which Datacenter? VM may be in different Zone but under same DC or in different DC itself. How this problem is solved? thanks regards, keshava -- View this message in context: http://openstack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-tp54115p56323.html Sent from the Developer mailing list archive at Nabble.com. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Finalizing cross-project design summit track
On 10/29/2014 09:07 PM, Russell Bryant wrote: On 10/29/2014 06:46 PM, Rochelle Grober wrote: Any chance we could use the opening to move either the Refstack session or the logging session from their current joint (and conflicting) time (15:40)? QA really would be appreciated at both. And I'd really like to be at both. I'd say the Refstack one would go better in the debug slot, as the API stuff is sort of related to the logging. Switching with one of the 14:50 sessions might also work. Just hoping. I really want great participation at all of these sessions. The gate debugging session is most likely going to be dropped at this point. I don't see a big problem with moving the refstack one to that slot (the first time). Anyone else have a strong opinion on this? Sounds good to me. -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
Excerpts from Jeremy Stanley's message of 2014-10-29 18:37:42 -0700: On 2014-10-29 18:27:48 -0700 (-0700), Clint Byrum wrote: IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two elections prior to this one filtered out. Well, the base electorate for the TC are active contributors with patches landed to official projects within the past year, so these are devs getting their code merged but not interested in voting. This is somewhat different from (though potentially related to) the dead weight foundation membership on the rolls for board elections. Also, foundation members who have not voted in two board elections are being removed from the membership now, from what I understand (we just needed to get to the point where we had two years worth of board elections in the first place). Thanks, I lost my mind here and confused the board with the TC. So then my next question is, of those who did not vote, how many are from under-represented companies? A higher percentage there might point to disenfranchisement. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer][Heat]Defining a webhook URL for alarm-actions
Hi, Thank you Steven, I followed templates given there in examples, created one for me(see attached), but I am getting following error in /var/log/heat/heat-api.log file: 2014-10-30 10:07:44.749 30476 TRACE root 2014-10-30 10:07:44.749 30476 TRACE root File /usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/dispatcher.py, line 172, in dispatch 2014-10-30 10:07:44.749 30476 TRACE root result = getattr(proxyobj, method)(ctxt, **kwargs) 2014-10-30 10:07:44.749 30476 TRACE root 2014-10-30 10:07:44.749 30476 TRACE root File /usr/lib/python2.7/dist-packages/heat/engine/service.py, line 60, in wrapped 2014-10-30 10:07:44.749 30476 TRACE root return func(self, ctx, *args, **kwargs) 2014-10-30 10:07:44.749 30476 TRACE root 2014-10-30 10:07:44.749 30476 TRACE root File /usr/lib/python2.7/dist-packages/heat/engine/service.py, line 368, in validate_template 2014-10-30 10:07:44.749 30476 TRACE root ResourceClass = resource.get_class(res['Type']) 2014-10-30 10:07:44.749 30476 TRACE root 2014-10-30 10:07:44.749 30476 TRACE root File /usr/lib/python2.7/dist-packages/heat/engine/resource.py, line 45, in get_class 2014-10-30 10:07:44.749 30476 TRACE root return resources.global_env().get_class(resource_type, resource_name) 2014-10-30 10:07:44.749 30476 TRACE root 2014-10-30 10:07:44.749 30476 TRACE root File /usr/lib/python2.7/dist-packages/heat/engine/environment.py, line 326, in get_class 2014-10-30 10:07:44.749 30476 TRACE root return self.registry.get_class(resource_type, resource_name) 2014-10-30 10:07:44.749 30476 TRACE root 2014-10-30 10:07:44.749 30476 TRACE root File /usr/lib/python2.7/dist-packages/heat/engine/environment.py, line 257, in get_class 2014-10-30 10:07:44.749 30476 TRACE root raise exception.StackValidationFailed(message=msg) 2014-10-30 10:07:44.749 30476 TRACE root 2014-10-30 10:07:44.749 30476 TRACE root StackValidationFailed: Unknown resource Type : OS::Heat::AutoScalingGroup 2014-10-30 10:07:44.749 30476 TRACE root Why is it not supporting OS::Heat::AutoScalingGroup resource_type, Should I move to Icehouse or Junos to get it fixed? Or there is some other reason? Thanks in advance for any hint or suggestions. David On Wed, Oct 29, 2014 at 3:56 PM, Steven Hardy sha...@redhat.com wrote: On Wed, Oct 29, 2014 at 03:19:49PM +0500, david jhon wrote: Hi, I am using all-in-one Havana on Ubuntu 12.04 LTS, working on Ceilometer and Heat. I want to launch an instance based on a threshold defined in alarm. My question is where and how am I supposed to define the webhook URL for --alarm-actions argument. I am creating threshold alarm with the following command: ceilometer -k alarm-threshold-create --name tester_cpu_high --description 'instance_too_high' --meter-name cpu_util --threshold 20.0 --comparison-operator ge --statistic avg --period 30 --evaluation-periods 1 --query resource_id=bd4ec331-dfc5-4a75-b928-6d0988dfc369 Hi, you may want to use the general mailing list for future usage questions like this, as it's not really related to development: https://wiki.openstack.org/wiki/Mailing_Lists#General_List The answer to your question is you must create the alarm inside your heat template, and reference a resource which provides a pre-signed URL, such as a ScalingPolicy resource. Here's an example template: https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml#L121 If you really want to create the alarm via the ceilometer CLI for testing, you'll need to expose the URL of the ScalingPolicy via a stack output, like this: https://github.com/openstack/heat-templates/blob/master/hot/asg_of_servers.yaml#L78 And get the output URL via heat stack-show stack name Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev scaleup.yaml Description: application/yaml ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Finalizing cross-project design summit track
Thanks for your confirmation. Best Regards Chaoyi Huang ( joehuang ) From: Thierry Carrez [thie...@openstack.org] Sent: 29 October 2014 16:55 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [All] Finalizing cross-project design summit track joehuang wrote: Is the cascading included in the session Approaches for scaling out [1] ? Yes it is. The goal of the session is to get the proponents of the various scaling out approaches in the same room so that they compare notes and potentially converge. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading
Hello, Keshava, Wu described the simplified pictures of cascading as following, if you attend Paris summit, you can join the cross-project design summit session approached for scaling out, cascading will also be discussed in this session, we can have f2f talk in more detail. Best Regards Chaoyi Hunag ( joehuang ) From: Wuhongning [wuhongn...@huawei.com] Sent: 30 October 2014 10:25 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hi keshava, Thanks for interested in Cascading. Here are some very simple explanation: Basically Datacenter is not in the 2-level tree of cascading. We use term POD to represent a cascaded child openstack (same meaning of your term Zone?). There may be single or multiple PODs in one Datacenter, Just like below: (A, B, C) ... (D, E) ... (F) ... (G) Each character represent a POD or child openstack, while parenthesis represent a Datacenter. Each POD has a corresponding virtual host node in the parent openstack, so when scheduler of any projects (nova/neutron/cinder...) locate a host node, the resource POD is determined, also with its geo-located Datacenter by side effect. Cascading don't schedule by Datacenter directly, DC is just an attribute of POD (for example we can configure host aggregate to identify a DC with multiple PODs). The upper scale of POD is fixed, maybe several hundreds, so a super large DC with tens of thousands servers could be built by modularized PODs, avoiding the difficult of tuning and maintaining such a huge monolithic openstack. Next do you mean networking reachability? Sorry for the limitation of mail post I can just give some very simple idea: in parent openstack the L2pop and DVR is used, so L2/L3 agent-proxy in each virtual host node can get all the vm reachability information of other POD, then they are set to local POD by Neutron REST API. However, cascading depends on some feature not exists yet in current Neutron, like L2GW, pluggable external network, WE Fwaas in DVR, centralized FIP in DVR... so we have to do some little patch in the front. In the future if these features is merged, these patch code can be removed. Indeed Neutron is the most challenge part of cascading, without considering those proxies in the parent openstack virtual host node, Neutron patchs account for 85% or more LOC in the whole project. Regards, Wu From: keshava [keshav...@hp.com] Sent: Wednesday, October 29, 2014 2:22 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading This is very interesting problem to solve. I am curious to know how the reachability is provided across different Datacenter. How to know which VM is part of which Datacenter? VM may be in different Zone but under same DC or in different DC itself. How this problem is solved? thanks regards, keshava -- View this message in context: http://openstack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-tp54115p56323.html Sent from the Developer mailing list archive at Nabble.com. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
