Re: [openstack-dev] [heat] Can heat automatically create a flavor as part of stack creation?
In principle yes. You need: - to write a module to orchestrate the nova flavor API. - to configure your policy rules in the cloud in question to let the heat engine user create flavors -Rob On 9 February 2014 20:49, ELISHA, Moshe (Moshe) moshe.eli...@alcatel-lucent.com wrote: Hello, I am wondering if instead of being obligated to use an existing flavor, I could declare a flavor (with its properties) inside Heat template and let Heat create the flavor automatically? Similar to the ability to create networks as part of the template. Thanks. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Gate broken
Thanks for fixing this. From: Qiu Yu unic...@gmail.commailto:unic...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Saturday, February 8, 2014 9:44 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova] Gate broken On Sat, Feb 8, 2014 at 3:29 PM, Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com wrote: Hi, Anyone aware of: It is caused the new boto 2.25 release. Joe Gordon filed a new bug on this[1], and I just submitted a patch [2] to fix. [1] https://bugs.launchpad.net/nova/+bug/1277790https://urldefense.proofpoint.com/v1/url?u=https://bugs.launchpad.net/nova/%2Bbug/1277790k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=vI%2BXgZM0Jp3%2FXnNc6HdXuLiyoSz9X9STn67VyRUuQFE%3D%0As=fd96e0f368b4d139e35c6b7a37c7234dbcb580e81a49fd4fc2b5c5bc95535e0d [2] https://review.openstack.org/#/c/72066/https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/72066/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=vI%2BXgZM0Jp3%2FXnNc6HdXuLiyoSz9X9STn67VyRUuQFE%3D%0As=4eaee74f7d34704dd0e64d6ecbb345ea8f51e1e02cf2532d191d3145d84c1416 Thanks, -- Qiu Yu ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Can heat automatically create a flavor as part of stack creation?
Heat template orchestrates user actions, while management of flavors is typically admin's job (due to their tight link to the physical hardware configuration, unknown to a regular user). Regards, Alex From: ELISHA, Moshe (Moshe) moshe.eli...@alcatel-lucent.com To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org, Date: 09/02/2014 09:54 AM Subject:[openstack-dev] [heat] Can heat automatically create a flavor as part of stack creation? Hello, I am wondering if instead of being obligated to use an existing flavor, I could declare a flavor (with its properties) inside Heat template and let Heat create the flavor automatically? Similar to the ability to create networks as part of the template. 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
Re: [openstack-dev] [Neutron] Interest in discussing vendor plugins for L3 services?
Hi Paul Yes I would be interested in this as I believe its an area we have not got around to so far in Neutron. /Alan From: Paul Michali [mailto:p...@cisco.com] Sent: February-03-14 5:20 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron] Interest in discussing vendor plugins for L3 services? I'd like to see if there is interest in discussing vendor plugins for L3 services. The goal is to strive for consistency across vendor plugins/drivers and across service types (if possible/sensible). Some of this could/should apply to reference drivers as well. I'm thinking about these topics (based on questions I've had on VPNaaS - feel free to add to the list): * How to handle vendor specific validation (e.g. say a vendor has restrictions or added capabilities compared to the reference drivers for attributes). * Providing client feedback (e.g. should help and validation be extended to include vendor capabilities or should it be delegated to server reporting?) * Handling and reporting of errors to the user (e.g. how to indicate to the user that a failure has occurred establishing a IPSec tunnel in device driver?) * Persistence of vendor specific information (e.g. should new tables be used or should/can existing reference tables be extended?). * Provider selection for resources (e.g. should we allow --provider attribute on VPN IPSec policies to have vendor specific policies or should we rely on checks at connection creation for policy compatibility?) * Handling of multiple device drivers per vendor (e.g. have service driver determine which device driver to send RPC requests, or have agent determine what driver requests should go to - say based on the router type) If you have an interest, please reply to me and include some days/times that would be good for you, and I'll send out a notice on the ML of the time/date and we can discuss. Looking to hearing form you! PCM (Paul Michali) MAIL p...@cisco.commailto:p...@cisco.com IRCpcm_ (irc.freenode.nethttp://irc.freenode.net) TW@pmichali GPG key4525ECC253E31A83 Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][ml2] Maintaining support for the Tail-f NCS mech driver in Icehouse
On Feb 6, 2014, at 8:52 AM, Luke Gorrie l...@snabb.co wrote: Howdy! My name is Luke and I'm helping my friends at Tail-f Systems to support Neutron with their NCS [1] product. This went really smoothly for us on the Havana cycle, but lately we're having a harder time with Icehouse. In particular, our attempt to fulfill the 3rd party testing requirements has caused a lot of frustration for the #openstack-infra team around New Year. So I'm writing now to look for a good solution. Our goal for Icehouse is to keep our mechanism driver officially supported. The code already works, and has unit tests to keep it working. The risk we want to avoid is going on the dreaded deprecated list for some other reason, which would confuse our customers. For background, our mechanism driver is about 150 lines of code. It translates each network/port/subnet API call into a REST/JSON notification to an external system. That external system returns HTTP 200 OK. That's about all. It's a pretty trivial program. In December I sat down with Tobbe Tornqvist and we tried to setup Jenkins 3rd party testing. We created a Vagrantfile that spins up an Ubuntu VM, installs Neutron and NCS, and performs integration tests with them connected together. We hooked this into Jenkins with a service account. This went fine to start with, but after Christmas our tests started failing due to random setup issues with 'tox', and the script started making -1 votes. Those -1's created major headaches for the infrastructure team and others upstream, I am sorry to say, and ended up requiring a messy process of manual cleanup, and a public flogging for us on IRC. Bad feeling all around ... And that's where we are today. Now, reviewing the situation, I would love to find a solution that doesn't make us deprecated _and_ doesn't require us to be so deeply hooked into the OpenStack Jenkins infrastructure. Could we, for example, write an accurate emulator for the external system so that the MD code can be tested on OpenStack's own servers? That would suit us very well. It seems like a reasonable request to make given the simplicity of our driver code. So, in general I don’t think this will fly because it’s my understanding the OpenStack servers only test fully open source code. Allowing a third party vendor system to run on the OpenStack servers as part of any functional testing would open an entirely new can of worms here. I would suggest asking this question on #openstack-infra as well for clarity since I don’t see a response on the mailing list yet. Thanks, Kyle Hoping for a simple solution... Cheers, -Luke friends at Tail-f [1] http://blog.ipspace.net/2013/05/tail-f-network-control-system-first.html ___ 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] Support for multiple provider networks with same VLAN segmentation id
On Feb 6, 2014, at 5:24 PM, Vinay Bannai vban...@gmail.com wrote: Hello Folks, We are running into a situation where we are not able to create multiple provider networks with the same VLAN id. We would like to propose a solution to remove this restriction through a configuration option. This approach would not conflict with the present behavior where it is not possible to create multiple provider networks with the same VLAN id. The changes should be minimal and would like to propose it for the next summit. The use case for this need is documented in the blueprint specification. Any feedback or comments are welcome. https://blueprints.launchpad.net/neutron/+spec/duplicate-providernet-vlans Hi Vinay: This problem seems straightforward enough, though currently you are right in that we don’t allow multiple Neutron networks to have the same segmentation ID. I’ve added myself as approver for this BP and look forward to further discussions of this before and during the upcoming Summit! Thanks! Kyle Thanks -- Vinay Bannai Email: vban...@gmail.com Google Voice: 415 938 7576 ___ 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][ceilometer] Removing simple_tenant_usage and os-instance_usage_audit_log from V3 API
On Fri, Feb 7, 2014 at 3:10 PM, Joe Gordon joe.gord...@gmail.com wrote: Hi All, I would like to propose removing the simple_tenant_usage and os-instance_usage_audit_log extensions from the nova V3 API (while keeping them in V2). Both of these are pre ceilometer extensions to generate rudimentary usage information, something that we should be using ceilometer for. +1 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] question about storage policies for Swift
Hi Gil, Thanks for the question. I'll start with a quick status update and encourage anyone interested to participate in the activates listed below as well. IRC is a great place to bring up questions/discussion topics as well: -We're currently tracking outstanding activates on a Trello board at https://trello.com/b/LlvIFIQs/swift-erasure-codes-and-storage-policies -There's no policy code on master right now -All policy code is currently checked in on the feature/EC branch - the majorly of the work is done but there are some patches still in review, and a few still being coded so 100% functionality is not there yet (see Trello for details). -One the policy related items on Trello are merged, John will be determining at what point we merge to master and after that policy work will continue on master and EC work will be isolated on the feature/EC branch -If you grab the feature/EC branch now, you'll get basic functionality of policies, enough to mess around with it - the biggest missing patch (in final review) for evaluation is replication support. Note that one to-do item is on the docs which we'll tackle after wrapping up the last of the required patches that will get us onto master. No single patch right now will provide a good overview as most of the functionality is on the EC branch and the result of several earlier patches. For example, the patch mentioned below, on its own, doesn't define policies - it was put on top of an already functional policy code base to better integrate with diskfile Until that happens, here's some quick hints to help answer your question and hopefully get you, or anyone else, started messing around with them: -Policies is essentially support for multiple object rings. It's an extremely powerful feature for being so simple in concept. John blogged about it here https://swiftstack.com/blog/2014/01/27/openstack-swift-storage-policies/ so I won't spend any time describing how it can be used -To setup policies, you need to do the following: o Define your policies in swift.conf (in etc/swift). Below is a section from swift.conf-sample from the pending replicator patch https://review.openstack.org/#/c/52194/ I use this example because it also includes the 'type' key which is optional but helps to see that some policies will be replication, others can be erasure code (future). # storage policies are defined here and determine various characteristics # about how objects are stored and treated. Policies are specified by name # on a per container basis. The policy index is specified in the section # header and is used internally. Policy 0 is always used for legacy # containers and can be given a name for use in metadata however the ring # file name will always be 'object' for backwards compatibility. The name # is optional for policy 0. A default policy is used when creating new # containers and no policy is specified, any policy can be marked as default. # The 'type' element is optional and if not specified will default to # 'replication' and is important for some services, such as the replicator, # to understand how to process the data. For example purposes, 'replication' # is called out explicitly below. #[storage-policy:0] #name = chicken #type = replication # the following declares a policy called 'turkey' and uses replication by # default, the number of replicas will be determined by how the ring is built. # In this example the 'turkey' policy could have a lower or higher # of # replicas than the 'chicken' policy above. The ring filename will be # 'object-1'. When a new container is created w/o a policy specified, # it will get the 'turkey' policy because it is specified as the default # however if a legacy container is accessed (one created with a pre-policy # version of swift) and no policy is specified, policy 0 will be used (chicken) #[storage-policy:1] #name = turkey #default = yes -After you've defined some policy names, and optional parameters, you need to setup your object rings. The policy defined with :0 maps to the object ring that everyone knows and loves today so create that the same way you would normally and include all of the devices that you want to participate in this policy -Next you need to create an object ring for other policies that you've defined. You create them in the same way you did with the first ring except now you include the policy number (aka index) in the object ring name so it would be object-N where N is the index. For example, to create the ring that corresponds to the turkey policy above: o swift-ring-builder object-1.builder create 18 3 1 and then add the devices to this ring, using the object-1 name, that you want to participate in this policy -To use the new policy simply add the header X-Storage-Policy when creating a container and all
Re: [openstack-dev] [nova][ceilometer] Removing simple_tenant_usage and os-instance_usage_audit_log from V3 API
On 02/09/2014 01:39 PM, Christopher Yeoh wrote: On Fri, Feb 7, 2014 at 3:10 PM, Joe Gordon joe.gord...@gmail.com mailto:joe.gord...@gmail.com wrote: Hi All, I would like to propose removing the simple_tenant_usage and os-instance_usage_audit_log extensions from the nova V3 API (while keeping them in V2). Both of these are pre ceilometer extensions to generate rudimentary usage information, something that we should be using ceilometer for. +1 Sounds reasonable to me. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] User Signup
I've just taken a look at the feedback in the whiteboard. If it's ok, I'd like to take this discussion back to the mailing list. I find the whiteboards somewhat clumsy for discussions. Akihiro Motoki points out that all services should work without the dashboard. Keystone already exposes an API to create new users, so that requirement is already fulfilled, whether there's an intermediate service or not, so I don't really understand this objection. Kieran Spear argues in favour of a separate registration service that Horizon talks to over some sort of RPC interface. He argues that putting Keystone admin credentials on public facing webserver is a security risk. I agree that putting admin credentials on a public web server is a security risk, but I'm not sure why a set of restricted admin credentials that only allow you to create users and tenants is a bigger problem than the credentials for separate registration service that performs the exact same operations? Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ 2014-02-01 18:24 GMT+01:00 Saju M sajup...@gmail.com: Hi folks, Could you please spend 5 minutes on the blueprint https://blueprints.launchpad.net/horizon/+spec/user-registration and add your suggestions in the white board. 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
Re: [openstack-dev] [neutron][ml2] Maintaining support for the Tail-f NCS mech driver in Icehouse
Kyle Mestery wrote: So, in general I don't think this will fly because it's my understanding the OpenStack servers only test fully open source code. Allowing a third party vendor system to run on the OpenStack servers as part of any functional testing would open an entirely new can of worms here. I would suggest asking this question on #openstack-infra as well for clarity since I don't see a response on the mailing list yet. How does the current testing work with any of the hardware drivers? I just read Jay Pipe's excellent blog post [1] on the general setup and function of the CI system, but it only explained the software parts. I could not extrapolate from the article anything about how it works In the context of Neutron drivers that are supposed to configure physical networking hardware or even software components such as Nicira's or PlugGrid's gateways. [1] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [heat] Nominate Jason Dunsmore for heat-core
I would like to nominate Jason Dunsmore for heat-core. His reviews are valuable and prolific, his code contributions have demonstrated a good knowledge of heat internals, and he has endured a sound hazing to get multi-engine into heat. http://russellbryant.net/openstack-stats/heat-reviewers-60.txt http://www.stackalytics.com/?release=icehousemetric=commitsuser_id=jasondunsmore Heat cores, please reply with your vote. cheers ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core
Very +1 Original message From: Steve Baker Date:02/09/2014 4:41 PM (GMT-06:00) To: OpenStack Development Mailing List Subject: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core I would like to nominate Jason Dunsmore for heat-core. His reviews are valuable and prolific, his code contributions have demonstrated a good knowledge of heat internals, and he has endured a sound hazing to get multi-engine into heat. http://russellbryant.net/openstack-stats/heat-reviewers-60.txt http://www.stackalytics.com/?release=icehousemetric=commitsuser_id=jasondunsmore Heat cores, please reply with your vote. cheers ___ 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] [heat] Nominate Jason Dunsmore for heat-core
Curse you Randall for taking first post! +1 Excerpts from Randall Burt's message of 2014-02-09 14:47:39 -0800: Very +1 Original message From: Steve Baker Date:02/09/2014 4:41 PM (GMT-06:00) To: OpenStack Development Mailing List Subject: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core I would like to nominate Jason Dunsmore for heat-core. His reviews are valuable and prolific, his code contributions have demonstrated a good knowledge of heat internals, and he has endured a sound hazing to get multi-engine into heat. http://russellbryant.net/openstack-stats/heat-reviewers-60.txt http://www.stackalytics.com/?release=icehousemetric=commitsuser_id=jasondunsmore Heat cores, please reply with your vote. cheers ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][ml2] Maintaining support for the Tail-f NCS mech driver in Icehouse
On Feb 9, 2014, at 4:10 PM, CARVER, PAUL pc2...@att.com wrote: Kyle Mestery wrote: So, in general I don't think this will fly because it's my understanding the OpenStack servers only test fully open source code. Allowing a third party vendor system to run on the OpenStack servers as part of any functional testing would open an entirely new can of worms here. I would suggest asking this question on #openstack-infra as well for clarity since I don't see a response on the mailing list yet. How does the current testing work with any of the hardware drivers? I just read Jay Pipe's excellent blog post [1] on the general setup and function of the CI system, but it only explained the software parts. I could not extrapolate from the article anything about how it works In the context of Neutron drivers that are supposed to configure physical networking hardware or even software components such as Nicira's or PlugGrid's gateways. Each vendor can control this themselves. Some vendors choose to run Tempest against a virtual environment instead of actual hardware, I suspect. At the end of the day, if it’s testing the requisite functionality, it shouldn’t matter. Thanks, Kyle [1] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/ ___ 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][ml2] Maintaining support for the Tail-f NCS mech driver in Icehouse
On Mon, Feb 10, 2014 at 9:10 AM, CARVER, PAUL pc2...@att.com wrote: Kyle Mestery wrote: So, in general I don't think this will fly because it's my understanding the OpenStack servers only test fully open source code. Allowing a third party vendor system to run on the OpenStack servers as part of any functional testing would open an entirely new can of worms here. I would suggest asking this question on #openstack-infra as well for clarity since I don't see a response on the mailing list yet. How does the current testing work with any of the hardware drivers? I just read Jay Pipe's excellent blog post [1] on the general setup and function of the CI system, but it only explained the software parts. I think the short answer is that most don't test. Hence the drive towards third party CI for these drivers. 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] [heat] Nominate Jason Dunsmore for heat-core
+1 From: Steve Baker [sba...@redhat.com] Sent: Monday, February 10, 2014 8:38 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core I would like to nominate Jason Dunsmore for heat-core. His reviews are valuable and prolific, his code contributions have demonstrated a good knowledge of heat internals, and he has endured a sound hazing to get multi-engine into heat. http://russellbryant.net/openstack-stats/heat-reviewers-60.txt http://www.stackalytics.com/?release=icehousemetric=commitsuser_id=jasondunsmore Heat cores, please reply with your vote. cheers ___ 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] [nova] Possible Hyper-V false CI failures
Hi, I think the hyper-v CI system is sometimes failing with this message incorrectly: This change was unable to be automatically merged with the current state of the repository. Please rebase your change and upload a new patchset. I only mention it because its the second time I've seen it. An example here: https://review.openstack.org/#/c/72197/ The changeset was made off a very fresh git update and there doesn't appear to be any updates merged since then. The last time this error appeared for me the rebase had no conflicts and Jenkins did not have any trouble testing the same patchset that the Hyper-V one failed to merge. Regards, Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Call for Testing: PetiteCloud's support for linux as a Cloud Foundation Layer
PetiteCloud is a Free Open Source and Open Knowledge Cloud Foundation Layer Tool that is designed to make OpenStack more stable and robust. See http://www.petitecloud.org for more details. We have recently added support for Linux (Ubuntu 12.04.3 LTS) as a host, we have had a FreeBSD production machine running PetiteCloud since september internally (there are about 40 or 50 FreeBSD users by our estimate). PetiteCloud 0.2.5 is our first widely usable version (all previous versions ran on FreeBSD). Since we are not Linux experts we have likely done a number of minor things wrong, as far we can tell nothing critical though, in the porting and would like help in tracking them down. -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Support for multiple provider networks with same VLAN segmentation id
On 02/09/2014 12:56 PM, Kyle Mestery wrote: On Feb 6, 2014, at 5:24 PM, Vinay Bannai vban...@gmail.com wrote: Hello Folks, We are running into a situation where we are not able to create multiple provider networks with the same VLAN id. We would like to propose a solution to remove this restriction through a configuration option. This approach would not conflict with the present behavior where it is not possible to create multiple provider networks with the same VLAN id. The changes should be minimal and would like to propose it for the next summit. The use case for this need is documented in the blueprint specification. Any feedback or comments are welcome. https://blueprints.launchpad.net/neutron/+spec/duplicate-providernet-vlans Hi Vinay: This problem seems straightforward enough, though currently you are right in that we don’t allow multiple Neutron networks to have the same segmentation ID. I’ve added myself as approver for this BP and look forward to further discussions of this before and during the upcoming Summit! Multiple networks with network_type of 'vlan' are already allowed to have the same segmentation ID with the ml2, openvswitch, or linuxbridge plugins - the networks just need to have different physical_network names. If they have the same network_type, physical_network, and segmentation_id, they are the same network. What else would distinguish them from each other? Could your use case be addressed by simply using different physical_network names for each rack? This would provide independent spaces of segmentation_ids for each. -Bob Thanks! Kyle Thanks -- Vinay Bannai Email: vban...@gmail.com Google Voice: 415 938 7576 ___ 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] Possible Hyper-V false CI failures
On Sun, 2014-02-09 at 18:17 -0700, Christopher Yeoh wrote: Hi, I think the hyper-v CI system is sometimes failing with this message incorrectly: This change was unable to be automatically merged with the current state of the repository. Please rebase your change and upload a new patchset. I only mention it because its the second time I've seen it. An example here: https://review.openstack.org/#/c/72197/ The changeset was made off a very fresh git update and there doesn't appear to be any updates merged since then. The last time this error appeared for me the rebase had no conflicts and Jenkins did not have any trouble testing the same patchset that the Hyper-V one failed to merge. Yeah, it may not be a rebase issue at all. The problem may be that the failure-message setting on the Zuul pipeline that is being triggered or Jenkins Gerrit trigger plugin is set to the above message, regardless of whether the failure is indeed due to the failure of a rebase... Octavius, is it possible to pastebin your Zuul layout.yaml? Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Possible Hyper-V false CI failures
Hi guys, On 10 Feb 2014, at 03:59 , Jay Pipes jaypi...@gmail.com wrote: On Sun, 2014-02-09 at 18:17 -0700, Christopher Yeoh wrote: Hi, I think the hyper-v CI system is sometimes failing with this message incorrectly: This change was unable to be automatically merged with the current state of the repository. Please rebase your change and upload a new patchset. I only mention it because its the second time I've seen it. An example here: https://review.openstack.org/#/c/72197/ The changeset was made off a very fresh git update and there doesn't appear to be any updates merged since then. The last time this error appeared for me the rebase had no conflicts and Jenkins did not have any trouble testing the same patchset that the Hyper-V one failed to merge. Yeah, it may not be a rebase issue at all. The problem may be that the failure-message setting on the Zuul pipeline that is being triggered or Jenkins Gerrit trigger plugin is set to the above message, regardless of whether the failure is indeed due to the failure of a rebase… Hi guys, looking into this. We had a similar issue some days ago due to a corrupted Nova local git repo, which clearly had nothing to do with a rebase. Checking out what’s going on this time. Octavius, is it possible to pastebin your Zuul layout.yaml? Here’s the zuul layout that we’re using: https://github.com/cloudbase/ci-overcloud-init-scripts/blob/master/zuul_layout.yaml 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] [neutron][ml2] Maintaining support for the Tail-f NCS mech driver in Icehouse
On 02/06/2014 09:52 AM, Luke Gorrie wrote: Howdy! My name is Luke and I'm helping my friends at Tail-f Systems to support Neutron with their NCS [1] product. This went really smoothly for us on the Havana cycle, but lately we're having a harder time with Icehouse. In particular, our attempt to fulfill the 3rd party testing requirements has caused a lot of frustration for the #openstack-infra team around New Year. So I'm writing now to look for a good solution. Our goal for Icehouse is to keep our mechanism driver officially supported. The code already works, and has unit tests to keep it working. The risk we want to avoid is going on the dreaded deprecated list for some other reason, which would confuse our customers. For background, our mechanism driver is about 150 lines of code. It translates each network/port/subnet API call into a REST/JSON notification to an external system. That external system returns HTTP 200 OK. That's about all. It's a pretty trivial program. In December I sat down with Tobbe Tornqvist and we tried to setup Jenkins 3rd party testing. We created a Vagrantfile that spins up an Ubuntu VM, installs Neutron and NCS, and performs integration tests with them connected together. We hooked this into Jenkins with a service account. This went fine to start with, but after Christmas our tests started failing due to random setup issues with 'tox', and the script started making -1 votes. Those -1's created major headaches for the infrastructure team and others upstream, I am sorry to say, and ended up requiring a messy process of manual cleanup, and a public flogging for us on IRC. Bad feeling all around ... The part to keep in mind is that random issues crop up all the time. For us in -infra they are a weekly event, and some weeks they are a daily event. The part that was the most difficult was the lack of responsiveness to our efforts to communicate, to get an acknowledgement from the maintainers that this account was experiencing some issues. Then to get the issues addressed. In the end we failed and had to resort to revoking verify voting permissions for this account. It has become evident through an IRC conversation with Tobbe Tornqvist [0] that the human resources required to stay available to maintain this testing system is an issue. While understanding of the need of different sized companies to make decisions to provide value for their customers, in -infra, we can not lose sight of the fact that our customers are our developers and we need to be responsive to their requirements. We are moving to be able to merge 200 patches a day with our system, by making a commitment to that rate of development as our target, we have to ensure any dependencies for testing also are able to move at a similar pace or at least be responsive to ours. Third-party CI [1] service accounts can still place comments on open reviews even if they lack the ability to set a verify vote (-1/+1), and this can be used to show whether the backend is reliably representing the changes it tests in an effort to build community trust in its results. Your account, Tail-f, can vote on our sandbox repo [2] as a way of testing voting for the system. Thank you, Anita. [0] http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2014-01-10.log timestamp ~ 2014-01-10T14:48:01 [1] https://review.openstack.org/#/admin/groups/270,members [2] http://git.openstack.org/cgit/openstack-dev/sandbox/ And that's where we are today. Now, reviewing the situation, I would love to find a solution that doesn't make us deprecated _and_ doesn't require us to be so deeply hooked into the OpenStack Jenkins infrastructure. Could we, for example, write an accurate emulator for the external system so that the MD code can be tested on OpenStack's own servers? That would suit us very well. It seems like a reasonable request to make given the simplicity of our driver code. Hoping for a simple solution... Cheers, -Luke friends at Tail-f [1] http://blog.ipspace.net/2013/05/tail-f-network-control-system-first.html ___ 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] Policy Issue
Hi, I noticed that the Ceilometer project has no strict policy control, the /etc/ceilometer/policy.json only has one single rule 'context_is_admin', and for each specific resource operation, it will invoke acl.get_limit_to and v2._verify_query_segregation to forbid non-admin role operate other tenant's resources, so normal user has full privilege to CURD all resources in his own tenant, which means it can delete the alarms which is created by other users (verified in deployed Havana environment), this sounds not so good. So, is this loose policy limit designed purposely, or it just a simple implementation for policy? In other core projects (except heat), for i.e. Neutron, policy is very detailed, resource operation policy even can forcus on an attribute. And the verification is not defined in specific operation's code but call a function and it will check the rules defined in policy.json. So, is there any opportunity to implement more strict policy check, for i.e. a normal user can read resources created by other users (to be stricter, may disable this too), but read+write for his own? I'd like to get some help or advise before create a blueprint Thanks ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [gantt] Scheduler sub-group meeting 2/11 - Cancel this week
Let's cancel the meeting this week, some of us (me for sure) will be tied up at the Icehouse mid-cycle meetup. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Using Python-Neutronclient from Python - docstrings needed?
Do you have plans to submit these back upstream? It would be a great first
start, perhaps we could add these as examples underneath the JSON
request/reponse in http://api.openstack.org/api-ref-networking.html
Sean M. Collins
From: Rajdeep Dua [dua_rajd...@yahoo.com]
Sent: Saturday, February 08, 2014 11:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Using Python-Neutronclient from Python -
docstrings needed?
Sean,
We have written a few docs for writing these samples
http://python-api-guide.cfapps.io/content/neutron.html
You can find get the source here https://github.com/rajdeepd/openstack-samples
Thanks
Rajdeep
On Sunday, February 9, 2014 12:57 AM, Collins, Sean
sean_colli...@cable.comcast.com wrote:
Hi,
I was writing a small script yesterday to parse a list of IP blocks and
create security groups and rules, by using python-neutronclient.
To be honest, it was very difficult - even though I have actually
written extensions to Python-Neutronclient for the QoS API.
For those that are trying to use the client from inside their code,
they end up getting zero help as to how to actually call any of the
functions, and what parameters they take.
neutron = client.Client('2.0', auth_url=os.environ['OS_AUTH_URL'],
...tenant_id=os.environ['OS_TENANT_ID'],
...username=os.environ['OS_USERNAME'],
...password=os.environ['OS_PASSWORD'])
help(neutron)
| create_credential = function with_params
|
| create_firewall = function with_params
|
| create_firewall_policy = function with_params
|
| create_firewall_rule = function with_params
|
| create_floatingip = function with_params
|
| create_health_monitor = function with_params
|
| create_ikepolicy = function with_params
|
| create_ipsec_site_connection = function with_params
|
| create_ipsecpolicy = function with_params
|
| create_member = function with_params
|
| create_metering_label = function with_params
Since there was nothing there, I decided to go check the source of
python-neutronclient and see if there are any examples.
https://github.com/openstack/python-neutronclient/blob/master/doc/source/index.rst
If you read closely enough, you'll find out that the function takes a
dictionary, that looks very similar to the request/response examples
listed in the API documentation. So, I went over and checked it out.
http://docs.openstack.org/api/openstack-network/2.0/content/POST_security-groups-v2.0_createSecGroup_v2.0_security-groups_security-groups-ext.html
So from there, I was able to remember enough that each of these
functions takes a single argument, that is a dictionary, that mimics
the same structure that you see in the API documentation, so from there
it was just some experimentation to get the structure right.
Honestly it wasn't easy to remember all this stuff, since
it had been a couple months since I had worked with
python-neutronclient, and it had been from inside the library itself.
This was my first experience using it on the outside and it was pretty
tough - so I'm going to try and look into how we can improve the
docstrings for the client object, to make it a bit easier to figure out.
Thoughts?
--
Sean M. Collins
___
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] [Neutron] Using Python-Neutronclient from Python - docstrings needed?
Yes, We would be interested in doing that.
Please let me know which is the right group/ team for this?
On Monday, February 10, 2014 10:34 AM, Collins, Sean
sean_colli...@cable.comcast.com wrote:
Do you have plans to submit these back upstream? It would be a great first
start, perhaps we could add these as examples underneath the JSON
request/reponse in http://api.openstack.org/api-ref-networking.html
Sean M. Collins
From: Rajdeep Dua [dua_rajd...@yahoo.com]
Sent: Saturday, February 08, 2014 11:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Using Python-Neutronclient from Python -
docstrings needed?
Sean,
We have written a few docs for writing these samples
http://python-api-guide.cfapps.io/content/neutron.html
You can find get the source here https://github.com/rajdeepd/openstack-samples
Thanks
Rajdeep
On Sunday, February 9, 2014 12:57 AM, Collins, Sean
sean_colli...@cable.comcast.com wrote:
Hi,
I was writing a small script yesterday to parse a list of IP blocks and
create security groups and rules, by using python-neutronclient.
To be honest, it was very difficult - even though I have actually
written extensions to Python-Neutronclient for the QoS API.
For those that are trying to use the client from inside their code,
they end up getting zero help as to how to actually call any of the
functions, and what parameters they take.
neutron = client.Client('2.0', auth_url=os.environ['OS_AUTH_URL'],
... tenant_id=os.environ['OS_TENANT_ID'],
... username=os.environ['OS_USERNAME'],
... password=os.environ['OS_PASSWORD'])
help(neutron)
| create_credential = function with_params
|
| create_firewall = function with_params
|
| create_firewall_policy = function with_params
|
| create_firewall_rule = function with_params
|
| create_floatingip = function with_params
|
| create_health_monitor = function with_params
|
| create_ikepolicy = function with_params
|
| create_ipsec_site_connection = function with_params
|
| create_ipsecpolicy = function with_params
|
| create_member = function with_params
|
| create_metering_label = function with_params
Since there was nothing there, I decided to go check the source of
python-neutronclient and see if there are any examples.
https://github.com/openstack/python-neutronclient/blob/master/doc/source/index.rst
If you read closely enough, you'll find out that the function takes a
dictionary, that looks very similar to the request/response examples
listed in the API documentation. So, I went over and checked it out.
http://docs.openstack.org/api/openstack-network/2.0/content/POST_security-groups-v2.0_createSecGroup_v2.0_security-groups_security-groups-ext.html
So from there, I was able to remember enough that each of these
functions takes a single argument, that is a dictionary, that mimics
the same structure that you see in the API documentation, so from there
it was just some experimentation to get the structure right.
Honestly it wasn't easy to remember all this stuff, since
it had been a couple months since I had worked with
python-neutronclient, and it had been from inside the library itself.
This was my first experience using it on the outside and it was pretty
tough - so I'm going to try and look into how we can improve the
docstrings for the client object, to make it a bit easier to figure out.
Thoughts?
--
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] Interest in discussing vendor plugins for L3 services?
I'm interested in it. My timezone is JST(UTC+9). thanks, On Mon, Feb 03, 2014 at 05:19:35PM -0500, Paul Michali p...@cisco.com wrote: I'd like to see if there is interest in discussing vendor plugins for L3 services. The goal is to strive for consistency across vendor plugins/drivers and across service types (if possible/sensible). Some of this could/should apply to reference drivers as well. I'm thinking about these topics (based on questions I've had on VPNaaS - feel free to add to the list): How to handle vendor specific validation (e.g. say a vendor has restrictions or added capabilities compared to the reference drivers for attributes). Providing client feedback (e.g. should help and validation be extended to include vendor capabilities or should it be delegated to server reporting?) Handling and reporting of errors to the user (e.g. how to indicate to the user that a failure has occurred establishing a IPSec tunnel in device driver?) Persistence of vendor specific information (e.g. should new tables be used or should/can existing reference tables be extended?). Provider selection for resources (e.g. should we allow --provider attribute on VPN IPSec policies to have vendor specific policies or should we rely on checks at connection creation for policy compatibility?) Handling of multiple device drivers per vendor (e.g. have service driver determine which device driver to send RPC requests, or have agent determine what driver requests should go to - say based on the router type) If you have an interest, please reply to me and include some days/times that would be good for you, and I'll send out a notice on the ML of the time/date and we can discuss. Looking to hearing form you! PCM (Paul Michali) MAIL p...@cisco.com IRCpcm_ (irc.freenode.net) TW@pmichali GPG key4525ECC253E31A83 Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance][nova]improvement-of-accessing-to-glance
Hi, all, Thanks for your comment. Please let me re-explain. The main purpose of our blueprint is to use network resources more efficiently. To complete this purpose, we suggested the method of using 2 lists. We think, as I wrote before, by listing near glance API servers and using them, the total amount of data transfer across the networks can be reduced. Especially, in case of using microserver, communication destination can be limited within same chassis. In addition, we think we can resume failed server during glance API server on secondary list are used. As a result, we can provide higher availability than current spec. This bp can provide high efficiency and high availability. But it seems you think our idea was not so good. Please let me know your idea which component should be changed. Regards, E.Aikawa (aik...@mxk.nes.nec.co.jp) --Separator@aik...@mxk.nes.nec.co.jp:-Original Message- From: Flavio Percoco [mailto:fla...@redhat.com] Sent: Tuesday, February 04, 2014 4:59 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [glance][nova]improvement-of-accessing-to-glance On 03/02/14 12:44 -0500, Jay Pipes wrote: On Mon, 2014-02-03 at 17:04 +0100, Flavio Percoco wrote: On 03/02/14 10:13 -0500, Jay Pipes wrote: On Mon, 2014-02-03 at 10:03 +0100, Flavio Percoco wrote: IMHO, the bit that should really be optimized is the selection of the store nodes where the image should be downloaded from. That is, selecting the nearest location from the image locations and this is something that perhaps should happen in glance-api, not nova. I disagree. The reason is because glance-api does not know where nova is. Nova does. Nova doesn't know where glance is either. More info is required in order to finally do something smart here. Not sure what the best approach is just yet but as mentioned in my previous email I think focusing on the stores for now is the thing to do. (As you pointed out bellow too). Right, which is why I am recommending to get rid of glance-api below... I continue to think that the best performance gains will come from getting rid of glance-api entirely, putting the block-streaming bits into a separate Python library, and having Nova and Cinder pull image/volume bits directly from backend storage instead of going through the glance middleman. This is exactly what we're doing by pulling glance.store into its own library. I'm working on this myself. We are not completely getting rid of glance-api but we're working on not depending on it to get the image data. Cool. Have you pushed a patch for this I can see? Not to gerrit but I'm hacking on this in my own GH repo first. I'll be submitting that patch soon, hopefully. This is the blueprint[0] for the glance.store work, there you'll find the link to my GH repo! :) [0] https://blueprints.launchpad.net/glance/+spec/create-store-package Thanks, Flavio! Cheers :) Flavio -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Service VM: irc discussion?
As the first patch for service vm framework is ready for review[1][2], it would be a good idea to have IRC meeting. Anyone interested in it? How about schedule? Schedule candidate Monday 22:00UTC-, 23:00UTC- Tuesday 22:00UTC-, 23:00UTC- (Although the slot of servanced service vm[3] can be resuled, it doesn't work for me because my timezone is UTC+9.) topics for - discussion/review on the patch - next steps - other open issues? [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms [2] https://review.openstack.org/#/c/56892/ [3] https://wiki.openstack.org/wiki/Meetings/AdvancedServices -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to write a new neutron L2 plugin using ML2 framework?
On Sat, Feb 08, 2014 at 03:49:46AM +, Yang, Yi Y yi.y.y...@intel.com wrote: Hi, All Hi. I want to write a new neutron L2 plugin using ML2 framework, I noticed openvswitch and linxubridge have been ported into ML2 framework, but it seems many code is removed compared to standalone L2 plugin, I guess some code has been written into a common library. Now I want to write a L2 plugin to enable switch for a SR-IOV 10g NIC, I think I need to write as follows: 1. a new mechanism driver neutron/plugins/ml2/drivers/mech_XXX.py, but from source code, it seems nothing to do. This requires to define how your plugin utilize network. If multi tenant network is wanted, what/how technology will be used. The common one is VLAN or tunneling(GRE, VXLAN). This depends on what feature your NIC supports. 2. a new agent neutron/plugins/XXX/ XXX_neutron_plugin.py After this, an issue it how to let neutron know it and load it by default or by configuration. Debugging is also an issue, nobody can write code correctly once :-), does neutron have any good debugging way for a newbie? LOG.debug and debug middle ware. If there are any other better way, I'd also like to know. thanks, I'm very eager to be able to get your help and sincerely thank you in advance. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Service VM: irc discussion?
Hi Isaku Yamahata, Is it possible to move the below time slot a little earlier like 18.00UTC? Regards, Balaji.P -Original Message- From: i y [mailto:yamahat...@gmail.com] On Behalf Of Isaku Yamahata Sent: Monday, February 10, 2014 11:42 AM To: openstack-dev@lists.openstack.org Cc: isaku.yamah...@gmail.com Subject: [Neutron] Service VM: irc discussion? As the first patch for service vm framework is ready for review[1][2], it would be a good idea to have IRC meeting. Anyone interested in it? How about schedule? Schedule candidate Monday 22:00UTC-, 23:00UTC- Tuesday 22:00UTC-, 23:00UTC- (Although the slot of servanced service vm[3] can be resuled, it doesn't work for me because my timezone is UTC+9.) topics for - discussion/review on the patch - next steps - other open issues? [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms [2] https://review.openstack.org/#/c/56892/ [3] https://wiki.openstack.org/wiki/Meetings/AdvancedServices -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Service VM: irc discussion?
What's your timezone? 18.00UTC doesn't work for me because my timezone is UTC+9 and it's 3:00AM. thanks, On Mon, Feb 10, 2014 at 06:43:05AM +, balaj...@freescale.com balaj...@freescale.com wrote: Hi Isaku Yamahata, Is it possible to move the below time slot a little earlier like 18.00UTC? Regards, Balaji.P -Original Message- From: i y [mailto:yamahat...@gmail.com] On Behalf Of Isaku Yamahata Sent: Monday, February 10, 2014 11:42 AM To: openstack-dev@lists.openstack.org Cc: isaku.yamah...@gmail.com Subject: [Neutron] Service VM: irc discussion? As the first patch for service vm framework is ready for review[1][2], it would be a good idea to have IRC meeting. Anyone interested in it? How about schedule? Schedule candidate Monday 22:00UTC-, 23:00UTC- Tuesday 22:00UTC-, 23:00UTC- (Although the slot of servanced service vm[3] can be resuled, it doesn't work for me because my timezone is UTC+9.) topics for - discussion/review on the patch - next steps - other open issues? [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms [2] https://review.openstack.org/#/c/56892/ [3] https://wiki.openstack.org/wiki/Meetings/AdvancedServices -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Service VM: irc discussion?
Hi Isaku Yamahata, We are at UTC+5.30.[IST] Regards, Balaji.P -Original Message- From: i y [mailto:yamahat...@gmail.com] On Behalf Of Isaku Yamahata Sent: Monday, February 10, 2014 12:36 PM To: P Balaji-B37839; OpenStack Development Mailing List (not for usage questions) Cc: Isaku Yamahata Subject: Re: [openstack-dev] [Neutron] Service VM: irc discussion? What's your timezone? 18.00UTC doesn't work for me because my timezone is UTC+9 and it's 3:00AM. thanks, On Mon, Feb 10, 2014 at 06:43:05AM +, balaj...@freescale.com balaj...@freescale.com wrote: Hi Isaku Yamahata, Is it possible to move the below time slot a little earlier like 18.00UTC? Regards, Balaji.P -Original Message- From: i y [mailto:yamahat...@gmail.com] On Behalf Of Isaku Yamahata Sent: Monday, February 10, 2014 11:42 AM To: openstack-dev@lists.openstack.org Cc: isaku.yamah...@gmail.com Subject: [Neutron] Service VM: irc discussion? As the first patch for service vm framework is ready for review[1][2], it would be a good idea to have IRC meeting. Anyone interested in it? How about schedule? Schedule candidate Monday 22:00UTC-, 23:00UTC- Tuesday 22:00UTC-, 23:00UTC- (Although the slot of servanced service vm[3] can be resuled, it doesn't work for me because my timezone is UTC+9.) topics for - discussion/review on the patch - next steps - other open issues? [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms [2] https://review.openstack.org/#/c/56892/ [3] https://wiki.openstack.org/wiki/Meetings/AdvancedServices -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core
+1 On 02/09/2014 11:38 PM, Steve Baker wrote: I would like to nominate Jason Dunsmore for heat-core. His reviews are valuable and prolific, his code contributions have demonstrated a good knowledge of heat internals, and he has endured a sound hazing to get multi-engine into heat. http://russellbryant.net/openstack-stats/heat-reviewers-60.txt http://www.stackalytics.com/?release=icehousemetric=commitsuser_id=jasondunsmore Heat cores, please reply with your vote. cheers ___ 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] Service VM: irc discussion?
Hi everyone, Is there anyone can kindly tell me how to join your conference? ^^ -邮件原件- 发件人: balaj...@freescale.com [mailto:balaj...@freescale.com] 发送时间: 2014年2月10日 15:11 收件人: Isaku Yamahata; OpenStack Development Mailing List (not for usage questions) 主题: Re: [openstack-dev] [Neutron] Service VM: irc discussion? Hi Isaku Yamahata, We are at UTC+5.30.[IST] Regards, Balaji.P -Original Message- From: i y [mailto:yamahat...@gmail.com] On Behalf Of Isaku Yamahata Sent: Monday, February 10, 2014 12:36 PM To: P Balaji-B37839; OpenStack Development Mailing List (not for usage questions) Cc: Isaku Yamahata Subject: Re: [openstack-dev] [Neutron] Service VM: irc discussion? What's your timezone? 18.00UTC doesn't work for me because my timezone is UTC+9 and it's 3:00AM. thanks, On Mon, Feb 10, 2014 at 06:43:05AM +, balaj...@freescale.com balaj...@freescale.com wrote: Hi Isaku Yamahata, Is it possible to move the below time slot a little earlier like 18.00UTC? Regards, Balaji.P -Original Message- From: i y [mailto:yamahat...@gmail.com] On Behalf Of Isaku Yamahata Sent: Monday, February 10, 2014 11:42 AM To: openstack-dev@lists.openstack.org Cc: isaku.yamah...@gmail.com Subject: [Neutron] Service VM: irc discussion? As the first patch for service vm framework is ready for review[1][2], it would be a good idea to have IRC meeting. Anyone interested in it? How about schedule? Schedule candidate Monday 22:00UTC-, 23:00UTC- Tuesday 22:00UTC-, 23:00UTC- (Although the slot of servanced service vm[3] can be resuled, it doesn't work for me because my timezone is UTC+9.) topics for - discussion/review on the patch - next steps - other open issues? [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms [2] https://review.openstack.org/#/c/56892/ [3] https://wiki.openstack.org/wiki/Meetings/AdvancedServices -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.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
