Re: [openstack-dev] [api] Forming the API Working Group
Hi Everett, Great to see things moving with the API Working Group! On Thu, Oct 9, 2014 at 9:35 AM, Everett Toews everett.to...@rackspace.com wrote: https://wiki.openstack.org/wiki/API_Working_Group This is the start of the API Working Group (API WG). To avoid bike shedding over the name of the working group, I decided to title the wiki page API Working Group. Simple, to the point, and avoids loaded terms like standards, best practices, guidelines, conventions, etc. The point isn’t what we name it. The point is what action we take about it. I propose the deliverables in the API WG wiki page. I agree with what you've written on the wiki page. I think our priority needs to be to flesh out https://wiki.openstack.org/wiki/Governance/Proposed/APIGuidelines so we have something to reference when reviewing specs. At the moment I see that document as something anyone should be able to document a project's API convention even if they conflict with another project for the moment. Once we've got a fair amount of content we can start as a group resolving any conflicts. Speaking of the wiki page, I wrote it very matter-of-factly. As if this is the way things are. They’re not. The wiki page is just a starting point. If something was missed, add it. If something can be improved, improve it. Let’s try to keep it simple though. One problem with API WG members reviewing spec proposals that affect the API is finding the specs in the first place across many different projects repositories. I invite everyone who chimed in on the original thread [1] that kicked this off to add themselves as a member committed to making the OpenStack APIs better. I’ve Cc’d everyone who asked to be kept in the loop. I already see some cross project summit topics [2] on APIs. But frankly, with the number of people committed to this topic, I’d expect there to be more. I encourage everyone to submit more API related sessions with better descriptions and goals about what you want to achieve in those sessions. Yea if there is enough content in the API guidelines then perhaps some time can be spent on working on resolving any conflicts in the document so projects know what direction to head in. Regards, Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] Generic descriptive format for deployment tasks
Hi team, After several discussions i want to propose generic format for describing deployment tasks, this format is expected to cover all tasks (e.g pre-deployment and post-deployment), also it should cover different actions like upgrade/patching action: upload_file id: upload_astute roles: * parameters: input: $.data - this is internal mistral thing timeout: 50 action: tasklib id: generate_keys stages: [pre-deployment] roles: master parameters: timeout: 60 command: generate/keys type: puppet manifest: /etc/puppet/manifests/key_generator.pp action: tasklib id: rsync_puppet stages: [pre-node] requires: [upload_astute] parameters: timeout: 100 command: rsync/stuff type: shell cmd: python rsync.py action: tasklib id: ceph roles: [ceph-osd, ceph-mon] requires: [rsync_puppet] parameters: timeout: 100 command: deployment/ceph type: puppet manifest: /etc/puppet/manifests/ceph.pp action: tasklib id: glance/image roles: [controller, primary-controller] stages: [post-deployment] parameters: timeout: 100 command: deployment/glance/image type: shell cmd: python upload_image.py Let me provide some clarifications: 1. As example, we want to generate keys strictly before deployment, and the 1st way to solve it is to introduce concept of stages, e.g pre-deployment, main, upgrade, post-deployment. Another one would be to use virtual roles and/or virtual tasks like deployment_started, deployment_ended. We need to consider both, but stages it is what we are using now, and i am just trying to generalize and make it data-driven. 2. Another internal thing is roles. As you can see in this configs there is 2 specific keywords for roles: * - means task should be executed on all roles master - task should be only executed on fuel master node All other roles should be entities from fuel. If you know other exceptions - lets discuss them. I would like to ask team for 2 things: 1. Examine approach and ask questions about any specific tasks, in order to test this approach for sanity. 2. If you think that some of the keywords in configuration is not appropriate, lets discuss it. For example we can not agree on term stage, because it is too widely used and basically we need another one. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC Candidacy
confirmed On 10/10/2014 01:52 AM, David Lyle wrote: I would like to announce my candidacy for the Technical Committee. I have been working on OpenStack since the beginning of the Grizzly cycle. I started working on OpenStack as part of HP's Public Cloud effort. I spent two years working to make Horizon work in that scale of environment and making Horizon the user facing interface of HP's Public Cloud. I have served as a Horizon core reviewer since the Havana cycle and I am starting my third release as Horizon PTL. Currently, I am employed by Intel in their Open Source Technology Center. I have been a regular observer of the Technical Committee during my time as PTL. The role of the TC is large and difficult. I appreciate the efforts of all those that have served during that time and I would like to thank them for their dedication. One takeaway from those observations in the very heavy representation on the TC by infrastructure and core services. I think the TC would be benefit from more representation higher up the stack. I think Heat, Horizon, Solum, TripleO have a unique perspective into cross-project issues and the TC would benefit from such representation. In my opinion, the fundamental problems the TC needs to address in the Kilo cycle are handling growth and cross-project alignment. I'll be honest, I don't have a master plan to address these, but I think I'm well equipped and motivated to help develop that plan with other members of the TC. Thanks for your consideration, David Lyle Topic: OpenStack Mission: How do you feel the technical community is doing in meeting the OpenStack Mission? To produce the ubiquitous OpenSource Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable. I think this is a very broad mission. Breadth is not a problem, but there are a few implications in here. One OpenStack needs to be inclusive, to accomplish ubiquity we need to strive to allow deployers to meet their widely varied needs. So we need to support a large ecosystem. The ecosystem around OpenStack is certainly large, but there is a fairly sharp dichotomy between OpenStack and not OpenStack, recognizing larger parts of the ecosystem is important for ecosystem health. As to public vs private and massively scalable aspects, I think we have room for growth. Running a public cloud on OpenStack requires not insignificant changes, and OpenStack has room for improvement on the scalability front. We need greater feedback from the very large deployers to make sure we meet those scalability needs. Topic: Technical Committee Mission: How do you feel the technical committee is doing in meeting the technical committee mission? The Technical Committee (TC) is tasked with providing the technical leadership for OpenStack as a whole (all official programs, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality...), decides on issues affecting multiple programs, forms an ultimate appeals board for technical decisions, and generally has oversight over all the OpenStack project. The technical committee has spent much of the last cycle acting as gate keeper. I would like to see it take a larger role in overall architectural direction in OpenStack. I believe one of the greatest challenges we face is coherency of vision and direction. I think this should be the province of the technical committee to act as an arbitrar and architectural board. I don't hold that overall technical direction is to be dictated by the TC, rather the TC merely helps unify that direction and insures consistency. Obviously this is a herculean task, but I believe OpenStack needs more clearness in direction. Topic: Contributor Motivation: How would you characterize the various facets of contributor motivation? Contributors are motivated to contribute for various reasons. People contribute for personal interest, corporate interest, academic interest, and any mix of all three. Corporate interest covers a lot, from users to operators, vendors to consumers. Many ideas from our great community of diverse contributors helps drive us forward and keeps us honest and progressing. At the end of the day, OpenStack is cloud software that should be usable. We do need to temper the wouldn't it be neat if, with how will this work in real world application ranging from small test clouds to large public clouds. Services should strive
[openstack-dev] [TripleO] prep-source-repos - new tool for managing repos+patchsets?
I've got a new tool, currently called prep-source-repos, that I'd like to set up as a new project. Most of the work was done by adamg and lifeless, with a bit of polish from me to make it ready to be packaged. The tool is something the tripleo-cd-admins have been using to let us deploy a cloud from trunk + unlanded patchsets from Gerrit. It takes a YAML file with a list of repos to clone, then allows for individual gerrit patches to be added on top. It also creates a file with all the DIB_REPO* variables required to have DIB use these local patched repos rather than the upstream repos. This allows us to test out patches - to TripleO tools, but also to any of the other openstack tools we install from source - without needing to wait for them to land. I believe it's something that can be useful in other places as well though: * I think that it could replace http://git.openstack.org/cgit/openstack/tripleo-incubator/tree/scripts/pull-tools as something we use inside TripleO to pull and update the tools we use * In https://review.openstack.org/#/c/118426/ jp_at_hp proposed a simpler tool that applies patches from gerrit to individual repos; I think prep-source-repos solves the need for this as well * At one point I was running Gertty from trunk with a whole bunch of un-landed patches from lifeless and I. To make things easier on myself, I'd pushed my changes to Gerrit as being a big dependency chain, which didn't reflect reality. push-source-repose would make it easy to run Gerrit from upstream trunk + pull in all my unlanded patches, without needed to set up a fake dependency tree. The code is currently sitting at https://github.com/jamezpolley/prep-source-repos, but I'd like to add it to git.openstack.org, (probably as a stackforge project) if there's consensus that this is something we'd find useful. So, right now, I've got two questions for the team: * Can you think of a better name? prep-source-repos sounds a bit clumsy to me, but I haven't been able to come up with anything I like better. * Am I wrong in thinking that this tool is useful enough to be worth splitting out into its own repo? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Voting for the TC Election is now open
Voting for the TC Election is now open and will remain open until after 1300 utc October 17 2014. We are electing 6 positions from a pool of 12 candidates[0]. When you receive your email providing you your link to your voting opportunity, follow the instructions that are available on the page where you may vote. If you are confused and need more instruction, close the webpage without submitting your vote and then email myself and Tristan[1]. Your ballot will still be enabled to vote until the election is closed, as long as you don't submit your ballot before your close your webpage. We are selecting 6 TC members, please rank all candidates in your order of preference. You are eligible to vote if are a Foundation individual member[2] that also has committed to one of the official programs projects[3] over the Icehouse-Juno timeframe (September 26, 2013 06:00 UTC to September 26, 2014 05:59 UTC) Or if you are one of the extra-atcs.[4] What to do if you don't see the email and have a commit in at least one of the official programs projects[3]: * check the trash of your gerrit Preferred Email address[5], in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from the program project repos[3] and email me and Tristan[1]. If we can confirm that you are entitled to vote, we will add you to the voters list and you will be emailed a ballot. Our democratic process is important to the health of OpenStack, please exercise your right to vote. Candidate statements/platforms can be found linked to Candidate names on this page: https://wiki.openstack.org/wiki/TC_Elections_October_2014#Candidates Happy voting, Anita. (anteaya) [0] https://wiki.openstack.org/wiki/TC_Elections_October_2014#Confirmed_Candidates [1] Anita: anteaya at anteaya dot info Tristan: tristan dot cacqueray at enovance dot com [2] http://www.openstack.org/community/members/ [3] http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml?id=sept-2014-elections [4] http://git.openstack.org/cgit/openstack/governance/tree/reference/extra-atcs?id=sept-2014-elections [5] Sign into review.openstack.org: Go to Settings Contact Information. Look at the email listed as your Preferred Email. That is where the ballot has been sent. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova][oslo] how to sync oslo.concurrency to nova?
There used to method in oslo-incubator like https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator or ' https://review.openstack.org/#/c/78429/ ' we can use however, I was told to submit patch to oslo.concurrency instead of oslo-incubator, so what's the method can be used now ? Thanks a lot 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___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] what happened to ModularL2Agent?
Hi, In the Juno cycle there is proposal of ModularL2Agent [1,2], which is very useful to develop agent for new backend with much less redundant code. Without that, we have to either fork a new agent by copying large amount of existing l2agent code, or patch existing l2agent. However in the K pad [3] it seems that this feature disappeared? Now there are some interest on hybrid backend (e.g. Hierachical Binding), and some BPs are proposed to patch OVS agent. But it has two drawbacks: 1) tightly coupled with OVS; 2) OVS agent became unnecessarily heavier. With ML2agent we only need to add separated driver modules in the common L2agent framework, but not to patch the monolithic ovs agent. Also if it is convenient to write only modules but not the whole agent, backend providers may prefer to move out most of the logic from MD to agent side driver, for better stability for Neutron controller node and easier co-existing with other backend. Ofagent shows good compatibility of l2pop to build vxlan/gre tunnel network between itself and other ovs/linuxbridge agent. Or are there any general consideration about Neutron agent side consolidation, either L2/L3/L4-7？ 1. https://wiki.openstack.org/wiki/Neutron/ModularL2Agent#Possible_Directions 2. https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent 3. https://etherpad.openstack.org/p/kilo-neutron-summit-topics Best Regards Wu ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] Juno RC2 available
Hello everyone, Due to a number of issues discovered in the published Nova 2014.2 RC1 (including a security regression during the Juno development cycle), we generated a new Juno release candidate. You can find the list of bugfixes in this RC and a link to a source tarball at: https://launchpad.net/nova/juno/juno-rc2 Unless new release-critical issues are found that warrant a release candidate respin, this RC2 will be formally released as Nova 2014.2 on October 16. You are therefore strongly encouraged to test and validate this tarball ! Alternatively, you can directly test the proposed/juno branch at: https://github.com/openstack/nova/tree/proposed/juno If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/nova/+filebug and tag it *juno-rc-potential* to bring it to the release crew's attention. Regards, -- 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] [Fuel] Let's remove fuelweb from repo paths
I do not have any objections about removing legacy fuelweb suffix from our repo URLs. So I am +1 here. On Wed, Oct 8, 2014 at 9:08 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi fuelers, I'm going to propose you remove fuelweb word from repos' paths. What am I talking about? Let me show you. Currently we have the following paths to repos: /var/www/nailgun/2014.2-6.0/centos/fuelweb/x86_64/ /var/www/nailgun/2014.2-6.0/ubuntu/fuelweb/x86_64/ Obviously, the word fuelweb is redundant here and doesn't reflect reality, because our repos contain not only fuel packages, but openstack. Moreover, fuel-upgrade script installs repos without that word (fuelweb, I mean) so we have inconsistent file structure for repos, which may lead to problems in future. So I propose to do it now, while we can do it without risks and safety. I prepared a set of patches https://review.openstack.org/#/c/126885/ https://review.openstack.org/#/c/126886/ https://review.openstack.org/#/c/126887/ and built an ISO #508 [1] - both master node and centos cluster was deployed successfully. Folks, please, take a look over patches above and let's merge it. Thanks, Igor [1]: http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_master_iso/508/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Let's remove fuelweb from repo paths
+1. It was a legacy item and it should go away. I'll review the patches. On Wed, Oct 8, 2014 at 9:08 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi fuelers, I'm going to propose you remove fuelweb word from repos' paths. What am I talking about? Let me show you. Currently we have the following paths to repos: /var/www/nailgun/2014.2-6.0/centos/fuelweb/x86_64/ /var/www/nailgun/2014.2-6.0/ubuntu/fuelweb/x86_64/ Obviously, the word fuelweb is redundant here and doesn't reflect reality, because our repos contain not only fuel packages, but openstack. Moreover, fuel-upgrade script installs repos without that word (fuelweb, I mean) so we have inconsistent file structure for repos, which may lead to problems in future. So I propose to do it now, while we can do it without risks and safety. I prepared a set of patches https://review.openstack.org/#/c/126885/ https://review.openstack.org/#/c/126886/ https://review.openstack.org/#/c/126887/ and built an ISO #508 [1] - both master node and centos cluster was deployed successfully. Folks, please, take a look over patches above and let's merge it. Thanks, Igor [1]: http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_master_iso/508/ ___ 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] [Fuel] Let's remove fuelweb from repo paths
I have no objections, and essentially I'm for such initiatives at the beginning of development cycle, when risks are lower. If we ensure tests coverage, and do it carefully (for instance, building custom ISO with changes and making sure it passes BVTs), then let's do it. On Wed, Oct 8, 2014 at 9:08 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi fuelers, I'm going to propose you remove fuelweb word from repos' paths. What am I talking about? Let me show you. Currently we have the following paths to repos: /var/www/nailgun/2014.2-6.0/centos/fuelweb/x86_64/ /var/www/nailgun/2014.2-6.0/ubuntu/fuelweb/x86_64/ Obviously, the word fuelweb is redundant here and doesn't reflect reality, because our repos contain not only fuel packages, but openstack. Moreover, fuel-upgrade script installs repos without that word (fuelweb, I mean) so we have inconsistent file structure for repos, which may lead to problems in future. So I propose to do it now, while we can do it without risks and safety. I prepared a set of patches https://review.openstack.org/#/c/126885/ https://review.openstack.org/#/c/126886/ https://review.openstack.org/#/c/126887/ and built an ISO #508 [1] - both master node and centos cluster was deployed successfully. Folks, please, take a look over patches above and let's merge it. Thanks, Igor [1]: http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_master_iso/508/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project
Hi, Fuelers As you may have noticed our project is growing continuously. And this imposes a requirement of increasing amount of core reviewers. I would like to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core reviewers. As you know, they have been participating actively in development, design and code review of the majority of project components as long as being our topmost reviewers and contributors (#2 and #3) [1 and 2] (not to mention being just brilliant engineers and nice people). Please, reply to my message if you agree or disagree separately for Bogdan and Sergii (this is mandatory for existing core-reviewers). [1] http://stackalytics.com/report/contribution/fuel-library/90 http://stackalytics.com/?project_type=stackforgemodule=fuel-library [2] http://stackalytics.com/report/contribution/fuel-library/180 http://stackalytics.com/?project_type=stackforgemodule=fuel-library -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Generic descriptive format for deployment tasks
Hi, Dmitry 1) In my opinion, we should not have any hardcoded stages in task list. These should be virtual roles, that you can use as a vertex in dependency graph to aggregate and group tasks. Just like it is done in puppet with anchors. Also, we may need to look into some meta-data related approach, e.g. using tagging of tasks, nodes and roles. For example, we could mark rabbitmq, pacemaker and galera installation with ha tags and then use this tag when specifying dependency for other tasks. 2) Also, we need to use generic approach for dependencies specification: before and after for tasks. There is no need to use integer values for priorities, as all we need to do is just provide an ordered set of tasks - there is no need for particular numeric values. 3) Regarding roles - role is just an aggregational entity that combines several tasks 4) Regarding dependency and role keywords: I think, we need to look into some kind of query language that can satisfy our requirements. E.g., I can easily imagine a usecase when we need to do some dynamical calculation of nodes on which to execute the particular task. I think, we could look into Mistral and Murano projects doing some of the similar stuff and decide whether their approach fits our needs. As an example, we may need to exclude the node being added from a particular set of tasks. Imagine, we just added a controller. After we deployed it, all we need is to just update several configs on the nodes and restart/reload particular services, e.g. haproxy on controllers and nova-compute services on the computes. In this case, you will need to tag a node with, let's say new-node tag and then exclude it from execution list by using something like !tags.include(new-node) On Fri, Oct 10, 2014 at 10:21 AM, Dmitriy Shulyak dshul...@mirantis.com wrote: Hi team, After several discussions i want to propose generic format for describing deployment tasks, this format is expected to cover all tasks (e.g pre-deployment and post-deployment), also it should cover different actions like upgrade/patching action: upload_file id: upload_astute roles: * parameters: input: $.data - this is internal mistral thing timeout: 50 action: tasklib id: generate_keys stages: [pre-deployment] roles: master parameters: timeout: 60 command: generate/keys type: puppet manifest: /etc/puppet/manifests/key_generator.pp action: tasklib id: rsync_puppet stages: [pre-node] requires: [upload_astute] parameters: timeout: 100 command: rsync/stuff type: shell cmd: python rsync.py action: tasklib id: ceph roles: [ceph-osd, ceph-mon] requires: [rsync_puppet] parameters: timeout: 100 command: deployment/ceph type: puppet manifest: /etc/puppet/manifests/ceph.pp action: tasklib id: glance/image roles: [controller, primary-controller] stages: [post-deployment] parameters: timeout: 100 command: deployment/glance/image type: shell cmd: python upload_image.py Let me provide some clarifications: 1. As example, we want to generate keys strictly before deployment, and the 1st way to solve it is to introduce concept of stages, e.g pre-deployment, main, upgrade, post-deployment. Another one would be to use virtual roles and/or virtual tasks like deployment_started, deployment_ended. We need to consider both, but stages it is what we are using now, and i am just trying to generalize and make it data-driven. 2. Another internal thing is roles. As you can see in this configs there is 2 specific keywords for roles: * - means task should be executed on all roles master - task should be only executed on fuel master node All other roles should be entities from fuel. If you know other exceptions - lets discuss them. I would like to ask team for 2 things: 1. Examine approach and ask questions about any specific tasks, in order to test this approach for sanity. 2. If you think that some of the keywords in configuration is not appropriate, lets discuss it. For example we can not agree on term stage, because it is too widely used and basically we need another one. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Murano] Juno RC2 available
We had to release RC2 to address an issue blocking the inclusion of Murano Dashboard in Debian experimental packages. Tarballs with RC2 are available at: https://launchpad.net/murano/juno/juno-rc2 Thanks, Ruslan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Let's remove fuelweb from repo paths
As I mentioned early, I already have an ISO with patches and it works fine in my own deployment. However, I ran the BVT tests on centos [1] and ubuntu [2]. [1]: http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom.centos.bvt_1/198/ [2]: http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom.ubuntu.bvt_2/170/ On Fri, Oct 10, 2014 at 12:25 PM, Mike Scherbakov mscherba...@mirantis.com wrote: I have no objections, and essentially I'm for such initiatives at the beginning of development cycle, when risks are lower. If we ensure tests coverage, and do it carefully (for instance, building custom ISO with changes and making sure it passes BVTs), then let's do it. On Wed, Oct 8, 2014 at 9:08 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi fuelers, I'm going to propose you remove fuelweb word from repos' paths. What am I talking about? Let me show you. Currently we have the following paths to repos: /var/www/nailgun/2014.2-6.0/centos/fuelweb/x86_64/ /var/www/nailgun/2014.2-6.0/ubuntu/fuelweb/x86_64/ Obviously, the word fuelweb is redundant here and doesn't reflect reality, because our repos contain not only fuel packages, but openstack. Moreover, fuel-upgrade script installs repos without that word (fuelweb, I mean) so we have inconsistent file structure for repos, which may lead to problems in future. So I propose to do it now, while we can do it without risks and safety. I prepared a set of patches https://review.openstack.org/#/c/126885/ https://review.openstack.org/#/c/126886/ https://review.openstack.org/#/c/126887/ and built an ISO #508 [1] - both master node and centos cluster was deployed successfully. Folks, please, take a look over patches above and let's merge it. Thanks, Igor [1]: http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_master_iso/508/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ 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] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project
+1 for both. On Fri, Oct 10, 2014 at 1:35 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Fuelers As you may have noticed our project is growing continuously. And this imposes a requirement of increasing amount of core reviewers. I would like to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core reviewers. As you know, they have been participating actively in development, design and code review of the majority of project components as long as being our topmost reviewers and contributors (#2 and #3) [1 and 2] (not to mention being just brilliant engineers and nice people). Please, reply to my message if you agree or disagree separately for Bogdan and Sergii (this is mandatory for existing core-reviewers). [1] http://stackalytics.com/report/contribution/fuel-library/90 http://stackalytics.com/?project_type=stackforgemodule=fuel-library [2] http://stackalytics.com/report/contribution/fuel-library/180 http://stackalytics.com/?project_type=stackforgemodule=fuel-library -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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] [Nova][oslo] how to sync oslo.concurrency to nova?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/10/14 10:32, Chen CH Ji wrote: There used to method in oslo-incubator like https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator or '_https://review.openstack.org/#/c/78429/_ ' we can use however, I was told to submit patch to oslo.concurrency instead of oslo-incubator, so what's the method can be used now ? Thanks a lot With oslo.concurrency, you don't copy-paste code, you just reuse it as any other third-party library. So if your project is not yet using the library, just port it to it first, and once a new version of oslo.concurrency is released, you will get your change magically applied. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUN69RAAoJEC5aWaUY1u57sEEH/0q2HxdZkMKNDT+99hZWyyP7 qgeV77UKQ8bHNHVvMVW8vwSqemJVbJwTLrZxPkm4GodwdpF4voXeN1QdA8srU9a2 2DiAdzyrZLlUINpezXKmqOIqNYBg4uxwVCBNgShCM1ViHZkBuViG9c1dNiKyl5e/ 97AJSGV8NXa3mmlOpJJZ2KkfUCaMHo0KbBTSsdAa/td2a17IzpYl80BQB6zrtytB Ou0hYyD/rCVdekcg9ZbyR0DDO6gZR7EGHMzLoM+pWgLQ6+JAlnsaxxUR1ACLO51+ w65IYIArBZpVFyJFnHy/WiPpqitUBiHceXcykdlBFFpTnRe2SN+Ks4U5x+9QnSM= =/Y4a -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] Can sqlalchemy-migrate-core just be oslo.db core?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/10/14 23:44, Doug Hellmann wrote: On Oct 9, 2014, at 4:30 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: The sqlalchemy-migrate project is basically maintenance mode and the core team [1] is kind of a weird mix of people - all great people I'm sure, but I think it's more a team of people that stepped up when OpenStack took over the project and said they'd babysit it but it's pretty idle. Given we have oslo.db now, and sqlalchemy-migrate is all DB goodies, can we just have the oslo.db core team [2] own sqlalchemy-migrate now too? Here are the sqlalchemy-migrate open reviews: https://review.openstack.org/#/q/status:open+project:stackforge/sqlalchemy-migrate,n,z [1] https://review.openstack.org/#/admin/groups/186,members [2] https://review.openstack.org/#/admin/groups/331,members If the oslo.db team wants to participate, that’s obviously fine, but I don’t think we want to just add everyone in bulk. AIUI, the team’s goal is to get the migration stuff in oslo.db working with alembic so we can stop using sqlalchemy-migrate. Till that time, we're left with the library used by multiple projects. I feel it's hard to get any review in meaningful time for the library, so if moving the library under the oslo.db tent will help it move, I'm both hands for that. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUN7B4AAoJEC5aWaUY1u57JLIH/jn9iREgmRhvfiZosiN9knxV xrVFgEpZ35G5kGmWrnnnKvbWUIvIawwoA2OCOCMXScL5xwzLtn9+prvcujvGK3g1 /zk1aVKnKv90zR6j0ATgTq49tQQpVVe1KkaePzWRYIkU22f7KAPGmwjQlLfebV06 bWOS5HyUeueAIno67EVY3AM669JtKmS6ZqswIciEfMvsOmdDDrDje1qVUH9VVsoy UkvOQ+CPCTqwjIpbkbDrfIXJpA5qm0cCwPx8wDoYnEUN7laGjTtV0JMwGKwjBti0 y4ubs0X5xOU2ayr7xJXbeHCSB5eZKVZesbDyOCCk+lIaldih3qN6AR+Snncwjy4= =Ex7c -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] [oslo] Proposed database connectivity patterns
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/10/14 21:29, Mike Bayer wrote: So so far, everyone seems really positive and psyched about the proposal. It looks like providing some options for how to use would be best, that is provide decorators and context managers. Now the thing with the context manager, it can be as I stated: with sql.reader() as session: or we can even have that accept the “context”: with sql.reader(context) as session: The latter again avoids having to use thread locals. But can I get a feel for how comfortable we are with using thread local storage to implement this feature? I had anticipated people wouldn’t like it because it’s kind of a “global” object, even though it will be hidden behind this facade (of course CONF is global as is sys.modules, and I think it is fine). If I just use a tlocal, this whole thing is pretty simple. Won't the approach conflict with eventlet consumers that for some reason do not patch thread module, or do not patch it early enough? I guess in that case we may end up with mixed contexts. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUN7FeAAoJEC5aWaUY1u57sq0IANSM8gKCQZbgEY62uvyhZqzN 9gRDcFbTrH/yUNMv0tt3+e2vVEbn8VIatDWG4/OYghzuI1BerKzhP7JD5J+mV8yK sB0fc6ybHmz14T962LhFkAxWKybPW3sJO/0GIy606ty0OEV8QAgPwaYvjW596MUa BAp0IRAz4/MglT/M80OkT2jFdMV+a9SAFUKvnF/21KSGo/t4qcawA/+B0c3Ownle eYt+Auk3hcgJnZAvCOwy7bcAb1b12gonk4nIwMl/Mik8IKNR5fnl1IqTiISUO2Jw PV95/7muukSrt54lY+9u4SW9o/Zf/gaNCMmK3xfDmvMug6tk0SWzkzBZLva3wNc= =04Wx -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] [neutron] what happened to ModularL2Agent?
Comments inline. Salvatore On 10 October 2014 11:02, Wuhongning wuhongn...@huawei.com wrote: Hi, In the Juno cycle there is proposal of ModularL2Agent [1,2], which is very useful to develop agent for new backend with much less redundant code. Without that, we have to either fork a new agent by copying large amount of existing l2agent code, or patch existing l2agent. However in the K pad [3] it seems that this feature disappeared? The fact that the topic is not present in the Kilo summit discussion does not mean that the related work item has been tabled. It just means that it's not something we'll probably discuss at the summit, mostly because the discussion can happen on the mailing list - as you're doing now. I think a summit session should be granted if the community still needs to achieve consensus on the technical direction or if the topic is of such a paramount importance that awareness needs to be raised. The blueprint and spec for this topic are available ad [1] and [2], and afaict are still active. Now there are some interest on hybrid backend (e.g. Hierachical Binding), and some BPs are proposed to patch OVS agent. But it has two drawbacks: 1) tightly coupled with OVS; 2) OVS agent became unnecessarily heavier. With ML2agent we only need to add separated driver modules in the common L2agent framework, but not to patch the monolithic ovs agent. The point of a modular L2 agent is to have a very efficient RPC interface with the neutron server and a framework for detecting data plane transitions, such as new ports, and apply the corresponding configurations. And then have driver which will apply such configurations to different backends. I reckon the blueprints you are referring to are probably assuming the OVS agent becomes modular - because otherwise it will be hardy able to target backends which are not ovs. Also if it is convenient to write only modules but not the whole agent, backend providers may prefer to move out most of the logic from MD to agent side driver, for better stability for Neutron controller node and easier co-existing with other backend. Ofagent shows good compatibility of l2pop to build vxlan/gre tunnel network between itself and other ovs/linuxbridge agent. Or are there any general consideration about Neutron agent side consolidation, either L2/L3/L4-7？ As far as I know there is no plan for a consolidate neutron agent which does L2/L7 operations. Frankly I do not even think there is any need for it. 1. https://wiki.openstack.org/wiki/Neutron/ModularL2Agent#Possible_Directions 2. https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent 3. https://etherpad.openstack.org/p/kilo-neutron-summit-topics Best Regards Wu ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [1] https://blueprints.launchpad.net/neutron/+spec/modular-l2-agent [2] https://review.openstack.org/#/q/project:openstack/neutron-specs+branch:master+topic:bp/modular-L2-agent,n,z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Let's remove fuelweb from repo paths
Folks, BVT tests are passed successfully. What about merging? Thanks, Igor On Fri, Oct 10, 2014 at 12:40 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: As I mentioned early, I already have an ISO with patches and it works fine in my own deployment. However, I ran the BVT tests on centos [1] and ubuntu [2]. [1]: http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom.centos.bvt_1/198/ [2]: http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom.ubuntu.bvt_2/170/ On Fri, Oct 10, 2014 at 12:25 PM, Mike Scherbakov mscherba...@mirantis.com wrote: I have no objections, and essentially I'm for such initiatives at the beginning of development cycle, when risks are lower. If we ensure tests coverage, and do it carefully (for instance, building custom ISO with changes and making sure it passes BVTs), then let's do it. On Wed, Oct 8, 2014 at 9:08 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi fuelers, I'm going to propose you remove fuelweb word from repos' paths. What am I talking about? Let me show you. Currently we have the following paths to repos: /var/www/nailgun/2014.2-6.0/centos/fuelweb/x86_64/ /var/www/nailgun/2014.2-6.0/ubuntu/fuelweb/x86_64/ Obviously, the word fuelweb is redundant here and doesn't reflect reality, because our repos contain not only fuel packages, but openstack. Moreover, fuel-upgrade script installs repos without that word (fuelweb, I mean) so we have inconsistent file structure for repos, which may lead to problems in future. So I propose to do it now, while we can do it without risks and safety. I prepared a set of patches https://review.openstack.org/#/c/126885/ https://review.openstack.org/#/c/126886/ https://review.openstack.org/#/c/126887/ and built an ISO #508 [1] - both master node and centos cluster was deployed successfully. Folks, please, take a look over patches above and let's merge it. Thanks, Igor [1]: http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_master_iso/508/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ 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] [Neutron] Juno RC2 available
Hello everyone, Due to various issues discovered in the published Neutron 2014.2 RC1, we generated a new Juno release candidate. You can find the list of bugfixes in this RC and a link to a source tarball at: https://launchpad.net/neutron/juno/juno-rc2 Unless new release-critical issues are found that warrant a release candidate respin, this RC2 will be formally released as Neutron 2014.2 on October 16. You are therefore strongly encouraged to test and validate this tarball ! Alternatively, you can directly test the proposed/juno branch at: https://github.com/openstack/neutron/tree/proposed/juno If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/neutron/+filebug and tag it *juno-rc-potential* to bring it to the release crew's attention. Regards, -- 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] [neutron] what happened to ModularL2Agent?
在 2014-10-10，下午7:16，Salvatore Orlando sorla...@nicira.com 写道： Comments inline. Salvatore On 10 October 2014 11:02, Wuhongning wuhongn...@huawei.com wrote: Hi, In the Juno cycle there is proposal of ModularL2Agent [1,2], which is very useful to develop agent for new backend with much less redundant code. Without that, we have to either fork a new agent by copying large amount of existing l2agent code, or patch existing l2agent. However in the K pad [3] it seems that this feature disappeared? The fact that the topic is not present in the Kilo summit discussion does not mean that the related work item has been tabled. It just means that it's not something we'll probably discuss at the summit, mostly because the discussion can happen on the mailing list - as you're doing now. I think a summit session should be granted if the community still needs to achieve consensus on the technical direction or if the topic is of such a paramount importance that awareness needs to be raised. The blueprint and spec for this topic are available ad [1] and [2], and afaict are still active. Now there are some interest on hybrid backend (e.g. Hierachical Binding), and some BPs are proposed to patch OVS agent. But it has two drawbacks: 1) tightly coupled with OVS; 2) OVS agent became unnecessarily heavier. With ML2agent we only need to add separated driver modules in the common L2agent framework, but not to patch the monolithic ovs agent. The point of a modular L2 agent is to have a very efficient RPC interface with the neutron server and a framework for detecting data plane transitions, such as new ports, and apply the corresponding configurations. And then have driver which will apply such configurations to different backends. I reckon the blueprints you are referring to are probably assuming the OVS agent becomes modular - because otherwise it will be hardy able to target backends which are not ovs. Also if it is convenient to write only modules but not the whole agent, backend providers may prefer to move out most of the logic from MD to agent side driver, for better stability for Neutron controller node and easier co-existing with other backend. Ofagent shows good compatibility of l2pop to build vxlan/gre tunnel network between itself and other ovs/linuxbridge agent. Or are there any general consideration about Neutron agent side consolidation, either L2/L3/L4-7？ As far as I know there is no plan for a consolidate neutron agent which does L2/L7 operations. Frankly I do not even think there is any need for it. No necessary consolidation of L2-7, but L2 agent consolidation, L3 agent consolidation, advanced service agent consolidation by each, but all have framework with modular drivers 1. https://wiki.openstack.org/wiki/Neutron/ModularL2Agent#Possible_Directions 2. https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent 3. https://etherpad.openstack.org/p/kilo-neutron-summit-topics Best Regards Wu ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [1] https://blueprints.launchpad.net/neutron/+spec/modular-l2-agent [2] https://review.openstack.org/#/q/project:openstack/neutron-specs+branch:master+topic:bp/modular-L2-agent,n,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
Re: [openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project
Agree for Bogdan and Sergii Aleksey Kasatkin ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Fwd: Unable to install devstack
Hello All, I am new to Openstack and trying to setup Devstack. I am using ubuntu desktop 14.04 as os. I have cloned devstack sucessfully from github.But while installing I am facing error : It gives http error 407 and finally gives unable to download get-pip.py failed. which i found is error due to proxy authentication and all. So I changed my local.config file to give proxy variables. I have already set my apt.conf and environment files. I am attaching my local.config for better understanding. Then i copied both local.config and local.sh from sample to devstack folder as well still no success. I have made changes according to the link: http://www.rushiagr.com/blog/2014/08/05/devstack-behind-proxy/ Here is my terminal output when it fails: http://pastebin.com/hj7Bhmzk Suggestion Please *Shruti Sharma, Final Year, Computer Engineering* *Malaviya National Institute of Technology* local.conf Description: Binary data ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project
+1. On Fri, Oct 10, 2014 at 12:35 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Fuelers As you may have noticed our project is growing continuously. And this imposes a requirement of increasing amount of core reviewers. I would like to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core reviewers. As you know, they have been participating actively in development, design and code review of the majority of project components as long as being our topmost reviewers and contributors (#2 and #3) [1 and 2] (not to mention being just brilliant engineers and nice people). Please, reply to my message if you agree or disagree separately for Bogdan and Sergii (this is mandatory for existing core-reviewers). [1] http://stackalytics.com/report/contribution/fuel-library/90 [2] http://stackalytics.com/report/contribution/fuel-library/180 -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com www.mirantis.ru vkuk...@mirantis.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] [Nova][oslo] how to sync oslo.concurrency to nova?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/10/2014 05:05 AM, Ihar Hrachyshka wrote: On 10/10/14 10:32, Chen CH Ji wrote: There used to method in oslo-incubator like https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator or '_https://review.openstack.org/#/c/78429/_ ' we can use however, I was told to submit patch to oslo.concurrency instead of oslo-incubator, so what's the method can be used now ? Thanks a lot With oslo.concurrency, you don't copy-paste code, you just reuse it as any other third-party library. So if your project is not yet using the library, just port it to it first, and once a new version of oslo.concurrency is released, you will get your change magically applied. At this point oslo.concurrency hasn't been released yet so it won't be possible to switch any projects to use it. I think we're on track for a first release early next week and once that has happened this will be possible. Note that we do have a stable branch of the incubator code that can be used for important changes in projects that haven't yet ported to use new libs, but when possible we'd rather just make the changes in the lib. - -Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUN+bgAAoJEDehGd0Fy7uqjhMIANBPX4sTbVSnewoquF3Ih29z Adxq6KpDymonhpnJuOqM1gKYsd/oyqa6q92WTt9F9c8XwALB1x9IzgUBRRixhts5 p4fDzNTMGJzlT9slnGjyNVD0i3AJ1UuO5+mZADDk3jXqqERmbeCo+BgYqJr7q08r MmkPuo0EAZtWrY1+Isl1Eg3lz7P2DFC9kEmY8iUj5wObiqINU7L5MNCzCi7V+c8g uxacoCSXcyTR7nnXcs9cPywthBTLOOqkY1IzEYk38vbnQSmvqKbbovqVB0ZCTueF 8g/WO2+jOhETsyFGY7d3HuOQDxJSx/JeXlpPfriOsxdcrDtmP3YMEgh2kpK0e7k= =Puy/ -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Unable to install devstack
Hello All, I am new to Openstack and trying to setup Devstack. I am using ubuntu desktop 14.04 as os. I have cloned devstack sucessfully from github.But while installing I am facing error : It gives http error 407 and finally gives unable to download get-pip.py failed. which i found is error due to proxy authentication and all. So I changed my local.config file to give proxy variables. I have already set my apt.conf and environment files. I am attaching my local.config for better understanding. Then i copied both local.config and local.sh from sample to devstack folder as well still no success. I have made changes according to the link: http://www.rushiagr.com/blog/2014/08/05/devstack-behind-proxy/ Here is my terminal output when it fails: http://pastebin.com/hj7Bhmzk Suggestion Please *Shruti Sharma, Final Year, Computer Engineering* *Malaviya National Institute of Technology* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Can sqlalchemy-migrate-core just be oslo.db core?
On Oct 10, 2014, at 6:10 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Signed PGP part On 09/10/14 23:44, Doug Hellmann wrote: On Oct 9, 2014, at 4:30 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: The sqlalchemy-migrate project is basically maintenance mode and the core team [1] is kind of a weird mix of people - all great people I'm sure, but I think it's more a team of people that stepped up when OpenStack took over the project and said they'd babysit it but it's pretty idle. Given we have oslo.db now, and sqlalchemy-migrate is all DB goodies, can we just have the oslo.db core team [2] own sqlalchemy-migrate now too? Here are the sqlalchemy-migrate open reviews: https://review.openstack.org/#/q/status:open+project:stackforge/sqlalchemy-migrate,n,z [1] https://review.openstack.org/#/admin/groups/186,members [2] https://review.openstack.org/#/admin/groups/331,members If the oslo.db team wants to participate, that’s obviously fine, but I don’t think we want to just add everyone in bulk. AIUI, the team’s goal is to get the migration stuff in oslo.db working with alembic so we can stop using sqlalchemy-migrate. Till that time, we're left with the library used by multiple projects. I feel it's hard to get any review in meaningful time for the library, so if moving the library under the oslo.db tent will help it move, I'm both hands for that. It is not generally our community’s practice to assign core responsibility for a code base to anyone, especially without asking. Invite anyone to join the reviewer team, but please do not assume that just because there is a team working on database related code they are also interested in working on this code. Doug /Ihar ___ 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] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project
+1 for both. On Fri, Oct 10, 2014 at 5:01 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: +1. On Fri, Oct 10, 2014 at 12:35 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Fuelers As you may have noticed our project is growing continuously. And this imposes a requirement of increasing amount of core reviewers. I would like to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core reviewers. As you know, they have been participating actively in development, design and code review of the majority of project components as long as being our topmost reviewers and contributors (#2 and #3) [1 and 2] (not to mention being just brilliant engineers and nice people). Please, reply to my message if you agree or disagree separately for Bogdan and Sergii (this is mandatory for existing core-reviewers). [1] http://stackalytics.com/report/contribution/fuel-library/90 [2] http://stackalytics.com/report/contribution/fuel-library/180 -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com www.mirantis.ru vkuk...@mirantis.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
Re: [openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project
+1 On Fri, Oct 10, 2014 at 6:09 PM, Aleksandr Didenko adide...@mirantis.com wrote: +1 for both. On Fri, Oct 10, 2014 at 5:01 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: +1. On Fri, Oct 10, 2014 at 12:35 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Fuelers As you may have noticed our project is growing continuously. And this imposes a requirement of increasing amount of core reviewers. I would like to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core reviewers. As you know, they have been participating actively in development, design and code review of the majority of project components as long as being our topmost reviewers and contributors (#2 and #3) [1 and 2] (not to mention being just brilliant engineers and nice people). Please, reply to my message if you agree or disagree separately for Bogdan and Sergii (this is mandatory for existing core-reviewers). [1] http://stackalytics.com/report/contribution/fuel-library/90 [2] http://stackalytics.com/report/contribution/fuel-library/180 -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com www.mirantis.ru vkuk...@mirantis.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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Unable to install devstack
I’m assuming you’ve verified that your proxy server settings are correct. Try setting GIT_BASE to https://github.com You should be able to manually try the commands. For example, set your proxy env variables and then do: curl -o /home/shruti/devstack/files/get-pip.py https://bootstrap.pypa.io/get-pip.py For my setup (behind a proxy), I set both the upper and lower case proxy env variables: export PROXY_HOST=MY_PROXY_SERVER:80 export http_proxy=http://$PROXY_HOST/ export https_proxy=http://$PROXY_HOST/ export ftp_proxy=http://$PROXY_HOST/ export no_proxy=14.0.3.30,... export HTTP_PROXY=http://$PROXY_HOST/ export HTTPS_PROXY=http://$PROXY_HOST/ export FTP_PROXY=http://$PROXY_HOST/ Maybe overkill.. Regards, PCM (Paul Michali) MAIL …..…. p...@cisco.com IRC ……..… pcm_ (irc.freenode.com) TW ………... @pmichali GPG Key … 4525ECC253E31A83 Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 On Oct 10, 2014, at 9:54 AM, Shruti Sharma shrutisharma0...@gmail.com wrote: Hello All, I am new to Openstack and trying to setup Devstack. I am using ubuntu desktop 14.04 as os. I have cloned devstack sucessfully from github.But while installing I am facing error : It gives http error 407 and finally gives unable to download get-pip.py failed. which i found is error due to proxy authentication and all. So I changed my local.config file to give proxy variables. I have already set my apt.conf and environment files. I am attaching my local.config for better understanding. Then i copied both local.config and local.sh from sample to devstack folder as well still no success. I have made changes according to the link: http://www.rushiagr.com/blog/2014/08/05/devstack-behind-proxy/ Here is my terminal output when it fails: http://pastebin.com/hj7Bhmzk Suggestion Please Shruti Sharma, Final Year, Computer Engineering Malaviya National Institute of Technology local.conf___ 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] [all] [oslo] Proposed database connectivity patterns
On Oct 10, 2014, at 6:13 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Signed PGP part On 09/10/14 21:29, Mike Bayer wrote: So so far, everyone seems really positive and psyched about the proposal. It looks like providing some options for how to use would be best, that is provide decorators and context managers. Now the thing with the context manager, it can be as I stated: with sql.reader() as session: or we can even have that accept the “context”: with sql.reader(context) as session: The latter again avoids having to use thread locals. But can I get a feel for how comfortable we are with using thread local storage to implement this feature? I had anticipated people wouldn’t like it because it’s kind of a “global” object, even though it will be hidden behind this facade (of course CONF is global as is sys.modules, and I think it is fine). If I just use a tlocal, this whole thing is pretty simple. Won't the approach conflict with eventlet consumers that for some reason do not patch thread module, or do not patch it early enough? I guess in that case we may end up with mixed contexts. I’ve been asking a lot about “hey are people cool with thread locals?” and have been waiting for what the concerns are. Since I wrote that email I’ve shifted, and I’ve been considering only: @sql.reader def my_api_method(context, …): context.session def my_api_method(context, …): with sql.using_reader(context) as session: session , context.session because in fact, if you *want* to use a thread local context, you can, explicitly with the above: GLOBAL_CONTEXT = threading.local() def my_api_method(…): with sql.using_reader(GLOBAL_CONTEXT) as session: session I like that one the best. But again, Keystone folks would need to accept this explicitness. The challenge on my end is not technical in any way. It’s getting every project to agree on a single approach and not getting bogged down with idealistics (like, “let’s build a dependency injection framework!”).Because this “everyone does it their own way” thing is crazy and has to stop. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Can sqlalchemy-migrate-core just be oslo.db core?
On 10/10/2014 06:10 PM, Ihar Hrachyshka wrote: On 09/10/14 23:44, Doug Hellmann wrote: On Oct 9, 2014, at 4:30 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: The sqlalchemy-migrate project is basically maintenance mode and the core team [1] is kind of a weird mix of people - all great people I'm sure, but I think it's more a team of people that stepped up when OpenStack took over the project and said they'd babysit it but it's pretty idle. Given we have oslo.db now, and sqlalchemy-migrate is all DB goodies, can we just have the oslo.db core team [2] own sqlalchemy-migrate now too? Here are the sqlalchemy-migrate open reviews: https://review.openstack.org/#/q/status:open+project:stackforge/sqlalchemy-migrate,n,z [1] https://review.openstack.org/#/admin/groups/186,members [2] https://review.openstack.org/#/admin/groups/331,members If the oslo.db team wants to participate, that’s obviously fine, but I don’t think we want to just add everyone in bulk. AIUI, the team’s goal is to get the migration stuff in oslo.db working with alembic so we can stop using sqlalchemy-migrate. Till that time, we're left with the library used by multiple projects. I feel it's hard to get any review in meaningful time for the library, so if moving the library under the oslo.db tent will help it move, I'm both hands for that. /Ihar I'm not sure adding core reviewers would help, but I agree we have a maintenance issue with sqlalchemy-migrate. I've seen useful patches staging without core reviewer answers. I'm myself a core there, but I don't think I have the needed level to do good reviews. Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project
+1 for both On Fri, Oct 10, 2014 at 2:35 AM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Fuelers As you may have noticed our project is growing continuously. And this imposes a requirement of increasing amount of core reviewers. I would like to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core reviewers. As you know, they have been participating actively in development, design and code review of the majority of project components as long as being our topmost reviewers and contributors (#2 and #3) [1 and 2] (not to mention being just brilliant engineers and nice people). Please, reply to my message if you agree or disagree separately for Bogdan and Sergii (this is mandatory for existing core-reviewers). [1] http://stackalytics.com/report/contribution/fuel-library/90 http://stackalytics.com/?project_type=stackforgemodule=fuel-library [2] http://stackalytics.com/report/contribution/fuel-library/180 http://stackalytics.com/?project_type=stackforgemodule=fuel-library -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Dmitry Borodaenko ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project
+1 2014-10-10 16:35 GMT+07:00 Vladimir Kuklin vkuk...@mirantis.com: Hi, Fuelers As you may have noticed our project is growing continuously. And this imposes a requirement of increasing amount of core reviewers. I would like to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core reviewers. As you know, they have been participating actively in development, design and code review of the majority of project components as long as being our topmost reviewers and contributors (#2 and #3) [1 and 2] (not to mention being just brilliant engineers and nice people). Please, reply to my message if you agree or disagree separately for Bogdan and Sergii (this is mandatory for existing core-reviewers). [1] http://stackalytics.com/report/contribution/fuel-library/90 http://stackalytics.com/?project_type=stackforgemodule=fuel-library [2] http://stackalytics.com/report/contribution/fuel-library/180 http://stackalytics.com/?project_type=stackforgemodule=fuel-library -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Vitaly Kramskikh, Software Engineer, Mirantis, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project
+1 for both On Fri, Oct 10, 2014 at 8:05 PM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: +1 2014-10-10 16:35 GMT+07:00 Vladimir Kuklin vkuk...@mirantis.com: Hi, Fuelers As you may have noticed our project is growing continuously. And this imposes a requirement of increasing amount of core reviewers. I would like to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core reviewers. As you know, they have been participating actively in development, design and code review of the majority of project components as long as being our topmost reviewers and contributors (#2 and #3) [1 and 2] (not to mention being just brilliant engineers and nice people). Please, reply to my message if you agree or disagree separately for Bogdan and Sergii (this is mandatory for existing core-reviewers). [1] http://stackalytics.com/report/contribution/fuel-library/90 http://stackalytics.com/?project_type=stackforgemodule=fuel-library [2] http://stackalytics.com/report/contribution/fuel-library/180 http://stackalytics.com/?project_type=stackforgemodule=fuel-library -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Vitaly Kramskikh, Software Engineer, Mirantis, Inc. ___ 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] object field naming question
I think the hyphen question is settled – we can go with hv_type and vm_mode to
be in line with the rest of nova.
Now for the other bit…
After this email thread and discussion in the IRC with those who expressed
interest I have come to the following:
I will use the name supported_hv_specs instead of supported_instances in the
ComputeNode object and HVSpec for the new object. So the field type of
supported_hv_specs will be ListOfObjectsField(‘HVSpec’).
The supported_instances field in the compute_nodes table will be left as it is.
This means that supported_hv_specs in ComputeNodes will map to the
supported_instances field in the compute_nodes table.
Thanks for helping,
Paul
From: Paul Murray [mailto:ptma...@gmail.com]
Sent: 10 October 2014 13:00
To: Murray, Paul (HP Cloud)
Subject: Fwd: [openstack-dev] [Nova] object field naming question
-- Forwarded message --
From: Dan Smith d...@danplanet.commailto:d...@danplanet.com
Date: 9 October 2014 17:40
Subject: Re: [openstack-dev] [Nova] object field naming question
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
The value it adds (and that an underscore would add in hvtype -
hv_type) is that the name would match the naming style for the vast
majority of everything else in OpenStack. See, for examples:
Agreed.
As mentioned in the review, I disagree on this point, since doing a
cleanup afterwards would mean having to increment the
nova.objects.SupportedInstance model VERSION as soon as it went into
master. I say let's make the quick change now and avoid having to write
code like this in the next patchset:
if client_version = (1,0):
# We renamed hvtype to hv_type in 1.1
self.hv_type = fields.get('hvtype')
Right, this becomes RPC debt if we think we might change it later. We
definitely want to get it right the first time whenever possible.
--Dan
___
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] [all] [oslo] Proposed database connectivity patterns
On Oct 10, 2014, at 11:41 AM, Mike Bayer mba...@redhat.com wrote: I’ve been asking a lot about “hey are people cool with thread locals?” and have been waiting for what the concerns are. Since I wrote that email I’ve shifted, and I’ve been considering only: @sql.reader def my_api_method(context, …): context.session def my_api_method(context, …): with sql.using_reader(context) as session: session , context.session because in fact, if you *want* to use a thread local context, you can, explicitly with the above: GLOBAL_CONTEXT = threading.local() def my_api_method(…): with sql.using_reader(GLOBAL_CONTEXT) as session: session I like that one the best. But again, Keystone folks would need to accept this explicitness. The challenge on my end is not technical in any way. It’s getting every project to agree on a single approach and not getting bogged down with idealistics (like, “let’s build a dependency injection framework!”). Because this “everyone does it their own way” thing is crazy and has to stop. I’ve now pushed these changes, as well as a summation of all the alternatives so far, to the latest release. See https://review.openstack.org/#/c/125181/. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][oslo] how to sync oslo.concurrency to nova?
Thanks a lot for the info, So, my understanding is I need to wait for its released then someone need to change the code in projects (e.g. nova) to switch from its original method (nova/openstack/common/) to oslo.concurrency just like we did for oslo.utils and other components nowadays? thanks 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 From: Ben Nemec openst...@nemebean.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 10/10/2014 09:59 PM Subject:Re: [openstack-dev] [Nova][oslo] how to sync oslo.concurrency to nova? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/10/2014 05:05 AM, Ihar Hrachyshka wrote: On 10/10/14 10:32, Chen CH Ji wrote: There used to method in oslo-incubator like https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator or '_https://review.openstack.org/#/c/78429/_ ' we can use however, I was told to submit patch to oslo.concurrency instead of oslo-incubator, so what's the method can be used now ? Thanks a lot With oslo.concurrency, you don't copy-paste code, you just reuse it as any other third-party library. So if your project is not yet using the library, just port it to it first, and once a new version of oslo.concurrency is released, you will get your change magically applied. At this point oslo.concurrency hasn't been released yet so it won't be possible to switch any projects to use it. I think we're on track for a first release early next week and once that has happened this will be possible. Note that we do have a stable branch of the incubator code that can be used for important changes in projects that haven't yet ported to use new libs, but when possible we'd rather just make the changes in the lib. - -Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUN+bgAAoJEDehGd0Fy7uqjhMIANBPX4sTbVSnewoquF3Ih29z Adxq6KpDymonhpnJuOqM1gKYsd/oyqa6q92WTt9F9c8XwALB1x9IzgUBRRixhts5 p4fDzNTMGJzlT9slnGjyNVD0i3AJ1UuO5+mZADDk3jXqqERmbeCo+BgYqJr7q08r MmkPuo0EAZtWrY1+Isl1Eg3lz7P2DFC9kEmY8iUj5wObiqINU7L5MNCzCi7V+c8g uxacoCSXcyTR7nnXcs9cPywthBTLOOqkY1IzEYk38vbnQSmvqKbbovqVB0ZCTueF 8g/WO2+jOhETsyFGY7d3HuOQDxJSx/JeXlpPfriOsxdcrDtmP3YMEgh2kpK0e7k= =Puy/ -END PGP SIGNATURE- ___ 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] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project
+1 for both On Fri, Oct 10, 2014 at 8:09 PM, Anastasia Urlapova aurlap...@mirantis.com wrote: +1 for both On Fri, Oct 10, 2014 at 8:05 PM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: +1 2014-10-10 16:35 GMT+07:00 Vladimir Kuklin vkuk...@mirantis.com: Hi, Fuelers As you may have noticed our project is growing continuously. And this imposes a requirement of increasing amount of core reviewers. I would like to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core reviewers. As you know, they have been participating actively in development, design and code review of the majority of project components as long as being our topmost reviewers and contributors (#2 and #3) [1 and 2] (not to mention being just brilliant engineers and nice people). Please, reply to my message if you agree or disagree separately for Bogdan and Sergii (this is mandatory for existing core-reviewers). [1] http://stackalytics.com/report/contribution/fuel-library/90 http://stackalytics.com/?project_type=stackforgemodule=fuel-library [2] http://stackalytics.com/report/contribution/fuel-library/180 http://stackalytics.com/?project_type=stackforgemodule=fuel-library -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Vitaly Kramskikh, Software Engineer, Mirantis, Inc. ___ 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] [keystone] Using 'admin_token' option as token to create keystone client.
Thanks Lei. On Thu, Oct 9, 2014 at 6:52 PM, Lei Zhang zhang.lei@gmail.com wrote: Yes. That will be more safer. On Fri, Oct 10, 2014 at 12:00 AM, Nader Lahouti nader.laho...@gmail.com wrote: Thanks Lei for the reply and clarification. So, instead of that we can use the following: from keystone client.v2_0 import Client keystone = Client(username=user, password=password, tenant_name=tenant, auth_url=url) with user, password, tenant and url can be obtained from cfg.CONF. Thanks, Nader. On Wed, Oct 8, 2014 at 11:54 PM, Lei Zhang zhang.lei@gmail.com wrote: it should works but it is not safe to use admin_token. Because * It is a admin token which has the full privilege for the keystone service * The token will be always valid till the admin_token in the conf file is changed. It is dangerous when the token leak. Suggest that the admin_token is only used for the initial of admin account. On Thu, Oct 9, 2014 at 2:29 PM, Nader Lahouti nader.laho...@gmail.com wrote: Hi, Is it acceptable to use 'admin_token' option from keystone.conf, when creating a keystone client? something like this: kc = client.Client(token=cfg.CONF.admin_token, endpoint='http://localhost:35357/v2.0/') Thanks, Nader. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Lei Zhang Blog: http://xcodest.me twitter/weibo: @jeffrey4l ___ 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 -- Lei Zhang Blog: http://xcodest.me twitter/weibo: @jeffrey4l ___ 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] RSS feeds for gerrit projects
Is it possible to directly access RSS feeds for gerrit projects or is the only way to do this to use a wrapper like openstackwatch in jeepyb? Christian. -- Christian Berendt Cloud Solution Architect Mail: bere...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Granularity of policies
Eddie, +1 on glance-spec We might want to define the scope. How far are we diverging from Openstack policy structure? Are there any other use cases which need policy changes? - some questions which come to my mind. Thanks, -Nikhil From: Eddie Sheffield [eddie.sheffi...@rackspace.com] Sent: Monday, October 06, 2014 3:35 PM To: OpenStack Dev List Subject: [openstack-dev] [Glance] Granularity of policies I encountered an interesting situation with Glance policies. Basically we have a situation where users in certain roles are not allowed to make certain calls at all. In this specific case, we don't want users in those roles listing or viewing members. When listing members, these users receive a 403 (Forbidden) but when showing an individual member the users receive 404 (Not Found). So the problem is that there are a couple of situations here and we don't (can't?) distinguish the exact intent: 1) A user IS allowed to make the call but isn't allowed to see a particular member - in that case 404 makes sense because a 403 could imply the user actually is there, you just can't look see them directly. 2) A user IS NOT allowed to make the call at all. In this case a 403 makes more sense because the user is forbidden at the call level. At this point I'm mainly trying to spark some conversation on this. This feels a bit inconsistent if users get 403 for a whole set of calls they are barred from but 404 for others which are sub calls of the others (e.g. listing members vs. showing a specific one.) But I don't have a specific proposals at this time - first I'm trying to find out if others feel this is a problem which should be addressed. If so I'm willing to work on a blueprint and implementation. - Eddie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [oslo] Proposed database connectivity patterns
On Oct 10, 2014, at 3:13 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/10/14 21:29, Mike Bayer wrote: So so far, everyone seems really positive and psyched about the proposal. It looks like providing some options for how to use would be best, that is provide decorators and context managers. Now the thing with the context manager, it can be as I stated: with sql.reader() as session: or we can even have that accept the “context”: with sql.reader(context) as session: The latter again avoids having to use thread locals. But can I get a feel for how comfortable we are with using thread local storage to implement this feature? I had anticipated people wouldn’t like it because it’s kind of a “global” object, even though it will be hidden behind this facade (of course CONF is global as is sys.modules, and I think it is fine). If I just use a tlocal, this whole thing is pretty simple. Won't the approach conflict with eventlet consumers that for some reason do not patch thread module, or do not patch it early enough? I guess in that case we may end up with mixed contexts. Eck, this is not something people should be doing (not patching the thread module). Example for why @ https://gist.github.com/harlowja/9c35e443dfa136a4f965 (run that and see your program lock up). Once you accept/use eventlet, u shouldn't really be accepted half of it, otherwise there be dragons there; especially since openstack doesn't control what external library code does inside those libraries (and rightfully so it shouldn't), and if any library does anything like that gist code, the whole application will lock up... /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUN7FeAAoJEC5aWaUY1u57sq0IANSM8gKCQZbgEY62uvyhZqzN 9gRDcFbTrH/yUNMv0tt3+e2vVEbn8VIatDWG4/OYghzuI1BerKzhP7JD5J+mV8yK sB0fc6ybHmz14T962LhFkAxWKybPW3sJO/0GIy606ty0OEV8QAgPwaYvjW596MUa BAp0IRAz4/MglT/M80OkT2jFdMV+a9SAFUKvnF/21KSGo/t4qcawA/+B0c3Ownle eYt+Auk3hcgJnZAvCOwy7bcAb1b12gonk4nIwMl/Mik8IKNR5fnl1IqTiISUO2Jw PV95/7muukSrt54lY+9u4SW9o/Zf/gaNCMmK3xfDmvMug6tk0SWzkzBZLva3wNc= =04Wx -END PGP SIGNATURE- ___ 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] Neutron documentation to update about new vendor plugin, but without code in repository?
Hi, How to include a new vendor plug-in (aka mechanism_driver in ML2 framework) into the Openstack documentation?.. In other words, is it possible to include a new plug-in in the Openstack documentation page without having the actual plug-in code as part of the Openstack neutron repository?... The actual plug-in is posted and available for the public to download as Ubuntu package. But i need to mention somewhere in the Openstack documentation that this new plugin is available for the public to use along with its documentation. Pls. provide some insights into whether it is possible?.. and any further info on this?.. Thanks, Vad -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Neutron documentation to update about new vendor plugin, but without code in repository?
On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan vadivel.openst...@gmail.com wrote: Hi, How to include a new vendor plug-in (aka mechanism_driver in ML2 framework) into the Openstack documentation?.. In other words, is it possible to include a new plug-in in the Openstack documentation page without having the actual plug-in code as part of the Openstack neutron repository?... The actual plug-in is posted and available for the public to download as Ubuntu package. But i need to mention somewhere in the Openstack documentation that this new plugin is available for the public to use along with its documentation. We definitely want you to include pointers to vendor documentation in the OpenStack docs, but I'd prefer make sure they're gate tested before they get listed on docs.openstack.org. Drivers change enough release-to-release that it's difficult to keep up maintenance. Lately I've been talking to driver contributors (hypervisor, storage, networking) about the out-of-tree changes possible. I'd like to encourage even out-of-tree drivers to get listed, but to store their main documents outside of docs.openstack.org, if they are gate-tested. Anyone have other ideas here? Looping in the OpenStack-docs mailing list also. Anne Pls. provide some insights into whether it is possible?.. and any further info on this?.. Thanks, Vad -- ___ 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] [oslo] Proposed database connectivity patterns
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/10/14 20:21, Joshua Harlow wrote: On Oct 10, 2014, at 3:13 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: On 09/10/14 21:29, Mike Bayer wrote: So so far, everyone seems really positive and psyched about the proposal. It looks like providing some options for how to use would be best, that is provide decorators and context managers. Now the thing with the context manager, it can be as I stated: with sql.reader() as session: or we can even have that accept the “context”: with sql.reader(context) as session: The latter again avoids having to use thread locals. But can I get a feel for how comfortable we are with using thread local storage to implement this feature? I had anticipated people wouldn’t like it because it’s kind of a “global” object, even though it will be hidden behind this facade (of course CONF is global as is sys.modules, and I think it is fine). If I just use a tlocal, this whole thing is pretty simple. Won't the approach conflict with eventlet consumers that for some reason do not patch thread module, or do not patch it early enough? I guess in that case we may end up with mixed contexts. Eck, this is not something people should be doing (not patching the thread module). Example for why @ https://gist.github.com/harlowja/9c35e443dfa136a4f965 (run that and see your program lock up). Once you accept/use eventlet, u shouldn't really be accepted half of it, otherwise there be dragons there; especially since openstack doesn't control what external library code does inside those libraries (and rightfully so it shouldn't), and if any library does anything like that gist code, the whole application will lock up... Real life sucks. In Neutron, we have at least two files that patch only some modules (though all of them patch threading). [Not that I mean that those files should not patch the whole library set; I have no defined view on the matter.] Though I agree that consumers with some modules unpatched are not something that should be seriosly considered, we're still left with consumers that do not patch their libraries early enough. We had an issue with tlocal when porting Neutron to oslo.messaging that resulted in the following patch: https://review.openstack.org/#/c/96791/ The issue showed up in very weird way hard to debug, so if possible, I would try to avoid similar situations with oslo.db. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUODkZAAoJEC5aWaUY1u57QrcIANLtMi1jRrfHnwV2xnwYGPOl QwZWDG6i/cdnzqrwGz+0chqRxu4KWZB5gAfMR4/ralHvGGbaa1vGp9wtzsfIJTB1 RuyE7XKXUX4rU3WoAOB7F3uF1WzFpI8ourunBG4OCE0t0YT89z9mCLfOTZNNKGxH OE89n4pnyMd3GXGtoxVINyA6pqQotYuHKG6o6LbhmTZ1UoL3P3rO+Onb1Ma2BF6Z VO84smdMnOC3yVtv4TGwrW5iBoU3RwOqxooOg4g5Jam6D++kzCKrPT9wdY7TNe+C A6IvMlad0RbygkhrLyWIWXaqCAg5VzzDvk4z6dywVkmoWS7V861mjiV4unbr0X8= =5ovh -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] [Nova][oslo] how to sync oslo.concurrency to nova?
On Oct 10, 2014, at 12:36 PM, Chen CH Ji jiche...@cn.ibm.com wrote: Thanks a lot for the info, So, my understanding is I need to wait for its released then someone need to change the code in projects (e.g. nova) to switch from its original method (nova/openstack/common/) to oslo.concurrency just like we did for oslo.utils and other components nowadays? Yes, that’s correct. Doug thanks 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 graycol.gifBen Nemec ---10/10/2014 09:59:16 PMBEGIN PGP SIGNED MESSAGE- Hash: SHA1 From: Ben Nemec openst...@nemebean.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 10/10/2014 09:59 PM Subject: Re: [openstack-dev] [Nova][oslo] how to sync oslo.concurrency to nova? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/10/2014 05:05 AM, Ihar Hrachyshka wrote: On 10/10/14 10:32, Chen CH Ji wrote: There used to method in oslo-incubator like https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator or '_https://review.openstack.org/#/c/78429/_ ' we can use however, I was told to submit patch to oslo.concurrency instead of oslo-incubator, so what's the method can be used now ? Thanks a lot With oslo.concurrency, you don't copy-paste code, you just reuse it as any other third-party library. So if your project is not yet using the library, just port it to it first, and once a new version of oslo.concurrency is released, you will get your change magically applied. At this point oslo.concurrency hasn't been released yet so it won't be possible to switch any projects to use it. I think we're on track for a first release early next week and once that has happened this will be possible. Note that we do have a stable branch of the incubator code that can be used for important changes in projects that haven't yet ported to use new libs, but when possible we'd rather just make the changes in the lib. - -Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUN+bgAAoJEDehGd0Fy7uqjhMIANBPX4sTbVSnewoquF3Ih29z Adxq6KpDymonhpnJuOqM1gKYsd/oyqa6q92WTt9F9c8XwALB1x9IzgUBRRixhts5 p4fDzNTMGJzlT9slnGjyNVD0i3AJ1UuO5+mZADDk3jXqqERmbeCo+BgYqJr7q08r MmkPuo0EAZtWrY1+Isl1Eg3lz7P2DFC9kEmY8iUj5wObiqINU7L5MNCzCi7V+c8g uxacoCSXcyTR7nnXcs9cPywthBTLOOqkY1IzEYk38vbnQSmvqKbbovqVB0ZCTueF 8g/WO2+jOhETsyFGY7d3HuOQDxJSx/JeXlpPfriOsxdcrDtmP3YMEgh2kpK0e7k= =Puy/ -END PGP SIGNATURE- ___ 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 documentation to update about new vendor plugin, but without code in repository?
Hi Anne, Thanks for your immediate response!... Just to clarify... I have developed and maintaining a Neutron plug-in (ML2 mechanism_driver) since Grizzly and now it is up-to-date with Icehouse. But it was never listed nor part of the main Openstack releases. Now i would like to have my plugin mentioned as supported plugin/mechanism_driver for so and so vendor equipments in the docs.openstack.org, but without having the actual plugin code to be posted in the main Openstack GIT repository. Reason is that I dont have plan/bandwidth to go thru the entire process of new plugin blue-print/development/review/testing etc as required by the Openstack development community. Bcos this is already developed, tested and released to some customers directly. Now I just want to get it to the official Openstack documentation, so that more people can get this and use. The plugin package is made available to public from Ubuntu repository along with necessary documentation. So people can directly get it from Ubuntu repository and use it. All i need is to get listed in the docs.openstack.org so that people knows that it exists and can be used with any Openstack. Pls. confrim whether this is something possible?... Thanks again!.. Vad -- On Fri, Oct 10, 2014 at 12:18 PM, Anne Gentle a...@openstack.org wrote: On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan vadivel.openst...@gmail.com wrote: Hi, How to include a new vendor plug-in (aka mechanism_driver in ML2 framework) into the Openstack documentation?.. In other words, is it possible to include a new plug-in in the Openstack documentation page without having the actual plug-in code as part of the Openstack neutron repository?... The actual plug-in is posted and available for the public to download as Ubuntu package. But i need to mention somewhere in the Openstack documentation that this new plugin is available for the public to use along with its documentation. We definitely want you to include pointers to vendor documentation in the OpenStack docs, but I'd prefer make sure they're gate tested before they get listed on docs.openstack.org. Drivers change enough release-to-release that it's difficult to keep up maintenance. Lately I've been talking to driver contributors (hypervisor, storage, networking) about the out-of-tree changes possible. I'd like to encourage even out-of-tree drivers to get listed, but to store their main documents outside of docs.openstack.org, if they are gate-tested. Anyone have other ideas here? Looping in the OpenStack-docs mailing list also. Anne Pls. provide some insights into whether it is possible?.. and any further info on this?.. Thanks, Vad -- ___ 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] [oslo] Meeting time
On Oct 8, 2014, at 10:19 AM, Doug Hellmann d...@doughellmann.com wrote: On Oct 8, 2014, at 5:20 AM, Julien Danjou jul...@danjou.info wrote: On Tue, Oct 07 2014, Roman Podoliaka wrote: - Mondays at 1600 UTC [1]: #openstack-meeting-alt, #openstack-meeting-3 - Thursdays at 1600 UTC [2]: #openstack-meeting-3 One of these would be cool. -- Julien Danjou -- Free Software hacker -- http://julien.danjou.info ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I think we’re converging, but let’s do this with doodle instead of spamming the dev list. Please vote here: http://doodle.com/zv8izg7ymxcank34 Doug The survey results indicate a clear preference for the Monday 16:00 UTC time slot, so I’ve updated https://wiki.openstack.org/wiki/Meetings#Oslo_Team_meeting to reflect that. We will skip meeting the Monday right after the summit on the assumption we will have nothing new to say to one another after spending a week together. :-) The first date for the new meeting time will be Monday 17 Nov 2014. We will keep the same meeting room, #openstack-meeting-alt. Until then let's continue to meet on Fridays. Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] RSS feeds for gerrit projects
On 2014-10-10 19:15:33 +0200 (+0200), Christian Berendt wrote: Is it possible to directly access RSS feeds for gerrit projects or is the only way to do this to use a wrapper like openstackwatch in jeepyb? As far as I can tell, Gerrit has no RSS feature yet[1]. An OSW instance was added to review.openstack.org mainly as a proof-of-concept[2], but the RSS files[3] seem to have ceased updating roughly 6 months ago so probably broken by the Gerrit upgrade. Clearly nobody was using it in that time, but if there's renewed interest then I doubt the infra team would refuse patches to get it back into working order. [1] http://code.google.com/p/gerrit/issues/detail?id=561 [2] http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/manifests/gerrit.pp#n78 [3] http://rss.cdn.openstack.org/nova.xml -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Group-based Policy] Database migration chain
On 10/7/14 6:36 PM, Ivar Lazzaro wrote: I posted a patch that implements the Different DB Different Chain approach [0]. That does not mean that this approach is the chosen one! It's just to have a grasp of what the change looks like. The Same DB different chain solution is much simpler to implement (basically you just specify a different version table in the alembic environment) so I haven't posted anything for that. One thing I'm particularly interested about is to hear packagers opinions about which approach would be the preferred one: Same DB or Different? It seems to me that deployment tools such as puppet scripts would also be simpler if the GBP service plugin used the neutron DB, as there would be no need to create a separate DB, set its permissions, put its URL into neutron's config file, etc.. All that would be needed at deployment time is to run the additional gbp-db-manage tool to perform the GBP DB migrations. Am I missing anything? With dependencies only in one direction, and the foreign keys GBP depends on (neutron resource IDs) unlikely to be changed by neutron migrations during Kilo, I don't think we need to worry about interleaving GBP migrations with neutron migrations. On initial deployments or version upgrades, it should be sufficient to run gbp-db-manage after neutron-db-manage. On downgrades, some situations might require running gbp-db-manage before neutron-db-manage. This seems not to be effected by whether the two migration chains are in the same DB/schema or different ones. Also, on the line of Bob's comment in my patch, is there any kind of compatibility or performance issue anyone is aware of about in using cross schema FKs? In addition to compatibility and performance, I'm also concerned about DB connection management when the same server is using multiple connection URLs. I'm not convinced the approach in the patch is sufficient. At least with some DBs, wouldn't we we need a separate sqlalchemy.create_engine() call with each DB's connection URL, which might require using separate context and session objects rather than the ones neutron uses? -Bob Thanks, Ivar. [0] https://review.openstack.org/#/c/126383/ On Mon, Oct 6, 2014 at 11:09 AM, Ivar Lazzaro ivarlazz...@gmail.com mailto:ivarlazz...@gmail.com wrote: I believe Group-based Policy (which this thread is about) will use the Neutron database configuration for its dependent database. If Neutron is configured for: connection = mysql://user:pass@locationX:3306/neutron then GBP would use: connection = mysql://user:pass@locationX:3306/neutron_gbp That's correct, that would be the likely approach if we go with the different schema route. if you can get the “other database” to be accessible from the target database via “otherdatabase.sometable”, then you’re in. from SQLAlchemy’s perspective, it’s just a name with a dot. It’s the database itself that has to support the foreign key at the scope you are shooting for. I'm experimenting this approach with our code and it seems to be the case. ' I feel that having the constraint of pointing the same database connection with a different schema is pretty acceptable given how tight is GBP to Neutron. On Sat, Oct 4, 2014 at 8:54 AM, Henry Gessau ges...@cisco.com mailto:ges...@cisco.com wrote: Clint Byrum cl...@fewbar.com mailto:cl...@fewbar.com wrote: Excerpts from Mike Bayer's message of 2014-10-04 08:10:38 -0700: On Oct 4, 2014, at 1:10 AM, Kevin Benton blak...@gmail.com mailto:blak...@gmail.com wrote: Does sqlalchemy have good support for cross-database foreign keys? I was under the impression that they cannot be implemented with the normal syntax and semantics of an intra-database foreign-key constraint. cross “database” is not typically portable, but cross “schema” is. different database vendors have different notions of “databases” or “schemas”. if you can get the “other database” to be accessible from the target database via “otherdatabase.sometable”, then you’re in. from SQLAlchemy’s perspective, it’s just a name with a dot. It’s the database itself that has to support the foreign key at the scope you are shooting for. All true, however, there are zero guarantees that databases will be hosted on the same server, and typically permissions are setup to prevent cross-schema joins. I believe Group-based Policy (which this thread is about) will use the Neutron database configuration for its dependent database. If Neutron is configured for: connection = mysql://user:pass@locationX:3306/neutron
Re: [openstack-dev] [Group-based Policy] Database migration chain
It seems to me that deployment tools such as puppet scripts would also be simpler if the GBP service plugin used the neutron DB, as there would be no need to create a separate DB, set its permissions, put its URL into neutron's config file, etc.. All that would be needed at deployment time is to run the additional gbp-db-manage tool to perform the GBP DB migrations. Am I missing anything? That's correct, being a new schema it needs to be created, the access granted, and the connection URL configured in neutron.conf (doable also with devstack in the extra-conf option). With dependencies only in one direction, and the foreign keys GBP depends on (neutron resource IDs) unlikely to be changed by neutron migrations during Kilo, I don't think we need to worry about interleaving GBP migrations with neutron migrations. On initial deployments or version upgrades, it should be sufficient to run gbp-db-manage after neutron-db-manage. On downgrades, some situations might require running gbp-db-manage before neutron-db-manage. This seems not to be effected by whether the two migration chains are in the same DB/schema or different ones. That's correct too. Also, this is true for the downgrade even with a different schema. In addition to compatibility and performance, I'm also concerned about DB connection management when the same server is using multiple connection URLs. I'm not convinced the approach in the patch is sufficient. At least with some DBs, wouldn't we we need a separate sqlalchemy.create_engine() call with each DB's connection URL, which might require using separate context and session objects rather than the ones neutron uses? That should not be the case. We are not using a separate DB connection. The connection is in fact the same, the only thing that changes is the schema. For the sql engine this should be only a matter of namespacing (different schema - different namespace), therefore I don't see any relevant performance/connection/greenthread issue. However I'm no DBMS expert, any additional feedback on this matter is welcome. Ivar. On Fri, Oct 10, 2014 at 2:59 PM, Robert Kukura kuk...@noironetworks.com wrote: On 10/7/14 6:36 PM, Ivar Lazzaro wrote: I posted a patch that implements the Different DB Different Chain approach [0]. That does not mean that this approach is the chosen one! It's just to have a grasp of what the change looks like. The Same DB different chain solution is much simpler to implement (basically you just specify a different version table in the alembic environment) so I haven't posted anything for that. One thing I'm particularly interested about is to hear packagers opinions about which approach would be the preferred one: Same DB or Different? It seems to me that deployment tools such as puppet scripts would also be simpler if the GBP service plugin used the neutron DB, as there would be no need to create a separate DB, set its permissions, put its URL into neutron's config file, etc.. All that would be needed at deployment time is to run the additional gbp-db-manage tool to perform the GBP DB migrations. Am I missing anything? With dependencies only in one direction, and the foreign keys GBP depends on (neutron resource IDs) unlikely to be changed by neutron migrations during Kilo, I don't think we need to worry about interleaving GBP migrations with neutron migrations. On initial deployments or version upgrades, it should be sufficient to run gbp-db-manage after neutron-db-manage. On downgrades, some situations might require running gbp-db-manage before neutron-db-manage. This seems not to be effected by whether the two migration chains are in the same DB/schema or different ones. Also, on the line of Bob's comment in my patch, is there any kind of compatibility or performance issue anyone is aware of about in using cross schema FKs? In addition to compatibility and performance, I'm also concerned about DB connection management when the same server is using multiple connection URLs. I'm not convinced the approach in the patch is sufficient. At least with some DBs, wouldn't we we need a separate sqlalchemy.create_engine() call with each DB's connection URL, which might require using separate context and session objects rather than the ones neutron uses? -Bob Thanks, Ivar. [0] https://review.openstack.org/#/c/126383/ On Mon, Oct 6, 2014 at 11:09 AM, Ivar Lazzaro ivarlazz...@gmail.com wrote: I believe Group-based Policy (which this thread is about) will use the Neutron database configuration for its dependent database. If Neutron is configured for: connection = mysql://user:pass@locationX:3306/neutron then GBP would use: connection = mysql://user:pass@locationX:3306/neutron_gbp That's correct, that would be the likely approach if we go with the different schema route. if you can get the “other database” to be accessible from the target database via
Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can!
On Fri, Oct 3, 2014 at 3:07 PM, Stefano Maffulli stef...@openstack.org wrote: 4. Send e-mail to reviewers network...@openstacknow.com. Why not use the docs mailing list or other facilities on @openstack.org? We've now switched over to use the [networking] topic on the openstack-docs list. So anybody who's interested in following the discussions, please feel free to join us. Thanks! - Nick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Neutron documentation to update about new vendor plugin, but without code in repository?
I think you will probably have to wait until after the summit so we can see the direction that will be taken with the rest of the in-tree drivers/plugins. It seems like we are moving towards removing all of them so we would definitely need a solution to documenting out-of-tree drivers as you suggested. However, I think the minimum requirements for having a driver being documented should be third-party testing of Neutron patches. Otherwise the docs will become littered with a bunch of links to drivers/plugins with no indication of what actually works, which ultimately makes Neutron look bad. On Fri, Oct 10, 2014 at 1:28 PM, Vadivel Poonathan vadivel.openst...@gmail.com wrote: Hi Anne, Thanks for your immediate response!... Just to clarify... I have developed and maintaining a Neutron plug-in (ML2 mechanism_driver) since Grizzly and now it is up-to-date with Icehouse. But it was never listed nor part of the main Openstack releases. Now i would like to have my plugin mentioned as supported plugin/mechanism_driver for so and so vendor equipments in the docs.openstack.org, but without having the actual plugin code to be posted in the main Openstack GIT repository. Reason is that I dont have plan/bandwidth to go thru the entire process of new plugin blue-print/development/review/testing etc as required by the Openstack development community. Bcos this is already developed, tested and released to some customers directly. Now I just want to get it to the official Openstack documentation, so that more people can get this and use. The plugin package is made available to public from Ubuntu repository along with necessary documentation. So people can directly get it from Ubuntu repository and use it. All i need is to get listed in the docs.openstack.org so that people knows that it exists and can be used with any Openstack. Pls. confrim whether this is something possible?... Thanks again!.. Vad -- On Fri, Oct 10, 2014 at 12:18 PM, Anne Gentle a...@openstack.org wrote: On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan vadivel.openst...@gmail.com wrote: Hi, How to include a new vendor plug-in (aka mechanism_driver in ML2 framework) into the Openstack documentation?.. In other words, is it possible to include a new plug-in in the Openstack documentation page without having the actual plug-in code as part of the Openstack neutron repository?... The actual plug-in is posted and available for the public to download as Ubuntu package. But i need to mention somewhere in the Openstack documentation that this new plugin is available for the public to use along with its documentation. We definitely want you to include pointers to vendor documentation in the OpenStack docs, but I'd prefer make sure they're gate tested before they get listed on docs.openstack.org. Drivers change enough release-to-release that it's difficult to keep up maintenance. Lately I've been talking to driver contributors (hypervisor, storage, networking) about the out-of-tree changes possible. I'd like to encourage even out-of-tree drivers to get listed, but to store their main documents outside of docs.openstack.org, if they are gate-tested. Anyone have other ideas here? Looping in the OpenStack-docs mailing list also. Anne Pls. provide some insights into whether it is possible?.. and any further info on this?.. Thanks, Vad -- ___ 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 -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Any ideas on why nova-novncproxy is failing to start on devstack?
I had a system with devstack, which I restack with reclone, with the intention of then patching in my review diffs to update and test. Well, the stack is failing in n-nonvc, with this message: openstack@devstack-33:~/devstack$ /usr/local/bin/nova-novncproxy --config-file /etc/nova/nova.conf --web /opt/stack/noVNC echo $! /opt/stack/status/stack/n-novnc.pid; fg || echo n-novnc failed to start | tee /opt/stack/status/stack/n-novnc.failure [1] 826 /usr/local/bin/nova-novncproxy --config-file /etc/nova/nova.conf --web /opt/stack/noVNC Traceback (most recent call last): File /usr/local/bin/nova-novncproxy, line 6, in module from nova.cmd.novncproxy import main File /opt/stack/nova/nova/cmd/novncproxy.py, line 29, in module from nova.console import websocketproxy File /opt/stack/nova/nova/console/websocketproxy.py, line 110, in module websockify.ProxyRequestHandler): AttributeError: 'module' object has no attribute 'ProxyRequestHandler' n-novnc failed to start The websockify package is installed: openstack@devstack-33:~/devstack$ pip show websockify --- Name: websockify Version: 0.5.1 Location: /usr/local/lib/python2.7/dist-packages Requires: numpy However, the version required is: openstack@devstack-33:/opt/stack/nova$ grep websockify requirements.txt websockify=0.6.0,0.7 Any ideas why is does not have the right version and how to best correct? Thanks! PCM (Paul Michali) MAIL …..…. p...@cisco.com IRC ……..… pcm_ (irc.freenode.com) TW ………... @pmichali GPG Key … 4525ECC253E31A83 Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 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] [OpenStack-docs] Neutron documentation to update about new vendor plugin, but without code in repository?
Hi, IMHO we should have a proper way to reference external vendor specific plugins/drivers mostly because at least in Neutron we are considering to move ALL vendor specific code out-of-tree, again it is just a consideration not a fact. So, having a place holder for that will make sense. Thanks, Edgar From: Anne Gentle a...@openstack.orgmailto:a...@openstack.org Date: Friday, October 10, 2014 at 12:18 PM To: OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org Cc: openstack-d...@lists.openstack.orgmailto:openstack-d...@lists.openstack.org openstack-d...@lists.openstack.orgmailto:openstack-d...@lists.openstack.org Subject: Re: [OpenStack-docs] [openstack-dev] Neutron documentation to update about new vendor plugin, but without code in repository? On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan vadivel.openst...@gmail.commailto:vadivel.openst...@gmail.com wrote: Hi, How to include a new vendor plug-in (aka mechanism_driver in ML2 framework) into the Openstack documentation?.. In other words, is it possible to include a new plug-in in the Openstack documentation page without having the actual plug-in code as part of the Openstack neutron repository?... The actual plug-in is posted and available for the public to download as Ubuntu package. But i need to mention somewhere in the Openstack documentation that this new plugin is available for the public to use along with its documentation. We definitely want you to include pointers to vendor documentation in the OpenStack docs, but I'd prefer make sure they're gate tested before they get listed on docs.openstack.orghttp://docs.openstack.org. Drivers change enough release-to-release that it's difficult to keep up maintenance. Lately I've been talking to driver contributors (hypervisor, storage, networking) about the out-of-tree changes possible. I'd like to encourage even out-of-tree drivers to get listed, but to store their main documents outside of docs.openstack.orghttp://docs.openstack.org, if they are gate-tested. Anyone have other ideas here? Looping in the OpenStack-docs mailing list also. Anne Pls. provide some insights into whether it is possible?.. and any further info on this?.. Thanks, Vad -- ___ 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] Any ideas on why nova-novncproxy is failing to start on devstack?
Well, I deleted /usr/local/lib/python2.7/dist-packages/websockify* and then stacked and it worked! PCM (Paul Michali) MAIL …..…. p...@cisco.com IRC ……..… pcm_ (irc.freenode.com) TW ………... @pmichali GPG Key … 4525ECC253E31A83 Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 On Oct 10, 2014, at 8:46 PM, Paul Michali (pcm) p...@cisco.com wrote: I had a system with devstack, which I restack with reclone, with the intention of then patching in my review diffs to update and test. Well, the stack is failing in n-nonvc, with this message: openstack@devstack-33:~/devstack$ /usr/local/bin/nova-novncproxy --config-file /etc/nova/nova.conf --web /opt/stack/noVNC echo $! /opt/stack/status/stack/n-novnc.pid; fg || echo n-novnc failed to start | tee /opt/stack/status/stack/n-novnc.failure [1] 826 /usr/local/bin/nova-novncproxy --config-file /etc/nova/nova.conf --web /opt/stack/noVNC Traceback (most recent call last): File /usr/local/bin/nova-novncproxy, line 6, in module from nova.cmd.novncproxy import main File /opt/stack/nova/nova/cmd/novncproxy.py, line 29, in module from nova.console import websocketproxy File /opt/stack/nova/nova/console/websocketproxy.py, line 110, in module websockify.ProxyRequestHandler): AttributeError: 'module' object has no attribute 'ProxyRequestHandler' n-novnc failed to start The websockify package is installed: openstack@devstack-33:~/devstack$ pip show websockify --- Name: websockify Version: 0.5.1 Location: /usr/local/lib/python2.7/dist-packages Requires: numpy However, the version required is: openstack@devstack-33:/opt/stack/nova$ grep websockify requirements.txt websockify=0.6.0,0.7 Any ideas why is does not have the right version and how to best correct? Thanks! PCM (Paul Michali) MAIL …..…. p...@cisco.com IRC ……..… pcm_ (irc.freenode.com) TW ………... @pmichali GPG Key … 4525ECC253E31A83 Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 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] [oslo] Proposed database connectivity patterns
On Oct 10, 2014, at 12:52 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/10/14 20:21, Joshua Harlow wrote: On Oct 10, 2014, at 3:13 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: On 09/10/14 21:29, Mike Bayer wrote: So so far, everyone seems really positive and psyched about the proposal. It looks like providing some options for how to use would be best, that is provide decorators and context managers. Now the thing with the context manager, it can be as I stated: with sql.reader() as session: or we can even have that accept the “context”: with sql.reader(context) as session: The latter again avoids having to use thread locals. But can I get a feel for how comfortable we are with using thread local storage to implement this feature? I had anticipated people wouldn’t like it because it’s kind of a “global” object, even though it will be hidden behind this facade (of course CONF is global as is sys.modules, and I think it is fine). If I just use a tlocal, this whole thing is pretty simple. Won't the approach conflict with eventlet consumers that for some reason do not patch thread module, or do not patch it early enough? I guess in that case we may end up with mixed contexts. Eck, this is not something people should be doing (not patching the thread module). Example for why @ https://gist.github.com/harlowja/9c35e443dfa136a4f965 (run that and see your program lock up). Once you accept/use eventlet, u shouldn't really be accepted half of it, otherwise there be dragons there; especially since openstack doesn't control what external library code does inside those libraries (and rightfully so it shouldn't), and if any library does anything like that gist code, the whole application will lock up... Real life sucks. In Neutron, we have at least two files that patch only some modules (though all of them patch threading). [Not that I mean that those files should not patch the whole library set; I have no defined view on the matter.] Yup it does, and once u accept eventlet it starts to become hard to get off it... It's 'viral', and for better or worse openstack has got the virus... So that means everything that openstack touches/uses also needs to be compatible with that virus... It's to bad guido just didn't accept eventlet/greenlet into mainline python, that would of made our job easier (and then added a python option or something like `python -g` that turns on greenthreading by default when the interpreter is started up)... Thats the crappy part with anything that monkey patches all the things, its not so easy to accept half of a monkey... Though I agree that consumers with some modules unpatched are not something that should be seriosly considered, we're still left with consumers that do not patch their libraries early enough. We had an issue with tlocal when porting Neutron to oslo.messaging that resulted in the following patch: https://review.openstack.org/#/c/96791/ The issue showed up in very weird way hard to debug, so if possible, I would try to avoid similar situations with oslo.db. I'm unsure on this one, I don't think we should be making oslo.* that succumbs to the same eventlet virus just because openstack projects aren't correctly using eventlet. The same bug that was found in oslo.messaging could of been any third part library that wasn't imported in the right order in all honesty. So it seems like we should fix the projects (as in that review) instead of making the oslo.* libraries less future compatible... If eventlet/greenlet got merged into mainline python then I'd say probably say the reverse, but it didn't. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUODkZAAoJEC5aWaUY1u57QrcIANLtMi1jRrfHnwV2xnwYGPOl QwZWDG6i/cdnzqrwGz+0chqRxu4KWZB5gAfMR4/ralHvGGbaa1vGp9wtzsfIJTB1 RuyE7XKXUX4rU3WoAOB7F3uF1WzFpI8ourunBG4OCE0t0YT89z9mCLfOTZNNKGxH OE89n4pnyMd3GXGtoxVINyA6pqQotYuHKG6o6LbhmTZ1UoL3P3rO+Onb1Ma2BF6Z VO84smdMnOC3yVtv4TGwrW5iBoU3RwOqxooOg4g5Jam6D++kzCKrPT9wdY7TNe+C A6IvMlad0RbygkhrLyWIWXaqCAg5VzzDvk4z6dywVkmoWS7V861mjiV4unbr0X8= =5ovh -END PGP SIGNATURE- ___ 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 documentation to update about new vendor plugin, but without code in repository?
On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton blak...@gmail.com wrote: I think you will probably have to wait until after the summit so we can see the direction that will be taken with the rest of the in-tree drivers/plugins. It seems like we are moving towards removing all of them so we would definitely need a solution to documenting out-of-tree drivers as you suggested. However, I think the minimum requirements for having a driver being documented should be third-party testing of Neutron patches. Otherwise the docs will become littered with a bunch of links to drivers/plugins with no indication of what actually works, which ultimately makes Neutron look bad. This is my line of thinking as well, expanded to ultimately makes OpenStack docs look bad -- a perception I want to avoid. Keep the viewpoints coming. We have a crucial balancing act ahead: users need to trust docs and trust the drivers. Ultimately the responsibility for the docs is in the hands of the driver contributors so it seems those should be on a domain name where drivers control publishing and OpenStack docs are not a gatekeeper, quality checker, reviewer, or publisher. We have documented the status of hypervisor drivers on an OpenStack wiki page. [1] To me, that type of list could be maintained on the wiki page better than in the docs themselves. Thoughts? Feelings? More discussion, please. And thank you for the responses so far. Anne [1] https://wiki.openstack.org/wiki/HypervisorSupportMatrix On Fri, Oct 10, 2014 at 1:28 PM, Vadivel Poonathan vadivel.openst...@gmail.com wrote: Hi Anne, Thanks for your immediate response!... Just to clarify... I have developed and maintaining a Neutron plug-in (ML2 mechanism_driver) since Grizzly and now it is up-to-date with Icehouse. But it was never listed nor part of the main Openstack releases. Now i would like to have my plugin mentioned as supported plugin/mechanism_driver for so and so vendor equipments in the docs.openstack.org, but without having the actual plugin code to be posted in the main Openstack GIT repository. Reason is that I dont have plan/bandwidth to go thru the entire process of new plugin blue-print/development/review/testing etc as required by the Openstack development community. Bcos this is already developed, tested and released to some customers directly. Now I just want to get it to the official Openstack documentation, so that more people can get this and use. The plugin package is made available to public from Ubuntu repository along with necessary documentation. So people can directly get it from Ubuntu repository and use it. All i need is to get listed in the docs.openstack.org so that people knows that it exists and can be used with any Openstack. Pls. confrim whether this is something possible?... Thanks again!.. Vad -- On Fri, Oct 10, 2014 at 12:18 PM, Anne Gentle a...@openstack.org wrote: On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan vadivel.openst...@gmail.com wrote: Hi, How to include a new vendor plug-in (aka mechanism_driver in ML2 framework) into the Openstack documentation?.. In other words, is it possible to include a new plug-in in the Openstack documentation page without having the actual plug-in code as part of the Openstack neutron repository?... The actual plug-in is posted and available for the public to download as Ubuntu package. But i need to mention somewhere in the Openstack documentation that this new plugin is available for the public to use along with its documentation. We definitely want you to include pointers to vendor documentation in the OpenStack docs, but I'd prefer make sure they're gate tested before they get listed on docs.openstack.org. Drivers change enough release-to-release that it's difficult to keep up maintenance. Lately I've been talking to driver contributors (hypervisor, storage, networking) about the out-of-tree changes possible. I'd like to encourage even out-of-tree drivers to get listed, but to store their main documents outside of docs.openstack.org, if they are gate-tested. Anyone have other ideas here? Looping in the OpenStack-docs mailing list also. Anne Pls. provide some insights into whether it is possible?.. and any further info on this?.. Thanks, Vad -- ___ 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 -- Kevin Benton ___ OpenStack-dev mailing list
[openstack-dev] [OpenStack-Dev] [libvirt] Block Devices and the discard option
Hi, So I've been beating on this for a good part of the day and I'm not having much luck so I thought I'd ask on the ML if anybody has had any success with the following. We have some applications that have been migrated off of our physical machines and into our OpenStack Cloud. The trouble is that these apps and our storage take advantage of fstrim which returns the error: fstrim: /: FITRIM ioctl failed: Operation not supported I thought... oh, easy I'll work up a quick patch to add this to Cinder and Nova; but I don't seem to be having any luck getting this to work. I also cam across the Nova patch to add this to Local Disk here: [1] and I seem to get the same error there as well. Testing fstrim on the devices from the compute node works fine, just not the device passed in to the instance. The XML I'm sending looks like this [2] I'm running on 14.04 with RC1 builds. I'm not sure what I'm missing, or if anybody has been able to make this work, or if it should work. Any insight would be greatly appreciated. Thanks, John [1]: https://review.openstack.org/#/c/112977/12 [2]: https://gist.github.com/j-griffith/3341ad287c5d684f02b5 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] [libvirt] Block Devices and the discard option
On 10/10/2014 08:44 PM, John Griffith wrote: Hi, So I've been beating on this for a good part of the day and I'm not having much luck so I thought I'd ask on the ML if anybody has had any success with the following. We have some applications that have been migrated off of our physical machines and into our OpenStack Cloud. The trouble is that these apps and our storage take advantage of fstrim which returns the error: fstrim: /: FITRIM ioctl failed: Operation not supported I thought... oh, easy I'll work up a quick patch to add this to Cinder and Nova; but I don't seem to be having any luck getting this to work. I also cam across the Nova patch to add this to Local Disk here: [1] and I seem to get the same error there as well. Testing fstrim on the devices from the compute node works fine, just not the device passed in to the instance. The XML I'm sending looks like this [2] I'm running on 14.04 with RC1 builds. I'm not sure what I'm missing, or if anybody has been able to make this work, or if it should work. Any insight would be greatly appreciated. Thanks, John [1]: https://review.openstack.org/#/c/112977/12 [2]: https://gist.github.com/j-griffith/3341ad287c5d684f02b5 Hey John, I'm not sure if it's the only issue, but the virtio bus doesn't support discard. You need to use virtio-scsi, scsi, or ide. Josh ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
