[openstack-dev] [magnum][barbican] Setting a live debug session time
Madhuri, Alee is in EST timezone (gmt-5 IIRC). Alee will help you get barbican rolling. Can you two folks set up a time to chat on irc on Monday or tuesday? Thanks -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Sounds good to me, +1 I know that some of the oslo core (I've done a little) and others (victor does a-lot of it) have been taking over this duty already but some kind of miniature group that has this a main goal would be cool to. -Josh Davanum Srinivas wrote: Thierry, +1 from me. We could just use a wiki to track work or upstream PR/reviews for now. -- dims On Fri, Jul 17, 2015 at 7:40 AM, Thierry Carrezthie...@openstack.org wrote: Davanum Srinivas wrote: Sounds like a great idea Thierry! Any concrete deliverables you have in mind for this group? I don't think that team would use a specific repository. More like agree on a set of objectives to reach in a given cycle, like the list Thomas came up with. If one ends up being a lot of work, optionally turn that into a cross-project spec. Then propose and babysit the changes to make those happen. Have regular meetings to track progress and split the work. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Victor Stinner wrote: Le 16/07/2015 22:28, Thomas Goirand a écrit : IMO, we should, for the Liberty release, get rid of: - suds suds-jurko suds was replaced with suds-jurko (in oslo.vmware, cinder, nova): I kicked suds off of global requirements. - memcached (in the favor of pymemcache) As I wrote, I may fork python-memcached. It's just not in my priority list right now. Oh noes, please don't fork it... I'd rather just focus on any more shift to pymemcache and let bygones be bygones... Afaik once https://github.com/pinterest/pymemcache/commit/63a2d96048202 (Introduced HashClient that uses consistent hasing... and Python 3 Support ... commit) is released (the hashing feature that just landed IMHO makes that client a production-ready fully featured client finally) then there really is no need to have python-memcached client anymore. FYI some colleagues just forked python-ldap in https://github.com/pyldap/pyldap/ to add Python 3 support. Stay tuned ;-) - mysqldb (this has been discussed at large already) MySQL-Python was replaced with PyMySQL in almost all projects, no? Even nova is now using PyMySQL ;-) - cliff-tablib and tablib (not ported to Py3, used only for testing) tablib works on Python 3, but it has a strange way of using dependencies. You can try to remove tablib/packages/markup.py when building the package for Python 3 and it should just work. Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Python 3: 5 more projects with a py34 voting gate, only 4 remaing
Hi, We are close to having a voting py34 gate on all OpenStack libraries and applications. I just made the py34 gate voting for the 5 following projects: * keystone * heat * glance_store: Glance library (py34 is already voting in Glance) * os-brick: Cinder library (py34 is already voting in Cinder) * sqlalchemy-migrate A voting py34 gate means that we cannot reintroduce Python 3 regressions in the code tested by tox -e py34. Currently, only a small subset of test suites is executed on Python 3.4, but the subset is growing constantly and it already helps to detect various kinds of Python 3 issues. Sirushti Murugesan (who is porting Heat to Python 3) and me proposed a talk Python 3 is coming! to the next OpenStack Summit at Tokyo. We will explain the plan to port OpenStack to Python in depth. There are only 4 remaining projects without py34 voting gate: (1) swift: I sent patches, see the Fix tox -e py34 patch: https://review.openstack.org/#/q/project:openstack/swift+branch:master+topic:py3,n,z (2) horizon: I sent patches: https://review.openstack.org/#/q/topic:bp/porting-python3+project:openstack/horizon,n,z (3) keystonemiddleware: blocked by python-memcached, I sent a pull request 3 months ago and I'm still waiting... https://github.com/linsomniac/python-memcached/pull/67 I may fork the project if the maintainer never reply. Read the current thread [all] Non-responsive upstream libraries (python34 specifically) on openstack-dev. (4) python-savannaaclient: We haven't enough tests to ensure that savanna client works correctly on py33, so, it's kind of premature step. We already have py33 and pypy jobs in experimental pipeline. This client can be ported later. Note: The py34 gate of oslo.messaging is currently non voting because of a bug in Python 3.4.0, fix not backported to Ubuntu Trusty LTS yet: https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1367907 The bug was fixed in Python 3.4 in May 2014 and was reported to Ubuntu in September 2014. Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library
Hey Alex, On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, I think that we should provide a separate script that will fetch the upstream modules into fuel-library/deployment/puppet/ directory. It will allow us to have everything in a single place and use this script in ISO build process and CI jobs. Right. That is what I'm going for. The issue I need help with is the best way to execute this as part of the build process. From what i understand of the build process is that we are using git archive for all pieces so I'm not sure how to wedge in an extra script execution to do the module fetch. The creation of the script isn't the issue, the issue is how can I properly run it as part of the build process. Regards, Alex Thanks, -Alex On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz aschu...@mirantis.com wrote: Hello everyone, I have committed the initial configuration required to start leveraging librarian-puppet as part of the way we pull in upstream puppet modules[0]. Additionally, I have also committed a change that would pull in the openstack-ironic module[1]. The one piece that is missing from this being a complete solution is the ability to run librarian-puppet as part of our build process for the fuel-library. I've looked into the fuel-main build scripts and I think it's over my head to figure this out just by looking. Can anyone explain to me or assist me in how I could go about modifying the existing build system to be able to run librarian-puppet to prepare the source for the package? In my initial investigation, it looks like it would be a modification of the fuel-main/packages/module.mk[3] file. I basically need to do the prepare_library[3] function from the 202763 review[0] after we've pulled all the sources together to fetch the upstream modules. Thanks, -Alex [0] https://review.openstack.org/202763 [1] https://review.openstack.org/202767 [2] https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 [3] https://review.openstack.org/#/c/202763/1/utils/jenkins/fuel_noop_tests.rb __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Davanum Srinivas wrote: Sounds like a great idea Thierry! Any concrete deliverables you have in mind for this group? I don't think that team would use a specific repository. More like agree on a set of objectives to reach in a given cycle, like the list Thomas came up with. If one ends up being a lot of work, optionally turn that into a cross-project spec. Then propose and babysit the changes to make those happen. Have regular meetings to track progress and split the work. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library
I believe build_repo function is the best way to do this [0]. So for fuel-library we'll need to run a shell script right from the repo before 'touch $$@'. We can make it either conditional ( test -f ./path/additional_build_script.sh bash ./path/additional_build_script.sh ) or as additional parameter to function and add it in fuel-library call [1] Regards, Alex [0] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L16-L37 [1] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L45 On Fri, Jul 17, 2015 at 2:37 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Alex, On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, I think that we should provide a separate script that will fetch the upstream modules into fuel-library/deployment/puppet/ directory. It will allow us to have everything in a single place and use this script in ISO build process and CI jobs. Right. That is what I'm going for. The issue I need help with is the best way to execute this as part of the build process. From what i understand of the build process is that we are using git archive for all pieces so I'm not sure how to wedge in an extra script execution to do the module fetch. The creation of the script isn't the issue, the issue is how can I properly run it as part of the build process. Regards, Alex Thanks, -Alex On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz aschu...@mirantis.com wrote: Hello everyone, I have committed the initial configuration required to start leveraging librarian-puppet as part of the way we pull in upstream puppet modules[0]. Additionally, I have also committed a change that would pull in the openstack-ironic module[1]. The one piece that is missing from this being a complete solution is the ability to run librarian-puppet as part of our build process for the fuel-library. I've looked into the fuel-main build scripts and I think it's over my head to figure this out just by looking. Can anyone explain to me or assist me in how I could go about modifying the existing build system to be able to run librarian-puppet to prepare the source for the package? In my initial investigation, it looks like it would be a modification of the fuel-main/packages/module.mk[3] file. I basically need to do the prepare_library[3] function from the 202763 review[0] after we've pulled all the sources together to fetch the upstream modules. Thanks, -Alex [0] https://review.openstack.org/202763 [1] https://review.openstack.org/202767 [2] https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 [3] https://review.openstack.org/#/c/202763/1/utils/jenkins/fuel_noop_tests.rb __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]Proposal for function to manage the resources available to each tenant
Thank you for reply! Not sure I fully understand but AggregateMultiTenancyIsolation filter already partially does the job (with a certain number of pitfalls, one being addressed in https://review.openstack.org/#/c/195783/ ) I understand that nova already has function to isolate resources for each tenant and the functional improvements is in progress. I will watch this blueprint and try to check AggregateMultiTenancyIsolation filter. https://review.openstack.org/#/c/195783/ Nova litterally knows nothing about Regions, that's a pure Keystone concept. From my perspective, you just have to make sure that your tenants are per region, you don't really need more to have the tenancy segregation at the region level. Caution, I'm not a Keystone expert. We had assumed that system configuration is single horizon and single keystone and multiple regions. In this case, a tenant has resources at all regions. My proposal is this precondition. Thanks. -Original Message- From: Sylvain Bauza [mailto:sba...@redhat.com] Sent: Friday, July 17, 2015 6:25 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova]Proposal for function to manage the resources available to each tenant Le 17/07/2015 10:42, Kenji Ishii a écrit : Hello! Please give me opinion in terms to be a valuable function for OpenStack Community. We believe that we need a mechanism to easily manage the resources available to the each tenant. In some case, we want to allow only the specific tenant to use the specific resources. We think the two architectures of the following. a. New concept called vDC vDC is virtual DC. It means collection of several logical resources : Availavility Zone(AZ). If we use it, we can control the resources to each tenant. For example, ___vDC_1 ___vDC_2 || || | AZ1, AZ2 | | AZ3 | || || tenant tenant_001 assigned vDC_1 tenant tenant_002 assigned vDC_2 tenant_001 can use AZ1 and AZ2, AZ3 is unavailable. tenant_002 can use AZ3 , AZ1 and AZ2 is unavailable. Not sure I fully understand but AggregateMultiTenancyIsolation filter already partially does the job (with a certain number of pitfalls, one being addressed in https://review.openstack.org/#/c/195783/ ) b. use region It will manage the relation between the Region and the tenant. The tenant can use only the resources in region that be allowed it to use. By the way, this proposal is several problems - Cost of system construction is higher than proposal a etc Nova litterally knows nothing about Regions, that's a pure Keystone concept. From my perspective, you just have to make sure that your tenants are per region, you don't really need more to have the tenancy segregation at the region level. Caution, I'm not a Keystone expert. -Sylvain each proposal's detail is following. https://wiki.openstack.org/wiki/Proposal_vDC -- Kenji Ishii __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kenji Ishii __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Exposing provider networks in network_data.json
On 17 July 2015 at 11:23, Sean Dague s...@dague.net wrote: On 07/16/2015 06:06 PM, Sean M. Collins wrote: On Thu, Jul 16, 2015 at 01:23:29PM PDT, Mathieu Gagné wrote: So it looks like there is a missing part in this feature. There should be a way to hide this information if the instance does not require to configure vlan interfaces to make network functional. I just commented on the review, but the provider network API extension is admin only, most likely for the reasons that I think someone has already mentioned, that it exposes details of the phyiscal network layout that should not be exposed to tenants. So, clearly, under some circumstances the network operator wants to expose this information, because there was the request for that feature. The question in my mind is what circumstances are those, and what additional information needs to be provided here. There is always a balance between the private cloud case which wants to enable more self service from users (and where the users are often also the operators), and the public cloud case where the users are outsiders and we want to hide as much as possible from them. For instance, would an additional attribute on a provider network that says this is cool to tell people about be an acceptable approach? Is there some other creative way to tell our infrastructure that these artifacts are meant to be exposed in this installation? Just kicking around ideas, because I know a pile of gate hardware for everyone to use is at the other side of answers to these questions. And given that we've been running full capacity for days now, keeping this ball moving forward would be great. Maybe we just need to add policy around who gets to see that extra detail, and maybe hide it by default? Would that deal with the concerns here? Thanks, John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
On Jul 17, 2015, at 04:36, Victor Stinner vstin...@redhat.com wrote: Le 16/07/2015 22:28, Thomas Goirand a écrit : IMO, we should, for the Liberty release, get rid of: - suds suds-jurko suds was replaced with suds-jurko (in oslo.vmware, cinder, nova): I kicked suds off of global requirements. - memcached (in the favor of pymemcache) As I wrote, I may fork python-memcached. It's just not in my priority list right now. Pymemcached would be my choice instead of forking this project. However, pymemcached is missing multiple server connections and key/hash ring capabilities (afaik there is a pull request/active development to cover those gaps). FYI some colleagues just forked python-ldap in https://github.com/pyldap/pyldap/ to add Python 3 support. Stay tuned ;-) I highly recommend contributing to the ldap3 project instead of continuing the python-ldap work. Ldap3 is (imho) a much better design and really (if anything) simply lacks a compatibility layer. Keystone will be moving to ldap3 (regardless of the compat module) either this cycle or next. - mysqldb (this has been discussed at large already) MySQL-Python was replaced with PyMySQL in almost all projects, no? Even nova is now using PyMySQL ;-) - cliff-tablib and tablib (not ported to Py3, used only for testing) tablib works on Python 3, but it has a strange way of using dependencies. You can try to remove tablib/packages/markup.py when building the package for Python 3 and it should just work. Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Python 3: 5 more projects with a py34 voting gate, only 4 remaing
On 17 July 2015 at 23:32, Victor Stinner vstin...@redhat.com wrote: Hi, https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1367907 The bug was fixed in Python 3.4 in May 2014 and was reported to Ubuntu in September 2014. I've just queried and its apparently in review-wait in the Ubuntu trusty upload queue; I'll try to find out if there any unexpected delays there etc. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Thierry, +1 from me. We could just use a wiki to track work or upstream PR/reviews for now. -- dims On Fri, Jul 17, 2015 at 7:40 AM, Thierry Carrez thie...@openstack.org wrote: Davanum Srinivas wrote: Sounds like a great idea Thierry! Any concrete deliverables you have in mind for this group? I don't think that team would use a specific repository. More like agree on a set of objectives to reach in a given cycle, like the list Thomas came up with. If one ends up being a lot of work, optionally turn that into a cross-project spec. Then propose and babysit the changes to make those happen. Have regular meetings to track progress and split the work. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library
Alex, Gathering upstream modules certainly should be implemented as a separate script so as to make it possible to use it wherever we need this (tests, builds, etc.) According to builds there are two things 1) We have so called perestroika package build system (Dmitry Burmistrov is a main contributor here). By the end of next week we are going to switch building all the packages to perestroika. And in order to gather upstream modules right before building fuel-library package, we need to change perestroika build scripts. 2) Currently we build packages using make system and you are right about the place where you need to make changes. https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 If you create shell script, I'll help you to add it to make code. Vladimir Kozhukalov On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko adide...@mirantis.com wrote: I believe build_repo function is the best way to do this [0]. So for fuel-library we'll need to run a shell script right from the repo before 'touch $$@'. We can make it either conditional ( test -f ./path/additional_build_script.sh bash ./path/additional_build_script.sh ) or as additional parameter to function and add it in fuel-library call [1] Regards, Alex [0] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L16-L37 [1] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L45 On Fri, Jul 17, 2015 at 2:37 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Alex, On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, I think that we should provide a separate script that will fetch the upstream modules into fuel-library/deployment/puppet/ directory. It will allow us to have everything in a single place and use this script in ISO build process and CI jobs. Right. That is what I'm going for. The issue I need help with is the best way to execute this as part of the build process. From what i understand of the build process is that we are using git archive for all pieces so I'm not sure how to wedge in an extra script execution to do the module fetch. The creation of the script isn't the issue, the issue is how can I properly run it as part of the build process. Regards, Alex Thanks, -Alex On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz aschu...@mirantis.com wrote: Hello everyone, I have committed the initial configuration required to start leveraging librarian-puppet as part of the way we pull in upstream puppet modules[0]. Additionally, I have also committed a change that would pull in the openstack-ironic module[1]. The one piece that is missing from this being a complete solution is the ability to run librarian-puppet as part of our build process for the fuel-library. I've looked into the fuel-main build scripts and I think it's over my head to figure this out just by looking. Can anyone explain to me or assist me in how I could go about modifying the existing build system to be able to run librarian-puppet to prepare the source for the package? In my initial investigation, it looks like it would be a modification of the fuel-main/packages/module.mk[3] file. I basically need to do the prepare_library[3] function from the 202763 review[0] after we've pulled all the sources together to fetch the upstream modules. Thanks, -Alex [0] https://review.openstack.org/202763 [1] https://review.openstack.org/202767 [2] https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 [3] https://review.openstack.org/#/c/202763/1/utils/jenkins/fuel_noop_tests.rb __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [all][ptl][release] New library release request process
On Fri, Jul 17, 2015 at 3:02 AM, Thierry Carrez thie...@openstack.org wrote: Doug Hellmann wrote: Excerpts from Anne Gentle's message of 2015-07-16 08:14:54 -0500: On Thu, Jul 16, 2015 at 6:58 AM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Andreas Jaeger's message of 2015-07-16 08:11:48 +0200: Doug, I'm missing openstackdocstheme and openstack-doc-tools in your import. How do you want to handle these? One sticking point with these tools is that they don't fit into our current definition of a deliverable, which is N repos that share a launchpad project and version number. My non-technical definition for a deliverable (or a thing we release) is a produce of the project team that is intended to be used by others, and therefore new releases need to be published and communicated. Since it is meant to be used by others, those should also have a Launchpad project so that users can report issues with it. So the question here is more: are openstackdocstheme and openstack-doc-tools products of the Documentation project team that are intended to be used outside of that team. If the answer is yes then they should have a Launchpad project and be considered a deliverable. If the answer is no then while they may have tags, they don't really need releases or direct user feedback, so the Launchpad project may be overkill. openstack-doc-tools seems to lean in the yes direction, I could find it used by a couple projects in test-requirements. openstackdocstheme seems to be used only in infra, so I guess it could go either way. I'm not really sure what releases/tags achieve there... 1. Create separate launchpad projects for each of them, so they can be managed independently like the other projects. Okay, we currently track both of these with the openstack-manuals project in Launchpad but it's fine to create separate Launchpad projects for each. 2. Start releasing and versioning them together. No reason for this really that I can think of. 3. Add support for a deliverable type with no launchpad project, which would skip the launchpad updates. Would a single Launchpad project work for both, or not? Thanks, Anne I like option 1, with 3 being a fallback. I don't really see option 2 as viable. What does everyone else think? Following my train of thoughts from the deliverable definition above, option 1 is the only that makes sense (with option 2 as a backup, but that would not be a good fit in this particular case). -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Anne Gentle Rackspace Principal Engineer www.justwriteclick.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][api] New API Guidelines read for cross project review
On 07/17/2015 05:50 AM, Thierry Carrez wrote: michael mccune wrote: hey all, we have 4 API Guidelines that are ready for final review. 1. Add generic name of each project for terms https://review.openstack.org/#/c/196918/ 2. Add new guideline for HTTP Headers https://review.openstack.org/#/c/186526/ 3. Adds guidance on request bodies with different Methods https://review.openstack.org/#/c/184358/ 4. Adding 5xx guidance https://review.openstack.org/#/c/183698/ if the API Working Group hasn't received any further feedback, we'll merge them on July 23. Note that we won't be having a cross-project meeting on July 21st, so these won't get the opportunity to get discussed in that forum. So you might want to delay that final approval for an extra week... Your call. thanks Thierry, i don't think it will hurt to wait an extra week. mike __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball
Matt, Thanks for noting this. My understanding of the problem is that we should put openstack.yaml into a separate package build from fuel-web repository. When a user installs fuel-upgrade package it requires openstack.yaml package of necessary version to be also installed. Another idea here is that we don't need this upgrade script at all. Our docker containers are stateless, so the upgrade flow is going to be significantly simpler in 7.0. But still we have quite a few things like create links, move files, backup database, etc. which makes this idea a little bit premature. Maybe a little bit later. Ok, let's stop merging any code into fuel-web/fuel_upgrade_system/fuel_upgrade since now. All patches, which are not merged yet (I doubt we have any) should be ported to the new repository which is going to be created once this patch [1] is merged. [1] https://review.openstack.org/#/c/202541/ Vladimir Kozhukalov On Fri, Jul 17, 2015 at 12:03 AM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, Let's put openstack.yaml to package if it requires for master node upgrade. Environment update part should be removed as it never reached production state. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Thu, Jul 16, 2015 at 8:07 AM, Matthew Mosesohn mmoses...@mirantis.com wrote: One item that will impact this separation is that fuel_upgrade implicitly depends on the openstack.yaml release file from fuel-nailgun. Without it, the upgrade process won't work. We should refactor fuel-nailgun to implement this functionality on its own, but then have fuel_upgrade call this piece. Right now, we're copying the openstack.yaml for the target version of Fuel and embedding it in the tarball[1]. Instead, the version should be taken from the new version of fuel-nailgun that is installed inside the nailgun container. The other file which gets embedded in the upgrade tarball is the version.yaml file, but I think that's okay to embed during RPM build. [1] https://github.com/stackforge/fuel-web/blob/master/fuel_upgrade_system/fuel_upgrade/fuel_upgrade/engines/openstack.py#L211-L213 On Thu, Jul 16, 2015 at 3:55 PM, Oleg Gelbukh ogelb...@mirantis.com wrote: Vladimir, Good, thank you for extended answer. -- Best regards, Oleg Gelbukh On Thu, Jul 16, 2015 at 3:30 PM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Oleg, Yes, you are right. At the moment all docker containers are packaged into a single rpm package. Yes, it would be great to split them into several one-by-one rpms, but it is not my current priority. I'll definitely think of this when I'll be moving so called late packages (which depend on other packages) into perestroika. Yet another thing is that eventually all those packages and containers will be artifacts and will be treated differently according to their nature. That will be the time when we'll be thinking of a docker registry and other stuff like this. Vladimir Kozhukalov On Thu, Jul 16, 2015 at 2:58 PM, Oleg Gelbukh ogelb...@mirantis.com wrote: Vladimir, Thank you, now it sounds concieving. My understanding that at the moment all Docker images used by Fuel are packaged in single RPM? Do you plan to split individual images into separate RPMs? Did you think about publishing those images to Dockerhub? -- Best regards, Oleg Gelbukh On Thu, Jul 16, 2015 at 1:50 PM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Oleg, All docker containers currently are distributed as rpm packages. A little bit surprising, isn't it? But it works and we can easily deliver updates using this old plain rpm based mechanism. The package in 6.1GA is called fuel-docker-images-6.1.0-1.x86_64.rpm So, upgrade flow would be like this 0) add new (say 7.0) repository into /etc/yum.repos.d/some.repo 1) install fuel-upgrade package (yum install fuel-upgrade-7.0) 2) fuel-upgrade package has all other packages (docker, bootstrap image, target images, puppet modules) as its dependencies 3) run fuel-upgrade script (say /usr/bin/fuel-upgrade) and it performs all necessary actions like moving files, run new containers, upload fixtures into nailgun via REST API. It is necessary to note that we are talking here about Fuel master node upgrades, not about Openstack cluster upgrades (which is the feature you are working on). Vladimir Kozhukalov On Thu, Jul 16, 2015 at 1:22 PM, Oleg Gelbukh ogelb...@mirantis.com wrote: Vladimir, I am fully support moving fuel-upgrade-system into repository of its own. However, I'm not 100% sure how docker containers are going to appear on the upgraded master node. Do we have public repository of Docker images already? Or we are going to build them from scratch during the upgrade? -- Best regards, Oleg Gelbukh On Thu, Jul 16, 2015 at 11:46 AM, Vladimir Kozhukalov
Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules
Hello guys, Update 'make iso' scripts: * Make them use 'r10k' (or other tool) to download upstream modules based on 'Puppetfile' I foreseen holywars with our Build team. AFAIK they are deeply concerned about Internet access during ISO build process. Hence, they'll propose to package upstream puppet manifests, and that can complicate our experience to work with upstream flexibly. Thanks, Igor On Thu, Jul 16, 2015 at 11:55 PM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, On Thu, Jul 16, 2015 at 9:01 AM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, guys, what if we simplify things a bit? All we need is: Remove all the community modules from fuel-library. Create 'Puppetfile' with list of community modules and their versions that we currently use. Make sure all our customizations are proposed to the upstream modules (via gerrit or github pull-requests). Create a separate file with list of patches for each module we need to cherry-pick (we need to support gerrit reviews and github pull-requests). Update 'make iso' scripts: Make them use 'r10k' (or other tool) to download upstream modules based on 'Puppetfile' I am giving +1 to librarian here. Iterate over list of patches for each module and cherry-pick them (just like we do for custom ISO build. I'm not sure if librarian provides such possibility) Puppetlabs is in transition of moving all modules to openstack. We may use pull-requests here just specifying repository. However, I am thinking about hacking librarian to add cherry-pick option. Eventually, when all the functionality we rely on is accepted in upstream modules, we'll get rid of file with list of patches for modules. But meanwhile it should be much easier to manage modules and customization in such way. Regards, Alex On Fri, Jul 10, 2015 at 5:25 PM, Alex Schultz aschu...@mirantis.com wrote: Done. Sorry about that. -Alex On Fri, Jul 10, 2015 at 9:22 AM, Simon Pasquier spasqu...@mirantis.com wrote: Alex, could you enable the comments for all on your document? Thanks! Simon On Thu, Jul 9, 2015 at 11:07 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote: Hello everyone, I took some time this morning to write out a document[0] that outlines one possible ways for us to manage our upstream modules in a more consistent fashion. I know we've had a few emails bouncing around lately around this topic of our use of upstream modules and how can we improve this. I thought I would throw out my idea of leveraging librarian-puppet to manage the upstream modules within our fuel-library repository. Ideally, all upstream modules should come from upstream sources and be removed from the fuel-library itself. Unfortunately because of the way our repository sits today, this is a very large undertaking and we do not currently have a way to manage the inclusion of the modules in an automated way. I believe this is where librarian-puppet can come in handy and provide a way to manage the modules. Please take a look at my document[0] and let me know if there are any questions. Thanks, -Alex [0] https://docs.google.com/document/d/13aK1QOujp2leuHmbGMwNeZIRDr1bFgJi88nxE642xLA/edit?usp=sharing The document is great, Alex! I'm fully support the idea to start adapting fuel-library by the suggested scheme. The monitoring feature of ibrarian looks not intrusive and we have no blockers to start using the librarian just immediately. -- Best regards, Bogdan Dobrelya, Irc #bogdando __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Aligning LP groups with real teams
Hello, Here's my +2 on this. :) BTW, any chance we can somehow to reduce spam emails when some bug was assigned to another team? For instance, I see email notifications when bug's assigned to fuel-library. Thanks, Igor On Fri, Jul 17, 2015 at 4:16 PM, Tatyana Leontovich tleontov...@mirantis.com wrote: Hi, Alex vote +1 to use astute tag as well to get possibility identify issues related to astute in the most easy way. Regards, Tanya On Fri, Jul 17, 2015 at 3:59 PM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, as we decided on the recent Fuel weekly IRC meeting, we need to align LP fuel-* groups with our teams and bug confirmation queues/duties. We decided to start with fuel-astute [0] and fuel-provsioning [1] LP groups that have 2 members each. So from now on please assign bugs about provisioning and astute to fuel-python [2] LP gorup and add 'ibp' tag for bugs about provisioning. Guys from fuel-python, please pay attention to bug tags. If you're the SME for 'ibp', please take a look at 'ibp' bugs first. Btw should we also use 'astute' tag for the same purpose? Also we need someone to delete fuel-astute and fuel-provisioning groups from LP, if there are no objections. Regards, Alex [0] https://launchpad.net/~fuel-astute/+members#active [1] https://launchpad.net/~fuel-provisioning/+members#active [2] https://launchpad.net/~fuel-python/+members#active __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] Aligning LP groups with real teams
Hi, as we decided on the recent Fuel weekly IRC meeting, we need to align LP fuel-* groups with our teams and bug confirmation queues/duties. We decided to start with fuel-astute [0] and fuel-provsioning [1] LP groups that have 2 members each. So from now on please assign bugs about provisioning and astute to fuel-python [2] LP gorup and add 'ibp' tag for bugs about provisioning. Guys from fuel-python, please pay attention to bug tags. If you're the SME for 'ibp', please take a look at 'ibp' bugs first. Btw should we also use 'astute' tag for the same purpose? Also we need someone to delete fuel-astute and fuel-provisioning groups from LP, if there are no objections. Regards, Alex [0] https://launchpad.net/~fuel-astute/+members#active [1] https://launchpad.net/~fuel-provisioning/+members#active [2] https://launchpad.net/~fuel-python/+members#active __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Aligning LP groups with real teams
Hi, Alex vote +1 to use astute tag as well to get possibility identify issues related to astute in the most easy way. Regards, Tanya On Fri, Jul 17, 2015 at 3:59 PM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, as we decided on the recent Fuel weekly IRC meeting, we need to align LP fuel-* groups with our teams and bug confirmation queues/duties. We decided to start with fuel-astute [0] and fuel-provsioning [1] LP groups that have 2 members each. So from now on please assign bugs about provisioning and astute to fuel-python [2] LP gorup and add 'ibp' tag for bugs about provisioning. Guys from fuel-python, please pay attention to bug tags. If you're the SME for 'ibp', please take a look at 'ibp' bugs first. Btw should we also use 'astute' tag for the same purpose? Also we need someone to delete fuel-astute and fuel-provisioning groups from LP, if there are no objections. Regards, Alex [0] https://launchpad.net/~fuel-astute/+members#active [1] https://launchpad.net/~fuel-provisioning/+members#active [2] https://launchpad.net/~fuel-python/+members#active __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Nailgun agent core reviewers nomination
+1 On Fri, Jul 17, 2015 at 5:43 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: +1 On Thu, Jul 16, 2015 at 8:57 AM Sergii Golovatiuk sgolovat...@mirantis.com wrote: +1 -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Thu, Jul 16, 2015 at 10:20 AM, Vladimir Sharshov vshars...@mirantis.com wrote: Hi, we have created separate project for fuel-nailgun-agent. At now moment only i have core-reviewer rights.We hardly need more core reviewers here. I want to nominate Vladimir Kozhukalov to fuel-nailgun-agent core. At now moment Vladimir is one of the main contributor in nailgun-agent. Please reply with +1/-1. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Nailgun agent core reviewers nomination
+1 On Fri, Jul 17, 2015 at 4:20 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: +1 On Fri, Jul 17, 2015 at 5:43 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: +1 On Thu, Jul 16, 2015 at 8:57 AM Sergii Golovatiuk sgolovat...@mirantis.com wrote: +1 -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Thu, Jul 16, 2015 at 10:20 AM, Vladimir Sharshov vshars...@mirantis.com wrote: Hi, we have created separate project for fuel-nailgun-agent. At now moment only i have core-reviewer rights.We hardly need more core reviewers here. I want to nominate Vladimir Kozhukalov to fuel-nailgun-agent core. At now moment Vladimir is one of the main contributor in nailgun-agent. Please reply with +1/-1. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Morgan Fainberg wrote: On Jul 17, 2015, at 04:36, Victor Stinnervstin...@redhat.com wrote: Le 16/07/2015 22:28, Thomas Goirand a écrit : IMO, we should, for the Liberty release, get rid of: - suds suds-jurko suds was replaced with suds-jurko (in oslo.vmware, cinder, nova): I kicked suds off of global requirements. - memcached (in the favor of pymemcache) As I wrote, I may fork python-memcached. It's just not in my priority list right now. Pymemcached would be my choice instead of forking this project. However, pymemcached is missing multiple server connections and key/hash ring capabilities (afaik there is a pull request/active development to cover those gaps). Not anymore! https://github.com/pinterest/pymemcache/commit/63a2d960 Merged '14 hours ago' ;) Now it just needs to be released :-P FYI some colleagues just forked python-ldap in https://github.com/pyldap/pyldap/ to add Python 3 support. Stay tuned ;-) I highly recommend contributing to the ldap3 project instead of continuing the python-ldap work. Ldap3 is (imho) a much better design and really (if anything) simply lacks a compatibility layer. Keystone will be moving to ldap3 (regardless of the compat module) either this cycle or next. - mysqldb (this has been discussed at large already) MySQL-Python was replaced with PyMySQL in almost all projects, no? Even nova is now using PyMySQL ;-) - cliff-tablib and tablib (not ported to Py3, used only for testing) tablib works on Python 3, but it has a strange way of using dependencies. You can try to remove tablib/packages/markup.py when building the package for Python 3 and it should just work. Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library
Hey Vladimir, On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Gathering upstream modules certainly should be implemented as a separate script so as to make it possible to use it wherever we need this (tests, builds, etc.) According to builds there are two things 1) We have so called perestroika package build system (Dmitry Burmistrov is a main contributor here). By the end of next week we are going to switch building all the packages to perestroika. And in order to gather upstream modules right before building fuel-library package, we need to change perestroika build scripts. 2) Currently we build packages using make system and you are right about the place where you need to make changes. https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 If you create shell script, I'll help you to add it to make code. I have updated my review[0] to extract the update logic to it's own bash script that can be invoked by the build scripts. Let me know what would be the best way to wedge this in there. I think for the perestroika this would also be needed for the fuel-library build, so if you point me at that I can see if I can help make that change as well. Thanks, -Alex [0] https://review.openstack.org/#/c/202763/ Vladimir Kozhukalov On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko adide...@mirantis.com wrote: I believe build_repo function is the best way to do this [0]. So for fuel-library we'll need to run a shell script right from the repo before 'touch $$@'. We can make it either conditional ( test -f ./path/additional_build_script.sh bash ./path/additional_build_script.sh ) or as additional parameter to function and add it in fuel-library call [1] Regards, Alex [0] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L16-L37 [1] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L45 On Fri, Jul 17, 2015 at 2:37 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Alex, On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, I think that we should provide a separate script that will fetch the upstream modules into fuel-library/deployment/puppet/ directory. It will allow us to have everything in a single place and use this script in ISO build process and CI jobs. Right. That is what I'm going for. The issue I need help with is the best way to execute this as part of the build process. From what i understand of the build process is that we are using git archive for all pieces so I'm not sure how to wedge in an extra script execution to do the module fetch. The creation of the script isn't the issue, the issue is how can I properly run it as part of the build process. Regards, Alex Thanks, -Alex On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz aschu...@mirantis.com wrote: Hello everyone, I have committed the initial configuration required to start leveraging librarian-puppet as part of the way we pull in upstream puppet modules[0]. Additionally, I have also committed a change that would pull in the openstack-ironic module[1]. The one piece that is missing from this being a complete solution is the ability to run librarian-puppet as part of our build process for the fuel-library. I've looked into the fuel-main build scripts and I think it's over my head to figure this out just by looking. Can anyone explain to me or assist me in how I could go about modifying the existing build system to be able to run librarian-puppet to prepare the source for the package? In my initial investigation, it looks like it would be a modification of the fuel-main/packages/module.mk[3] file. I basically need to do the prepare_library[3] function from the 202763 review[0] after we've pulled all the sources together to fetch the upstream modules. Thanks, -Alex [0] https://review.openstack.org/202763 [1] https://review.openstack.org/202767 [2] https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 [3] https://review.openstack.org/#/c/202763/1/utils/jenkins/fuel_noop_tests.rb __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [Neutron] Concern about networking-sfc and community process
On Thu, Jul 16, 2015 at 8:39 PM, Sean M. Collins s...@coreitpro.com wrote: Hi Cathy, You recently merged the following patch, by +2'ing and then Workflow+1'ing it, without allowing reviewers the chance to look at the changes between the patchset where there were -1's and the newer patchsets. https://review.openstack.org/#/c/192933/ I do see that you were asking on -infra about the mechanics of how to merge a patch http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2015-07-16.log.html#t2015-07-16T23:54:03 Just because a core member has given it a +2 and the Neutron PTL had +2'd a previous patch, doesn't mean that you should go ahead and unilaterally approve your own patch. That's not a way to build a commmunity project. I agree with Sean here. The patch merged with only a single +2, and if the other comments were not addressed earlier, they need to be addressed with a followup patch (and reply on this email thread with the patch), or we should revert the commit and address them there. Thanks, Kyle -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [keystone] Request for spec freeze execption
Hi Role assignment inheritance has been an extension in Keystone for a number of cycle. With the introduction of project hierarchies (which also support assignment inheritance), we’d like to move inheritance into core. At the same time as the move to core, we’d like to modify the way inheritance rules are applied. When assignment inheritance was first introduced, it was designed for domain-project inheritance - and under that model, the rule was that an inherited role assigned to the domain would be applied to all the projects in the domain, but not to the domain itself. Now that we have generalised project hierarchies, this seem to make a lot less sense…and the more standard model of the assignment being applied to its target and all the targets sub-projects makes more sense. The proposal is, therefore, that the API we support in core (which is, by definition, different from the one in OS-INHERIT extension), will support this new model, but we will, for backward compatibility, continue to support the old extension (with the old model of inheritance), marked as deprecate, with removal no sooner than 4 cycles. Although probably not recommended from an operations usability point of view, there would be no issue mixing and matching assignments both from the core API and the extension API, during the deprecation period. The spec for this change can be found here: https://review.openstack.org/#/c/200434 At the next keystone IRC meeting, I’d like to discuss granting a spec freeze exception to allow this move to core. Henry __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [os-ansible-deployment] Core nomination for Matt Kassawara (sam-i-am)
Hello all, I would like to nominate Matt Kassawara (IRC: sam-i-am) to the OpenStack Ansible deployment core team. Matt has been instrumental in building out our current install and use documentation[0], he is just about always in the community channel(s) helping folks, is a great technical resource for all things networking / OpenStack, and is one of the main people we already rely on to ensure we're documenting the right things in the right places. IMHO, its about time he be given Core powers within the OSAD project. Please respond with +1/-1s and or any other concerns. As a reminder, we are using the voting process outlined at [ https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess ] to add members to our core team. -- Kevin Carter IRC: cloudnull [0] https://review.openstack.org/#/q/owner:%22Matthew+Kassawara%22+status:merged+project:stackforge/os-ansible-deployment,n,z __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [os-ansible-deployment] Core nomination for Matt Kassawara (sam-i-am)
I am +1. Matt's been a huge help with his contributions to our documentation and guides, both in actual commits and reviews. From: Kevin Carter kevin.car...@rackspace.com Sent: Friday, July 17, 2015 11:14 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [os-ansible-deployment] Core nomination for Matt Kassawara (sam-i-am) Hello all, I would like to nominate Matt Kassawara (IRC: sam-i-am) to the OpenStack Ansible deployment core team. Matt has been instrumental in building out our current install and use documentation[0], he is just about always in the community channel(s) helping folks, is a great technical resource for all things networking / OpenStack, and is one of the main people we already rely on to ensure we're documenting the right things in the right places. IMHO, its about time he be given Core powers within the OSAD project. Please respond with +1/-1s and or any other concerns. As a reminder, we are using the voting process outlined at [ https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess ] to add members to our core team. -- Kevin Carter IRC: cloudnull [0] https://review.openstack.org/#/q/owner:%22Matthew+Kassawara%22+status:merged+project:stackforge/os-ansible-deployment,n,z __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Concern about networking-sfc and community process
On the top of that the co-authors should NOT be voting +2 on their own patch! Edgar From: Kyle Mestery Reply-To: OpenStack Development Mailing List (not for usage questions) Date: Friday, July 17, 2015 at 8:13 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Concern about networking-sfc and community process On Thu, Jul 16, 2015 at 8:39 PM, Sean M. Collins s...@coreitpro.commailto:s...@coreitpro.com wrote: Hi Cathy, You recently merged the following patch, by +2'ing and then Workflow+1'ing it, without allowing reviewers the chance to look at the changes between the patchset where there were -1's and the newer patchsets. https://review.openstack.org/#/c/192933/ I do see that you were asking on -infra about the mechanics of how to merge a patch http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2015-07-16.log.html#t2015-07-16T23:54:03 Just because a core member has given it a +2 and the Neutron PTL had +2'd a previous patch, doesn't mean that you should go ahead and unilaterally approve your own patch. That's not a way to build a commmunity project. I agree with Sean here. The patch merged with only a single +2, and if the other comments were not addressed earlier, they need to be addressed with a followup patch (and reply on this email thread with the patch), or we should revert the commit and address them there. Thanks, Kyle -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates
Nicely put, Doug, you gave me laughs :) I can't see how a CR could hang for a month without anyone paying attention if it worths merging. If this really happens (which I'm not aware of), auto-abandon definitely won't make things any worse. -- Best regards, Oleg Gelbukh On Fri, Jul 17, 2015 at 6:10 AM, Doug Wiegley doug...@parksidesoftware.com wrote: Just adding an experience from another project, Neutron. We had similar debates, and prepping for the long apocalyptic winter of changeset death, Kyle decimated the world and ran the abandon script. The debates were far more intense than the reality, and my large stockpile of Rad-X and Nuka Cola went to waste. Every few weeks, I get a few emails of things being abandoned. And if I care about something, mine or not, I click through and tap ‘Restore’. If one person in the entire community can’t be bothered to click one button, I’m not sure how it’d ever be kept up-to-date, much less merge. Thanks, doug On Jul 16, 2015, at 8:36 PM, Dmitry Borodaenko dborodae...@mirantis.com wrote: I'm with Stanislaw on this one: abandoning reviews just to make numbers *look* better will accomplish nothing. The only benefit I can see is cleaning up reviews that we *know* don't need to be considered, so that it's easier for reviewers to find the reviews that still need attention. I don't see this as that much of a problem, finding stuff to review in Fuel Review Inbox [0] is not hard at all. [0] https://wiki.openstack.org/wiki/Fuel#Development_related_links And the state of our review backlog is such that it's not safe to auto-abandon reviews without looking at them, and if a contributor has spent time looking at a review, abandoning it manually is one click away. If we do go with setting up an auto-abandon rule, it should be extremely conservative, for example: CR has a negative vote from a core reviewer AND there were no comments or positive votes from anyone after that AND it has not been touched in any way for 2 months. On Wed, Jul 15, 2015 at 5:10 PM Mike Scherbakov mscherba...@mirantis.com wrote: Folks, let's execute here. Numbers are still large. Did we have a chance to look over the whole queue? Can we go ahead and abandon changes having -1 or -2 from reviewers for over than a months or so? I'm all for just following standard OpenStack process [1], and then change it only if there is good reason for it. [1] https://wiki.openstack.org/wiki/Puppet#Patch_abandonment_policy On Thu, Jul 9, 2015 at 6:27 PM Stanislaw Bogatkin sbogat...@mirantis.com wrote: 2 weeks seems too small for me. We easy can be in situation when fix for medium bug is done, but SCF starts. And gap between SCF and release easily can be more than a month. So, 2 months seems okay for me if speaking about forcibly applying auto-abandon by major vote. And I'm personally against such innovation at all. On Thu, Jul 9, 2015 at 5:37 PM, Davanum Srinivas dava...@gmail.com wrote: That's a very good plan (Initial feedback/triage) Mike. thanks, dims On Thu, Jul 9, 2015 at 3:23 PM, Mike Scherbakov mscherba...@mirantis.com wrote: +1 for just reusing existing script, and adjust it on the way. No need to immediately switch from infinite time to a couple of weeks, we can always adjust it later. But 1-2 month should be a good start already. Our current stats [1] look just terrible. Before we enable an auto-abandon, we need to go every single patch first, and review it / provide comment to authors. The idea is not to abandon some good patches, and not to offend contributors... Let's think how we can approach it. Should we have core reviewers to check their corresponding components? [1] http://stackalytics.com/report/reviews/fuel-group/open On Wed, Jul 8, 2015 at 1:13 PM Sean M. Collins s...@coreitpro.com wrote: Let's keep it at 4 weeks without comment, and Jenkins failed - similar to the script that Kyle Mestery uses for Neutron. In fact, we could actually just use his script ;) https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims
Re: [openstack-dev] [Nova][infra][third-party] Intel actively seeking solution to CI issue and getting close to a solution
Yes, Anita. We are seeking the alternatives to fix it and hope the CIs can be recovered very soon. Also please allow me to explain a little bit, we shut down the service without any email notification, but update the wiki (https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-PCI-CI) only according to the suggestion from the Infra team. [09:18:52] anteaya then if anyone wonders what is happening with your system they check the status page [09:18:52] anteaya does that make sense? [09:19:13] anteaya correct [09:19:23] anteaya anytime you need to change the status of your ci [09:19:37] jyuso1 OK,thanks.I [09:19:37] anteaya change it here [09:19:45] jyuso1 I'll change it soon [09:19:49] anteaya and please don't send an email to the mailing list, people won't read it anyway We're going to make the CIs more stable in the future, and in case that any issue happened unexpectedly, we will let the community know. Sorry for inconvenience and thank you for your understanding. Best Regards. -- Shane -Original Message- From: Anita Kuno [mailto:ante...@anteaya.info] Sent: Thursday, July 16, 2015 10:34 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova][infra][third-party] Intel actively seeking solution to CI issue and getting close to a solution On 07/15/2015 10:19 PM, yongli he wrote: Hello OpenStackers! The Intel PCI/SRIOV/NGFW/PTAS CI located in China, due to reasons beyond our control, lost connectivity to the Jenkins servers. The great firewall of China is making quite a few folks unhappy. Although the CI system is working fine we haven't been able to report results back for about a month now. We are actively looking for a solution to this problem. Currently we are seeking a VM in AWS or similar public cloud to hold our CI logs, Have you taken a look at any of the fine offerings from companies who operate OpenStack public clouds? http://www.openstack.org/marketplace/public-clouds/ which will quickly give us a short term solution. For a longer term solution we are exploring moving to machines located in the US. Sorry for the inconvenience and your patience. Regards Yongli Thanks Yongli, Anita. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Proposing Cedric Brandily to Neutron Core Reviewer Team
+1 On Thu, Jul 16, 2015 at 1:47 AM, Oleg Bondarev obonda...@mirantis.com wrote: +1 On Thu, Jul 16, 2015 at 2:04 AM, Brian Haley brian.ha...@hp.com wrote: +1 On 07/15/2015 02:47 PM, Carl Baldwin wrote: As the Neutron L3 Lieutenant along with Kevin Benton for control plane, and Assaf Muller for testing, I would like to propose Cedric Brandily as a member of the Neutron core reviewer team under these areas of focus. Cedric has been a long time contributor to Neutron showing expertise particularly in these areas. His knowledge and involvement will be very important to the project. He is a trusted member of our community. He has been reviewing consistently [1][2] and community feedback that I've received indicates that he is a solid reviewer. Existing Neutron core reviewers from these areas of focus, please vote +1/-1 for the addition of Cedric to the team. Thanks! Carl Baldwin [1] https://review.openstack.org/#/q/reviewer:zzelle%2540gmail.com,n,z [2] http://stackalytics.com/report/contribution/neutron-group/90 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Le 16/07/2015 22:28, Thomas Goirand a écrit : IMO, we should, for the Liberty release, get rid of: - suds suds-jurko suds was replaced with suds-jurko (in oslo.vmware, cinder, nova): I kicked suds off of global requirements. - memcached (in the favor of pymemcache) As I wrote, I may fork python-memcached. It's just not in my priority list right now. FYI some colleagues just forked python-ldap in https://github.com/pyldap/pyldap/ to add Python 3 support. Stay tuned ;-) - mysqldb (this has been discussed at large already) MySQL-Python was replaced with PyMySQL in almost all projects, no? Even nova is now using PyMySQL ;-) - cliff-tablib and tablib (not ported to Py3, used only for testing) tablib works on Python 3, but it has a strange way of using dependencies. You can try to remove tablib/packages/markup.py when building the package for Python 3 and it should just work. Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][ptl][release] New library release request process
On 07/17/2015 10:19 AM, Andreas Jaeger wrote:
[...]
I agree, we treat them as deliverables, so let me setup launchpad
projects for these...
Created,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][ptl][release] New library release request process
On 07/17/2015 10:02 AM, Thierry Carrez wrote:
Doug Hellmann wrote:
Excerpts from Anne Gentle's message of 2015-07-16 08:14:54 -0500:
On Thu, Jul 16, 2015 at 6:58 AM, Doug Hellmann d...@doughellmann.com
wrote:
Excerpts from Andreas Jaeger's message of 2015-07-16 08:11:48 +0200:
Doug,
I'm missing openstackdocstheme and openstack-doc-tools in your import.
How do you want to handle these?
One sticking point with these tools is that they don't fit into our
current definition of a deliverable, which is N repos that share a
launchpad project and version number.
My non-technical definition for a deliverable (or a thing we release)
is a produce of the project team that is intended to be used by others,
and therefore new releases need to be published and communicated.
Since it is meant to be used by others, those should also have a
Launchpad project so that users can report issues with it.
So the question here is more: are openstackdocstheme and
openstack-doc-tools products of the Documentation project team that are
intended to be used outside of that team.
If the answer is yes then they should have a Launchpad project and be
considered a deliverable. If the answer is no then while they may have
tags, they don't really need releases or direct user feedback, so the
Launchpad project may be overkill.
openstack-doc-tools seems to lean in the yes direction, I could find
it used by a couple projects in test-requirements.
It's used by openstack-manuals and similar doc repos and trove for
building and checking of DocBook XML files.
openstackdocstheme seems to be used only in infra, so I guess it could
go either way. I'm not really sure what releases/tags achieve there...
It's used by all doc projects using RST files for documentation:
openstack-manuals, security-doc etc.
Releases are needed for both since we do build from a released version,
and they are used by projects outside of the Documentation team like
trove or security-doc.
We currently handle bugs for these as part of openstack-manuals.
1. Create separate launchpad projects for each of them, so they can be
managed independently like the other projects.
2. Start releasing and versioning them together.
3. Add support for a deliverable type with no launchpad project, which
would skip the launchpad updates.
I like option 1, with 3 being a fallback. I don't really see option 2 as
viable.
What does everyone else think?
Following my train of thoughts from the deliverable definition above,
option 1 is the only that makes sense (with option 2 as a backup, but
that would not be a good fit in this particular case).
I agree, we treat them as deliverables, so let me setup launchpad
projects for these...
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][ptl][release] New library release request process
Doug Hellmann wrote: Excerpts from Anne Gentle's message of 2015-07-16 08:14:54 -0500: On Thu, Jul 16, 2015 at 6:58 AM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Andreas Jaeger's message of 2015-07-16 08:11:48 +0200: Doug, I'm missing openstackdocstheme and openstack-doc-tools in your import. How do you want to handle these? One sticking point with these tools is that they don't fit into our current definition of a deliverable, which is N repos that share a launchpad project and version number. My non-technical definition for a deliverable (or a thing we release) is a produce of the project team that is intended to be used by others, and therefore new releases need to be published and communicated. Since it is meant to be used by others, those should also have a Launchpad project so that users can report issues with it. So the question here is more: are openstackdocstheme and openstack-doc-tools products of the Documentation project team that are intended to be used outside of that team. If the answer is yes then they should have a Launchpad project and be considered a deliverable. If the answer is no then while they may have tags, they don't really need releases or direct user feedback, so the Launchpad project may be overkill. openstack-doc-tools seems to lean in the yes direction, I could find it used by a couple projects in test-requirements. openstackdocstheme seems to be used only in infra, so I guess it could go either way. I'm not really sure what releases/tags achieve there... 1. Create separate launchpad projects for each of them, so they can be managed independently like the other projects. 2. Start releasing and versioning them together. 3. Add support for a deliverable type with no launchpad project, which would skip the launchpad updates. I like option 1, with 3 being a fallback. I don't really see option 2 as viable. What does everyone else think? Following my train of thoughts from the deliverable definition above, option 1 is the only that makes sense (with option 2 as a backup, but that would not be a good fit in this particular case). -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] What does flavor mean for a network?
Aha! Thanks so much for pointing that out. Although actually it's a reminder, and I should have known that already, as I now remember your recent thread about this. So, 100% understood now that flavors aren't intended for networks. I hope that the metaplugin removal change might land quickly now, as it's always nice to clarify the picture by removing obsolete things. Regards, Neil Original Message From: Itsuro ODA Sent: Thursday, 16 July 2015 23:22 To: OpenStack Development Mailing List (not for usage questions) Reply To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] What does flavor mean for a network? Neil, flavor:network is for Metaplugin. It is unrelated to flavor framework. FYI, Metaplugin will be removed in liberty. https://review.openstack.org/#/c/192056/ Thanks. Itsuro Oda (oda-g) On Thu, 16 Jul 2015 10:44:01 +0100 Neil Jerram neil.jer...@metaswitch.com wrote: Thanks everyone for your responses... On 15/07/15 21:01, Doug Wiegley wrote: That begins to looks like nova’s metadata tags and scheduler, which is a valid use case. The underpinnings of flavors could do this, but it’s not in the initial implementation. doug On Jul 15, 2015, at 12:38 PM, Kevin Benton blak...@gmail.com mailto:blak...@gmail.com wrote: Wouldn't it be valid to assign flavors to groups of provider networks? e.g. a tenant wants to attach to a network that is wired up to a 40g router so he/she chooses a network of the fat pipe flavor. Indeed. Otherwise, why does 'flavor:network' exist at all in the current codebase? As the code currently stands, 'flavor:network' appears to be consumed only by agent/linux/interface.py, with the logic that if the interface_driver setting is set to MetaInterfaceDriver, the interface driver class that is actually used for a particular network will be derived by using the network's 'flavor:network' value as a lookup key in the dict specified by the meta_flavor_driver_mappings setting. Is that an intended part of the flavors design? I hope it doesn't sound like I'm just complaining! My reason for asking these questions is that I'm working at https://review.openstack.org/#/c/198439/ on a type of network that works through routing on each compute host instead of bridging, and two of the consequences of that are that (1) there will not be L2 broadcast connectivity between the instances attached to such a network, whereas there would be with all existing Neutron network types (2) the DHCP agent needs some changes to provide DHCP service on unbridged TAP interfaces. Probably best here not to worry too much about the details. But, at a high level: - there is an aspect of the network's behavior that needs to be portrayed in the UI, so that tenants/projects can know when it is appropriate to attach instances to that network - there is an aspect of the network's implementation that the DHCP agent needs to be aware of, so that it can adjust accordingly. I believe the flavor:network 'works', for these purposes, in the senses that it is portrayed in the UI, and that it is available to software components such as the DHCP agent. So I was wondering whether 'flavor:network' would be the correct location in principle for a value identifying this kind of network, according to the intention of the flavors enhancement. On Wed, Jul 15, 2015 at 10:40 AM, Madhusudhan Kandadai madhusudhan.openst...@gmail.com mailto:madhusudhan.openst...@gmail.com wrote: On Wed, Jul 15, 2015 at 9:25 AM, Kyle Mestery mest...@mestery.com mailto:mest...@mestery.com wrote: On Wed, Jul 15, 2015 at 10:54 AM, Neil Jerram neil.jer...@metaswitch.com mailto:neil.jer...@metaswitch.com wrote: I've been reading available docs about the forthcoming Neutron flavors framework, and am not yet sure I understand what it means for a network. In reality, this is envisioned more for service plugins (e.g. flavors of LBaaS, VPNaaS, and FWaaS) than core neutron resources. Yes. Right put. This is for service plugins and its part of extensions than core network resources// Is it a way for an admin to provide a particular kind of network, and then for a tenant to know what they're attaching their VMs to? I'll defer to Madhu who is implementing this, but I don't believe that's the intention at all. Currently, an admin will be able to assign particular flavors, unfortunately, this is not going to be tenant specific flavors. To be clear - I wasn't suggesting or asking for tenant-specific flavors. I only meant that a tenant might choose which network to attach a particular set of VMs to, depending on the flavors of the available networks. (E.g. as in Kevin's example above.) As you might have seen in the review, we are just using tenant_id to bypass the keystone checks implemented in base.py
[openstack-dev] [nova]Proposal for function to manage the resources available to each tenant
Hello! Please give me opinion in terms to be a valuable function for OpenStack Community. We believe that we need a mechanism to easily manage the resources available to the each tenant. In some case, we want to allow only the specific tenant to use the specific resources. We think the two architectures of the following. a. New concept called vDC vDC is virtual DC. It means collection of several logical resources : Availavility Zone(AZ). If we use it, we can control the resources to each tenant. For example, ___vDC_1 ___vDC_2 || || | AZ1, AZ2 | | AZ3 | || || tenant tenant_001 assigned vDC_1 tenant tenant_002 assigned vDC_2 tenant_001 can use AZ1 and AZ2, AZ3 is unavailable. tenant_002 can use AZ3 , AZ1 and AZ2 is unavailable. b. use region It will manage the relation between the Region and the tenant. The tenant can use only the resources in region that be allowed it to use. By the way, this proposal is several problems - Cost of system construction is higher than proposal a etc each proposal's detail is following. https://wiki.openstack.org/wiki/Proposal_vDC -- Kenji Ishii __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] Parameters possible default value
Hello everyone,
Based on the conversation we had during last meeting I went ahead and
created an
ini_setting provider[1] that will act as a proxy between our provider
and the
upstream one, this way we don't have to fork, only overload the method
we want.
The second step towards parameter default management was to provide a
way that
means if 'X' is specified as the value for the provider then ensure it
is absent.
This way we could move from the following pattern :
if $myvar {
keystone_config {'DEFAULT/foo': value = $myvar,
} else {
keystone_config {'DEFAULT/foo': ensure = absent,
}
to a more readable one that would have been
keystone_config {'DEFAULT/foo': value = $myvar, }
that based on the value of $myvar would have ensure absent the parameter.
In a first time the empty string seemed to have been a good idea, so we
could
have default all the parameters to '' (empty string) and live happily
ever after,
if set the value would have been set else it would default to upstream
default.
But Mathieu raised a fair point here[2] is that an empty string for some
settings is a valid value, and hence we can't rely on
it.
Since the beginning we are trying to avoid the use of a magic string, but
I am starting to run out of idea here.
Does someone has an idea on which sane value the default could be ?
Thanks in advance,
[1] https://review.openstack.org/#/c/202488
[2] https://review.openstack.org/#/c/202574
--
Yanis Guenane
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Parameters possible default value
Hey Yanis,
On Fri, Jul 17, 2015 at 3:56 AM, Yanis Guenane yguen...@redhat.com wrote:
Hello everyone,
Based on the conversation we had during last meeting I went ahead and
created an
ini_setting provider[1] that will act as a proxy between our provider
and the
upstream one, this way we don't have to fork, only overload the method
we want.
The second step towards parameter default management was to provide a
way that
means if 'X' is specified as the value for the provider then ensure it
is absent.
This way we could move from the following pattern :
if $myvar {
keystone_config {'DEFAULT/foo': value = $myvar,
} else {
keystone_config {'DEFAULT/foo': ensure = absent,
}
to a more readable one that would have been
keystone_config {'DEFAULT/foo': value = $myvar, }
that based on the value of $myvar would have ensure absent the parameter.
In a first time the empty string seemed to have been a good idea, so we
could
have default all the parameters to '' (empty string) and live happily
ever after,
if set the value would have been set else it would default to upstream
default.
But Mathieu raised a fair point here[2] is that an empty string for some
settings is a valid value, and hence we can't rely on
it.
Does it make sense for undef to be the 'magic' string for this? As '' or
false may be valid settings, but undef currently is basically ignored (or
so I've been told). Would we want to use undef to indicate the removal of
an option from a configuration?
Since the beginning we are trying to avoid the use of a magic string, but
I am starting to run out of idea here.
Does someone has an idea on which sane value the default could be ?
Thanks in advance,
[1] https://review.openstack.org/#/c/202488
[2] https://review.openstack.org/#/c/202574
--
Yanis Guenane
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Thanks,
-Alex
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Exposing provider networks in network_data.json
On Fri, Jul 17, 2015 at 01:06:46PM +0100, John Garbutt wrote: On 17 July 2015 at 11:23, Sean Dague s...@dague.net wrote: On 07/16/2015 06:06 PM, Sean M. Collins wrote: On Thu, Jul 16, 2015 at 01:23:29PM PDT, Mathieu Gagné wrote: So it looks like there is a missing part in this feature. There should be a way to hide this information if the instance does not require to configure vlan interfaces to make network functional. I just commented on the review, but the provider network API extension is admin only, most likely for the reasons that I think someone has already mentioned, that it exposes details of the phyiscal network layout that should not be exposed to tenants. So, clearly, under some circumstances the network operator wants to expose this information, because there was the request for that feature. The question in my mind is what circumstances are those, and what additional information needs to be provided here. There is always a balance between the private cloud case which wants to enable more self service from users (and where the users are often also the operators), and the public cloud case where the users are outsiders and we want to hide as much as possible from them. For instance, would an additional attribute on a provider network that says this is cool to tell people about be an acceptable approach? Is there some other creative way to tell our infrastructure that these artifacts are meant to be exposed in this installation? Just kicking around ideas, because I know a pile of gate hardware for everyone to use is at the other side of answers to these questions. And given that we've been running full capacity for days now, keeping this ball moving forward would be great. Maybe we just need to add policy around who gets to see that extra detail, and maybe hide it by default? Would that deal with the concerns here? I'm not so sure. There are certain Neutron plugins that work with certain virt drivers (Ironic) that require this information to be passed to all instances built by that virt driver. However, it doesn't (and probably shouldn't, as to not confuse cloud-init/etc) need to be passed to other instances. I think the conditional for passing this as metadata is going to need to be some combination of operator config, Neutron config/driver, and virt driver. I know we don't like networking things to be conditional on the virt driver, but Ironic is working on feature parity with virt for networking, and baremetal networking is vastly different than virt networking. I think we're going to have to accept that. // jim Thanks, John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [os-ansible-deployment] Core nomination for Matt Kassawara (sam-i-am)
On 07/17/2015 11:19 AM, Nolan Brubaker wrote: Matt ... is just about always in the community channel(s) helping folks, is a great technical resource for all things networking / OpenStack, I heartly agree. I haven't looked at the ansible reviews so can't speak to that, but I do acknowledge the value I see in the work Matt does. Anita. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Should we move to #openstack-murano ?
Hi, Kate! So I have a question: should we move to #openstack-murano? I think it’s a good idea, since it’s more obvious to go to #openstack-murano if one needs help with murano. I like this idea. Strong +1 to it. -- Victor Ryzhenkin Junior QA Engeneer freerunner on #freenode Включено 17 июля 2015 г. в 19:23:36, Ekaterina Chernova (efedor...@mirantis.com) написал: Hi guys! Currently Murano holds the #murano IRC channel. But all openstack projects have the openstack- prefix in their channel’s name. So I have a question: should we move to #openstack-murano? I think it’s a good idea, since it’s more obvious to go to #openstack-murano if one needs help with murano. Do you know if anybody tried to get help at #openstack-murano and discovered that this is not the official Murano channel ? Would it be hard to migrate from one channel to another? Regards, Kate. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Nailgun agent core reviewers nomination
Thanks all. From this moment Vladimir Kozhukalov is a core-reviewer of fuel-nailgun-agent. On Fri, Jul 17, 2015 at 4:25 PM, Tatyana Leontovich tleontov...@mirantis.com wrote: +1 On Fri, Jul 17, 2015 at 4:20 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: +1 On Fri, Jul 17, 2015 at 5:43 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: +1 On Thu, Jul 16, 2015 at 8:57 AM Sergii Golovatiuk sgolovat...@mirantis.com wrote: +1 -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Thu, Jul 16, 2015 at 10:20 AM, Vladimir Sharshov vshars...@mirantis.com wrote: Hi, we have created separate project for fuel-nailgun-agent. At now moment only i have core-reviewer rights.We hardly need more core reviewers here. I want to nominate Vladimir Kozhukalov to fuel-nailgun-agent core. At now moment Vladimir is one of the main contributor in nailgun-agent. Please reply with +1/-1. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Murano] Should we move to #openstack-murano ?
Hi guys! Currently Murano holds the *#murano* IRC channel. But all openstack projects have the openstack- prefix in their channel’s name. So I have a question: should we move to *#openstack-murano*? I think it’s a good idea, since it’s more obvious to go to* #openstack-murano* if one needs help with murano. Do you know if anybody tried to get help at *#openstack-murano* and discovered that this is not the official Murano channel ? Would it be hard to migrate from one channel to another? Regards, Kate. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [openstack-infra] [CI] [tempest] Tempest tests failing with SSH timeout.
Hi Folks, In my CI I see the following tempest tests failure for a past couple of days. - tempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario [361.274316s] ... FAILED - tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern [320.122458s] ... FAILED - tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern [317.399342s] ... FAILED - tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_compute_with_volumes [257.858272s] ... FAILED The failure logs are always the same every time, i.e; *03:34:09* 2015-07-17 03:21:13,256 9505 ERROR [tempest.scenario.manager] (TestVolumeBootPattern:test_volume_boot_pattern) Initializing SSH connection to 172.24.5.1 failed. Error: Connection to the 172.24.5.1 via SSH timed out.*03:34:09* User: cirros, Password: None*03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager Traceback (most recent call last):*03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager File tempest/scenario/manager.py, line 312, in get_remote_client*03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager linux_client.validate_authentication()*03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager File tempest/common/utils/linux/remote_client.py, line 62, in validate_authentication*03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager self.ssh_client.test_connection_auth()*03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager File /opt/stack/new/tempest/.tox/all/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py, line 151, in test_connection_auth*03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager connection = self._get_ssh_connection()*03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager File /opt/stack/new/tempest/.tox/all/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py, line 87, in _get_ssh_connection*03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager password=self.password)*03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager SSHTimeout: Connection to the 172.24.5.1 via SSH timed out.*03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager User: cirros, Password: None*03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager *03:34:09* 2015-07-17 03:21:14,377 9505 INFO [tempest_lib.common.re Because of these every job is failing, so if someone can help me regarding this please do reply. -- *Thanks Regards,* *Abhishek* *Cloudbyte Inc. http://www.cloudbyte.com* __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Vedams' DotHill, Lenovo and HP MSA CIs are Unstable
Hi Mike, We are taking it as a high priority. We have moved all CIs to sand-box for making sure that they do not generate spam. We will move these CIs to cinder patches ASAP and will update the wiki page of third party CI. Please let me know if you have any questions. Regards Nikesh On Wed, Jul 15, 2015 at 4:21 AM, Mike Perez thin...@gmail.com wrote: These three CIs are unstable and the drivers are in danger of being removed from the Liberty release since the maintainer has not communicated any maintenance happening. http://paste.openstack.org/show/375584/ http://paste.openstack.org/show/375585/ http://paste.openstack.org/show/375586/ I will be requesting the HP MSA CI to be disabled in the third party list, since it has failed the last 60 runs in the last 5 days. This is unacceptable and we need Vedams to be more on top of this. -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][api] New API Guidelines read for cross project review
michael mccune wrote: hey all, we have 4 API Guidelines that are ready for final review. 1. Add generic name of each project for terms https://review.openstack.org/#/c/196918/ 2. Add new guideline for HTTP Headers https://review.openstack.org/#/c/186526/ 3. Adds guidance on request bodies with different Methods https://review.openstack.org/#/c/184358/ 4. Adding 5xx guidance https://review.openstack.org/#/c/183698/ if the API Working Group hasn't received any further feedback, we'll merge them on July 23. Note that we won't be having a cross-project meeting on July 21st, so these won't get the opportunity to get discussed in that forum. So you might want to delay that final approval for an extra week... Your call. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Exposing provider networks in network_data.json
On 07/16/2015 06:06 PM, Sean M. Collins wrote: On Thu, Jul 16, 2015 at 01:23:29PM PDT, Mathieu Gagné wrote: So it looks like there is a missing part in this feature. There should be a way to hide this information if the instance does not require to configure vlan interfaces to make network functional. I just commented on the review, but the provider network API extension is admin only, most likely for the reasons that I think someone has already mentioned, that it exposes details of the phyiscal network layout that should not be exposed to tenants. So, clearly, under some circumstances the network operator wants to expose this information, because there was the request for that feature. The question in my mind is what circumstances are those, and what additional information needs to be provided here. There is always a balance between the private cloud case which wants to enable more self service from users (and where the users are often also the operators), and the public cloud case where the users are outsiders and we want to hide as much as possible from them. For instance, would an additional attribute on a provider network that says this is cool to tell people about be an acceptable approach? Is there some other creative way to tell our infrastructure that these artifacts are meant to be exposed in this installation? Just kicking around ideas, because I know a pile of gate hardware for everyone to use is at the other side of answers to these questions. And given that we've been running full capacity for days now, keeping this ball moving forward would be great. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]Proposal for function to manage the resources available to each tenant
Le 17/07/2015 10:42, Kenji Ishii a écrit : Hello! Please give me opinion in terms to be a valuable function for OpenStack Community. We believe that we need a mechanism to easily manage the resources available to the each tenant. In some case, we want to allow only the specific tenant to use the specific resources. We think the two architectures of the following. a. New concept called vDC vDC is virtual DC. It means collection of several logical resources : Availavility Zone(AZ). If we use it, we can control the resources to each tenant. For example, ___vDC_1 ___vDC_2 || || | AZ1, AZ2 | | AZ3 | || || tenant tenant_001 assigned vDC_1 tenant tenant_002 assigned vDC_2 tenant_001 can use AZ1 and AZ2, AZ3 is unavailable. tenant_002 can use AZ3 , AZ1 and AZ2 is unavailable. Not sure I fully understand but AggregateMultiTenancyIsolation filter already partially does the job (with a certain number of pitfalls, one being addressed in https://review.openstack.org/#/c/195783/ ) b. use region It will manage the relation between the Region and the tenant. The tenant can use only the resources in region that be allowed it to use. By the way, this proposal is several problems - Cost of system construction is higher than proposal a etc Nova litterally knows nothing about Regions, that's a pure Keystone concept. From my perspective, you just have to make sure that your tenants are per region, you don't really need more to have the tenancy segregation at the region level. Caution, I'm not a Keystone expert. -Sylvain each proposal's detail is following. https://wiki.openstack.org/wiki/Proposal_vDC -- Kenji Ishii __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance] V3 authentication to swift
Thanks for the heads up Jamie, I'll try to take a look. -Stuart Glancers, A while ago I wrote an email outlining a couple of ways we could support keystone v3 authentication when using swift as a backend for glance_store. In the long term it would be best to transition swiftclient to use sessions as this would allow us to do more extensive (kerberos, ssl etc) authentication in the future, however this is a longer term plan that requires a lot of effort and coordination. For right now glance-swift is the last piece of devstack that only works with v2 authentication[1] and with a relatively small amount of code we can support v3 username/password which is by far the most common scenario. I've been prompting for a while on IRC however can I please request some reviews of https://review.openstack.org/#/c/193422/ as it has now become a blocker for the v3 authentication effort. Thanks for your help, Jamie [1] Note, that by this i mean that with v2 keystone disabled glance-swift communication is the last thing in the standard devstack gate path that can't be configured to v3. It does not mean that tempest will succeed or that all of OpenStack is v3 compatible just that we can start running meaningful gate jobs. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Sounds like a great idea Thierry! Any concrete deliverables you have in mind for this group? thanks, dims On Fri, Jul 17, 2015 at 6:07 AM, Thierry Carrez thie...@openstack.org wrote: Thomas Goirand wrote: IMO, we should, for the Liberty release, get rid of: - suds suds-jurko - memcached (in the favor of pymemcache) - mysqldb (this has been discussed at large already) - cliff-tablib and tablib (not ported to Py3, used only for testing) I feel like there is an opportunity for a project team to form around generally keeping up with the Python times. In the past we had various disconnected efforts: Python 3 migration, dependency convergence, getting rid (or taking over from) abandoned dependencies. All those efforts share a lot in common: you have to keep track and be closely involved with the Python ecosystem at large. You have to see what is getting abandoned or will never support newer versions of Python, check out new libraries that could replace things we use, actively push for those replacements in projects across OpenStack and generally work to converge on dependencies where possible. You have to watch upper-constraints and bump to keep up with bugfixes and avoid falling behind. Up to now those were mostly individual efforts. It may be time for a true horizontal effort to form around those activities and skillset: establishing an official project team would help coordinate those efforts and give them some weight. The same way Oslo reduced code duplication, I can see that new effort result in increasing the packageability (ew) of OpenStack and serve as insurance against falling behind the times. Thoughts ? -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Thomas Goirand wrote: IMO, we should, for the Liberty release, get rid of: - suds suds-jurko - memcached (in the favor of pymemcache) - mysqldb (this has been discussed at large already) - cliff-tablib and tablib (not ported to Py3, used only for testing) I feel like there is an opportunity for a project team to form around generally keeping up with the Python times. In the past we had various disconnected efforts: Python 3 migration, dependency convergence, getting rid (or taking over from) abandoned dependencies. All those efforts share a lot in common: you have to keep track and be closely involved with the Python ecosystem at large. You have to see what is getting abandoned or will never support newer versions of Python, check out new libraries that could replace things we use, actively push for those replacements in projects across OpenStack and generally work to converge on dependencies where possible. You have to watch upper-constraints and bump to keep up with bugfixes and avoid falling behind. Up to now those were mostly individual efforts. It may be time for a true horizontal effort to form around those activities and skillset: establishing an official project team would help coordinate those efforts and give them some weight. The same way Oslo reduced code duplication, I can see that new effort result in increasing the packageability (ew) of OpenStack and serve as insurance against falling behind the times. Thoughts ? -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
On Thu, Jul 16 2015, Angus Salkeld wrote: Hi Angus, I just saw this, and I am concerned this is going to kill Heat's gate (and user's templates). Will this be hidden within the client so that as long as we have aodh enabled in our gate's devstack this will just work? As Gordon said, don't worry, we'll do everything to not break Heat's gate, managing transition. We're setting up a plan and I think Mehdi already has patches doing magic so it's transparent and painless for everyone. -- Julien Danjou # Free Software hacker # http://julien.danjou.info signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library
Hi, I think that we should provide a separate script that will fetch the upstream modules into fuel-library/deployment/puppet/ directory. It will allow us to have everything in a single place and use this script in ISO build process and CI jobs. Regards, Alex On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz aschu...@mirantis.com wrote: Hello everyone, I have committed the initial configuration required to start leveraging librarian-puppet as part of the way we pull in upstream puppet modules[0]. Additionally, I have also committed a change that would pull in the openstack-ironic module[1]. The one piece that is missing from this being a complete solution is the ability to run librarian-puppet as part of our build process for the fuel-library. I've looked into the fuel-main build scripts and I think it's over my head to figure this out just by looking. Can anyone explain to me or assist me in how I could go about modifying the existing build system to be able to run librarian-puppet to prepare the source for the package? In my initial investigation, it looks like it would be a modification of the fuel-main/packages/module.mk[3] file. I basically need to do the prepare_library[3] function from the 202763 review[0] after we've pulled all the sources together to fetch the upstream modules. Thanks, -Alex [0] https://review.openstack.org/202763 [1] https://review.openstack.org/202767 [2] https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 [3] https://review.openstack.org/#/c/202763/1/utils/jenkins/fuel_noop_tests.rb __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][api] New API Guidelines read for cross project review
michael mccune wrote: On 07/17/2015 05:50 AM, Thierry Carrez wrote: Note that we won't be having a cross-project meeting on July 21st, so these won't get the opportunity to get discussed in that forum. So you might want to delay that final approval for an extra week... Your call. thanks Thierry, i don't think it will hurt to wait an extra week. OK, added to week after next's meeting agenda: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting Cheers, -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal with Hyper
Hi, Adrian, Jay and all, There could be a much longer version of this, but let me try to explain in a minimalist way. Bay currently has two modes: VM-based, BM-based. In both cases, Bay helps to isolate different tenants' containers. In other words, bay is single-tenancy. For BM-based bay, the single tenancy is a worthy tradeoff, given the performance merits of LXC vs VM. However, for a VM-based bay, there is no performance gain, but single tenancy seems a must, due to the lack of isolation in container. Hyper, as a hypervisor-based substitute for container, brings the much-needed isolation, and therefore enables multi-tenancy. In HyperStack, we don't really need Ironic to provision multiple Hyper bays. On the other hand, the entire HyperStack cluster is a single big bay. Pretty similar to how Nova works. Also, HyperStack is able to leverage Cinder, Neutron for SDS/SDN functionality. So when someone submits a Docker Compose app, HyperStack would launch HyperVMs and call Cinder/Neutron to setup the volumes and network. The architecture is quite simple. Here are a blog I'd like to recommend: https://hyper.sh/blog/post/2015/06/29/docker-hyper-and-the-end-of-guest-os.html Let me know your questions. Thanks, Peng -- Original -- From: Adrian Ottoadrian.o...@rackspace.com; Date: Thu, Jul 16, 2015 11:02 PM To: OpenStack Development Mailing List (not for usage questions)openstack-dev@lists.openstack.org; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetalwith Hyper Jay, Hyper is a substitute for a Docker host, so I expect it could work equally well for all of the current bay types. Hyper’s idea of a “pod” and a Kubernetes “pod” are similar, but different. I’m not yet convinced that integrating Hyper host creation direct with Magnum (and completely bypassing nova) is a good idea. It probably makes more sense to implement use nova with the ironic dirt driver to provision Hyper hosts so we can use those as substitutes for Bay nodes in our various Bay types. This would fit in the place were we use Fedora Atomic today. We could still rely on nova to do all of the machine instance management and accounting like we do today, but produce bays that use Hyper instead of a Docker host. Everywhere we currently offer CoreOS as an option we could also offer Hyper as an alternative, with some caveats. There may be some caveats/drawbacks to consider before committing to a Hyper integration. I’ll be asking those of Peng also on this thread, so keep an eye out. Thanks, Adrian On Jul 16, 2015, at 3:23 AM, Jay Lau jay.lau@gmail.com wrote: Thanks Peng, then I can see two integration points for Magnum and Hyper: 1) Once Hyper and k8s integration finished, we can deploy k8s in two mode: docker and hyper mode, the end user can select which mode they want to use. For such case, we do not need to create a new bay but may need some enhancement for current k8s bay 2) After mesos and hyper integration, we can treat mesos and hyper as a new bay to magnum. Just like what we are doing now for mesos+marathon. Thanks! 2015-07-16 17:38 GMT+08:00 Peng Zhao p...@hyper.sh: Hi Jay, Yes, we are working with the community to integrate Hyper with Mesos and K8S. Since Hyper uses Pod as the default job unit, it is quite easy to integrate with K8S. Mesos takes a bit more efforts, but still straightforward. We expect to finish both integration in v0.4 early August. Best, Peng - Hyper - Make VM run like Container On Thu, Jul 16, 2015 at 3:47 PM, Jay Lau jay.lau@gmail.com wrote: Hi Peng, Just want to get more for Hyper. If we create a hyper bay, then can I set up multiple hosts in a hyper bay? If so, who will do the scheduling, does mesos or some others integrate with hyper? I did not find much info for hyper cluster management. Thanks. 2015-07-16 9:54 GMT+08:00 Peng Zhao p...@hyper.sh: -- Original -- From: “Adrian Otto”adrian.o...@rackspace.com; Date: Wed, Jul 15, 2015 02:31 AM To: “OpenStack Development Mailing List (not for usage questions)“openstack-dev@lists.openstack.org; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper Peng, On Jul 13, 2015, at 8:37 PM, Peng Zhao p...@hyper.sh wrote: Thanks Adrian! Hi, all, Let me recap what is hyper and the idea of hyperstack. Hyper is a single-host runtime engine. Technically, Docker = LXC + AUFS Hyper = Hypervisor + AUFS where AUFS is the Docker image. I do not understand the last line above. My understanding is that AUFS == UnionFS, which is used to implement a storage driver for Docker. Others exist for btrfs, and
Re: [openstack-dev] [Murano] Should we move to #openstack-murano ?
+1, Kate. Lee -- Lee Calcote Director, Software Engineering | Cloud Systems and Solutions Seagate Technology | 10200 S. De Anza Blvd., Cupertino, CA 95014 (W) 408-658-1861 (C) 512-810-2771 (T) @lcalcote On Jul 17, 2015, at 11:26 AM, Victor Ryzhenkin vryzhen...@mirantis.com wrote: Hi, Kate! So I have a question: should we move to #openstack-murano? I think it’s a good idea, since it’s more obvious to go to #openstack-murano if one needs help with murano. I like this idea. Strong +1 to it. -- Victor Ryzhenkin Junior QA Engeneer freerunner on #freenode Включено 17 июля 2015 г. в 19:23:36, Ekaterina Chernova (efedor...@mirantis.com mailto:efedor...@mirantis.com) написал: Hi guys! Currently Murano holds the #murano IRC channel. But all openstack projects have the openstack- prefix in their channel’s name. So I have a question: should we move to #openstack-murano? I think it’s a good idea, since it’s more obvious to go to #openstack-murano if one needs help with murano. Do you know if anybody tried to get help at #openstack-murano and discovered that this is not the official Murano channel ? Would it be hard to migrate from one channel to another? Regards, Kate. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddevd=AwICAgc=IGDlg0lD0b-nebmJJ0Kp8Ar=I3cSIvyDkys1wUZdtxxtF5qxRkoDWv_Y7wNzrd3ReMUm=adKlfMyngJxcdIXIPM9W6VVMLHMA9FDNtEbjRiBSJv0s=1mjbCcPOcrLy18LVat6mo3EXOX-1qEM87rnAnp83H5ce= https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddevd=AwICAgc=IGDlg0lD0b-nebmJJ0Kp8Ar=I3cSIvyDkys1wUZdtxxtF5qxRkoDWv_Y7wNzrd3ReMUm=adKlfMyngJxcdIXIPM9W6VVMLHMA9FDNtEbjRiBSJv0s=1mjbCcPOcrLy18LVat6mo3EXOX-1qEM87rnAnp83H5ce= __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [magnum]
All, Does anyone have insight into Google's plans for contributing to containers within OpenStack? http://googlecloudplatform.blogspot.tw/2015/07/Containers-Private-Cloud-Google-Sponsors-OpenStack-Foundation.html Regards, Daneyon Hansen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Exposing provider networks in network_data.json
Check out my comments on the review. Only Neutron knows whether or not an instance needs to do manual tagging based on the plugin/driver loaded. For example, Ironic/bare metal ports can be bound by neutron with a correct driver so they shouldn't get the VLAN information at the instance level in those cases. Nova has no way to know whether Neutron is configured this way so Neutron should have an explicit response in the port binding information indicating that an instance needs to tag. On Fri, Jul 17, 2015 at 9:51 AM, Jim Rollenhagen j...@jimrollenhagen.com wrote: On Fri, Jul 17, 2015 at 01:06:46PM +0100, John Garbutt wrote: On 17 July 2015 at 11:23, Sean Dague s...@dague.net wrote: On 07/16/2015 06:06 PM, Sean M. Collins wrote: On Thu, Jul 16, 2015 at 01:23:29PM PDT, Mathieu Gagné wrote: So it looks like there is a missing part in this feature. There should be a way to hide this information if the instance does not require to configure vlan interfaces to make network functional. I just commented on the review, but the provider network API extension is admin only, most likely for the reasons that I think someone has already mentioned, that it exposes details of the phyiscal network layout that should not be exposed to tenants. So, clearly, under some circumstances the network operator wants to expose this information, because there was the request for that feature. The question in my mind is what circumstances are those, and what additional information needs to be provided here. There is always a balance between the private cloud case which wants to enable more self service from users (and where the users are often also the operators), and the public cloud case where the users are outsiders and we want to hide as much as possible from them. For instance, would an additional attribute on a provider network that says this is cool to tell people about be an acceptable approach? Is there some other creative way to tell our infrastructure that these artifacts are meant to be exposed in this installation? Just kicking around ideas, because I know a pile of gate hardware for everyone to use is at the other side of answers to these questions. And given that we've been running full capacity for days now, keeping this ball moving forward would be great. Maybe we just need to add policy around who gets to see that extra detail, and maybe hide it by default? Would that deal with the concerns here? I'm not so sure. There are certain Neutron plugins that work with certain virt drivers (Ironic) that require this information to be passed to all instances built by that virt driver. However, it doesn't (and probably shouldn't, as to not confuse cloud-init/etc) need to be passed to other instances. I think the conditional for passing this as metadata is going to need to be some combination of operator config, Neutron config/driver, and virt driver. I know we don't like networking things to be conditional on the virt driver, but Ironic is working on feature parity with virt for networking, and baremetal networking is vastly different than virt networking. I think we're going to have to accept that. // jim Thanks, John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [ironic] Exposing provider networks in network_data.json
(adding [ironic] since baremetal use cases are involved) On 2015-07-17 11:51 AM, Jim Rollenhagen wrote: On Fri, Jul 17, 2015 at 01:06:46PM +0100, John Garbutt wrote: On 17 July 2015 at 11:23, Sean Dague s...@dague.net wrote: On 07/16/2015 06:06 PM, Sean M. Collins wrote: On Thu, Jul 16, 2015 at 01:23:29PM PDT, Mathieu Gagné wrote: So it looks like there is a missing part in this feature. There should be a way to hide this information if the instance does not require to configure vlan interfaces to make network functional. I just commented on the review, but the provider network API extension is admin only, most likely for the reasons that I think someone has already mentioned, that it exposes details of the phyiscal network layout that should not be exposed to tenants. So, clearly, under some circumstances the network operator wants to expose this information, because there was the request for that feature. The question in my mind is what circumstances are those, and what additional information needs to be provided here. There is always a balance between the private cloud case which wants to enable more self service from users (and where the users are often also the operators), and the public cloud case where the users are outsiders and we want to hide as much as possible from them. For instance, would an additional attribute on a provider network that says this is cool to tell people about be an acceptable approach? Is there some other creative way to tell our infrastructure that these artifacts are meant to be exposed in this installation? Just kicking around ideas, because I know a pile of gate hardware for everyone to use is at the other side of answers to these questions. And given that we've been running full capacity for days now, keeping this ball moving forward would be great. Maybe we just need to add policy around who gets to see that extra detail, and maybe hide it by default? Would that deal with the concerns here? I'm not so sure. There are certain Neutron plugins that work with certain virt drivers (Ironic) that require this information to be passed to all instances built by that virt driver. However, it doesn't (and probably shouldn't, as to not confuse cloud-init/etc) need to be passed to other instances. I think the conditional for passing this as metadata is going to need to be some combination of operator config, Neutron config/driver, and virt driver. I know we don't like networking things to be conditional on the virt driver, but Ironic is working on feature parity with virt for networking, and baremetal networking is vastly different than virt networking. I think we're going to have to accept that. How about we list the known use cases (valid or not) for baremetal so people understand what we are referring to? We will then be able to determine what we wish to support. Here is my take on it: 1. Single NIC with single network in access mode 2. Single NIC with single network in trunk mode (similar to 3.) 3. Single NIC with multiple networks in trunk mode 4. Multiple NICs with 1 network/nic in access mode: 1 NIC == 1 network in access mode 5. Multiple NICs with multiple networks in trunk mode: 1 NIC == multiple networks in trunk mode (to which NIC is the network associated is left as an exercise to the reader) 6. Multiple NICs with bonding with 1 network/bond in access mode: 2 NICs == 1 bond == 1 network in access mode 7. Multiple NICs with bonding with multiple networks in trunk mode: 2 NICs == 1 bond == multiple networks in trunk mode Those examples are based on a setup with VLAN networks. Let me know if you feel I missed use cases. (I'm less familiar with VXLAN so excuse me if I get some stuff wrong) For VXLAN networks, there is the question of where is the VTEP: a. the baremetal node itself? b. the TOR switch? The use case a. leaves a lot of question to be answered regarding security which I'm definitely not familiar with. As for use case b., we have to perform VLAN translation. We can also argue that even without VXLAN encapsulation, an operator could wish to perform VLAN translation so the tenant isn't aware of the actual VLAN attributed to him. This could also allow an operator to bridge multiple L2 network segments together while still exposing a single common VLAN to the tenant across the whole datacenter, irregardless of the L2 network segment his baremetal node landed in. -- Mathieu __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Concern about networking-sfc and community process
Hi Sean, I was on IRC Infra channel yesterday getting guidance about the merge. I have replied to all the other comments on the new version 12 and addressed them in the latest updated version, but I did not spot yours since yours is towards the end of the spec and Louis, not I, replied to your comment. I apologize for this! I am usually careful and addressing all comments posted (even after the PTL approval). Yesterday I was in a little rush and was busy switching between intranet for checking the Jenkin email notification and external Internet for getting on the IRC channel and updating/checking in new versions. After I spotted your latest “-1” yesterday, I had replied that I will upload a follow-up patch to add the API endpoints and URL info in the wiki to this spec. Apologize again for this! Thanks, Cathy From: Kyle Mestery [mailto:mest...@mestery.com] Sent: Friday, July 17, 2015 8:13 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Cathy Zhang Subject: Re: [openstack-dev] [Neutron] Concern about networking-sfc and community process On Thu, Jul 16, 2015 at 8:39 PM, Sean M. Collins s...@coreitpro.commailto:s...@coreitpro.com wrote: Hi Cathy, You recently merged the following patch, by +2'ing and then Workflow+1'ing it, without allowing reviewers the chance to look at the changes between the patchset where there were -1's and the newer patchsets. https://review.openstack.org/#/c/192933/ I do see that you were asking on -infra about the mechanics of how to merge a patch http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2015-07-16.log.html#t2015-07-16T23:54:03 Just because a core member has given it a +2 and the Neutron PTL had +2'd a previous patch, doesn't mean that you should go ahead and unilaterally approve your own patch. That's not a way to build a commmunity project. I agree with Sean here. The patch merged with only a single +2, and if the other comments were not addressed earlier, they need to be addressed with a followup patch (and reply on this email thread with the patch), or we should revert the commit and address them there. Thanks, Kyle -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Well we already have a debtcollector[1] library, It serves similar purposes for actively maintained libraries (not dead/abandoned ones), So how about a group named 'the debtcollectors' [1] http://docs.openstack.org/developer/debtcollector/ Thierry Carrez wrote: Joshua Harlow wrote: Sounds good to me, +1 I know that some of the oslo core (I've done a little) and others (victor does a-lot of it) have been taking over this duty already but some kind of miniature group that has this a main goal would be cool to. And now for the hardest part... pick a name ! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Exposing provider networks in network_data.json
On Fri, Jul 17, 2015 at 10:56:36AM -0600, Kevin Benton wrote: Check out my comments on the review. Only Neutron knows whether or not an instance needs to do manual tagging based on the plugin/driver loaded. For example, Ironic/bare metal ports can be bound by neutron with a correct driver so they shouldn't get the VLAN information at the instance level in those cases. Nova has no way to know whether Neutron is configured this way so Neutron should have an explicit response in the port binding information indicating that an instance needs to tag. Agree. However, I just want to point out that there are neutron drivers that exist today[0] that support bonded NICs with trunked VLANs, which requires VLAN info to be pushed to the host. I keep hearing bare metal will never need to know about VLANs so I want to quash that ASAP. As far as Neutron sending the flag to decide whether the instance should tag packets, +1, I think that should work. // jim On Fri, Jul 17, 2015 at 9:51 AM, Jim Rollenhagen j...@jimrollenhagen.com wrote: On Fri, Jul 17, 2015 at 01:06:46PM +0100, John Garbutt wrote: On 17 July 2015 at 11:23, Sean Dague s...@dague.net wrote: On 07/16/2015 06:06 PM, Sean M. Collins wrote: On Thu, Jul 16, 2015 at 01:23:29PM PDT, Mathieu Gagné wrote: So it looks like there is a missing part in this feature. There should be a way to hide this information if the instance does not require to configure vlan interfaces to make network functional. I just commented on the review, but the provider network API extension is admin only, most likely for the reasons that I think someone has already mentioned, that it exposes details of the phyiscal network layout that should not be exposed to tenants. So, clearly, under some circumstances the network operator wants to expose this information, because there was the request for that feature. The question in my mind is what circumstances are those, and what additional information needs to be provided here. There is always a balance between the private cloud case which wants to enable more self service from users (and where the users are often also the operators), and the public cloud case where the users are outsiders and we want to hide as much as possible from them. For instance, would an additional attribute on a provider network that says this is cool to tell people about be an acceptable approach? Is there some other creative way to tell our infrastructure that these artifacts are meant to be exposed in this installation? Just kicking around ideas, because I know a pile of gate hardware for everyone to use is at the other side of answers to these questions. And given that we've been running full capacity for days now, keeping this ball moving forward would be great. Maybe we just need to add policy around who gets to see that extra detail, and maybe hide it by default? Would that deal with the concerns here? I'm not so sure. There are certain Neutron plugins that work with certain virt drivers (Ironic) that require this information to be passed to all instances built by that virt driver. However, it doesn't (and probably shouldn't, as to not confuse cloud-init/etc) need to be passed to other instances. I think the conditional for passing this as metadata is going to need to be some combination of operator config, Neutron config/driver, and virt driver. I know we don't like networking things to be conditional on the virt driver, but Ironic is working on feature parity with virt for networking, and baremetal networking is vastly different than virt networking. I think we're going to have to accept that. // jim Thanks, John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Congress] New IRC meeting time
Yes the day is still Tuesday. Sorry that wasn't clear. Tim On Tue, Jul 14, 2015 at 7:30 PM Masahito MUROI muroi.masah...@lab.ntt.co.jp wrote: I'm happy to see that. btw, is the day on Tuesday? best regard, masa On 2015/07/15 9:52, Zhou, Zhenzan wrote: Glad to see this change. Thanks for the supporting for developers in Asia☺ BR Zhou Zhenzan From: Tim Hinrichs [mailto:t...@styra.com] Sent: Wednesday, July 15, 2015 02:14 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Congress] New IRC meeting time To better accommodate the active contributors, we're moving our IRC meeting to 2300 UTC = 4p Pacific = 7p Eastern #openstack-meeting-3 Hope to see you there! Tim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 室井 雅仁(Masahito MUROI) Software Innovation Center, NTT Tel: +81-422-59-4539，FAX: +81-422-59-2699 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] (Horizon) Alternative way to set webroot and static_url
I personally think having JS code generated from Django template is not necessary better than having JS globals. Actually I finding it is more problematic and keep causing issues: * app.module.js has to be manually collected and being placed before some Django template generated JS code: https://github.com/openstack/horizon/blob/master/openstack_dashboard/templates/horizon/_conf.html#L26-L34, because of it, we have to do multiple section like this: https://github.com/openstack/horizon/blob/master/openstack_dashboard/settings.py#L307-L316 for each sub_path under the app/ folder. We cannot add app.module.spec.js app.module.mock.js, app.moduls.mock.spec etc besides app.module.js since they won’t be auto-collected, and we have to always keep this in mind, otherwise when it is not auto-collected, it is quite hard to figure out why. Actually this happened to me today when I try to add app.module.mock.js and app.module.spec.js. * app.module.js has some hacking-ish code at https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/app.module.js#L62-L66 , it quite smell to me. * I am not a big fan of this code: https://github.com/openstack/horizon/blob/master/openstack_dashboard/templates/horizon/_conf.html#L34-L46 either, it looks like conducting surgery on JS with django’s template language. * I haven’t figured out what causing the issue with this patch yet: https://review.openstack.org/#/c/199319/ . But I suspect that it is also related to the hackings. I tried with a pure html file with the libraries and app.module, it works fine. * Having _conf.html is a quite odd thing to me, it seem that there is no reason for it except for hacking (correct me if I am worng). Ideally there should only be _script.html being responsible for populating script tags and should no inline js code. To me, a pure data or pure data object (an object that has no its own methods) generated from python/c#/java/php/ruby/nodejs is ok, but code, especially angular code generated from code template is a bad thing. They are always the biggest headache I have to deal with. One elegant solution is that, let’s have one and only one pure data object wrapping all the data that we need to collect from the python environment, and set it in the global, or hook it on an existing global variable, `horizon` for example, so we won’t pollute the global space. Richard - constants are independent to each other, a constant can not be defined by using other constants regardless it is a string or a function. To use such a function, we can only define angular providers, and angular provider cannot be used to define routing with ngRout/ui-router. This is one issue. Another issue is, when using a basePath, you have to inject in at least two dependencies and you have to go to all the place there using basePath to do the changes, all the tests will be broken, I already tried something similar, I don’t believe that could be possibly simpler that the current solution even we will never consider client-side routing. Thanks, Sean From: Richard Jones r1chardj0...@gmail.commailto:r1chardj0...@gmail.com Date: Fri, 17 Jul 2015 10:58:35 +1000 To: Thai Q Tran tqt...@us.ibm.commailto:tqt...@us.ibm.com Cc: Tripp Travis S travis.tr...@hp.commailto:travis.tr...@hp.com, Shaoquan Chen sean.ch...@hp.commailto:sean.ch...@hp.com, Borland Matt matthew.borl...@hp.commailto:matthew.borl...@hp.com, Cindy Lu c...@us.ibm.commailto:c...@us.ibm.com, Lyle David david.l...@intel.commailto:david.l...@intel.com Subject: Re: Alternative way to set webroot and static_url Hi all, I'm sorry to say I've not been following the window / STATIC_URL / WEBROOT stuff very closely, so I'm not sure exactly what the problem is that's trying to be solved. In this specific case, it looks like the linter is complaining about access to the window global, which seems fair enough. Switching to a config/constant combo using $windowProvider seems like a good move to me. As I've previously mentioned in passing, having the config step set up a function to calculate paths (rather than using string concatenation all over the place) could also be a good move, as it'd reduce the complexity of a bunch of code, I think. Richard On 17 July 2015 at 10:50, Thai Q Tran tqt...@us.ibm.commailto:tqt...@us.ibm.com wrote: Hi All, I was playing around with the webroot thing today and found a different way to set webroot and static_url. https://review.openstack.org/#/c/181095/54/horizon/static/framework/framework.module.js Using these 2 methods outlined, we can actually get rid of static_url and webroot from global space. As far as I know, legacy has only one file that uses static_url in source code, which we can eventually replace with an angular equivalent. Anyway, just wanted to bring it to your attention, have a good weekend everyone. __
Re: [openstack-dev] [nova] Exposing provider networks in network_data.json
On Fri, Jul 17, 2015 at 10:43:37AM -0700, Jim Rollenhagen wrote: On Fri, Jul 17, 2015 at 10:56:36AM -0600, Kevin Benton wrote: Check out my comments on the review. Only Neutron knows whether or not an instance needs to do manual tagging based on the plugin/driver loaded. For example, Ironic/bare metal ports can be bound by neutron with a correct driver so they shouldn't get the VLAN information at the instance level in those cases. Nova has no way to know whether Neutron is configured this way so Neutron should have an explicit response in the port binding information indicating that an instance needs to tag. Agree. However, I just want to point out that there are neutron drivers that exist today[0] that support bonded NICs with trunked VLANs, which requires VLAN info to be pushed to the host. I keep hearing bare metal will never need to know about VLANs so I want to quash that ASAP. As far as Neutron sending the flag to decide whether the instance should tag packets, +1, I think that should work. [0] https://github.com/rackerlabs/ironic-neutron-plugin // jim // jim On Fri, Jul 17, 2015 at 9:51 AM, Jim Rollenhagen j...@jimrollenhagen.com wrote: On Fri, Jul 17, 2015 at 01:06:46PM +0100, John Garbutt wrote: On 17 July 2015 at 11:23, Sean Dague s...@dague.net wrote: On 07/16/2015 06:06 PM, Sean M. Collins wrote: On Thu, Jul 16, 2015 at 01:23:29PM PDT, Mathieu Gagné wrote: So it looks like there is a missing part in this feature. There should be a way to hide this information if the instance does not require to configure vlan interfaces to make network functional. I just commented on the review, but the provider network API extension is admin only, most likely for the reasons that I think someone has already mentioned, that it exposes details of the phyiscal network layout that should not be exposed to tenants. So, clearly, under some circumstances the network operator wants to expose this information, because there was the request for that feature. The question in my mind is what circumstances are those, and what additional information needs to be provided here. There is always a balance between the private cloud case which wants to enable more self service from users (and where the users are often also the operators), and the public cloud case where the users are outsiders and we want to hide as much as possible from them. For instance, would an additional attribute on a provider network that says this is cool to tell people about be an acceptable approach? Is there some other creative way to tell our infrastructure that these artifacts are meant to be exposed in this installation? Just kicking around ideas, because I know a pile of gate hardware for everyone to use is at the other side of answers to these questions. And given that we've been running full capacity for days now, keeping this ball moving forward would be great. Maybe we just need to add policy around who gets to see that extra detail, and maybe hide it by default? Would that deal with the concerns here? I'm not so sure. There are certain Neutron plugins that work with certain virt drivers (Ironic) that require this information to be passed to all instances built by that virt driver. However, it doesn't (and probably shouldn't, as to not confuse cloud-init/etc) need to be passed to other instances. I think the conditional for passing this as metadata is going to need to be some combination of operator config, Neutron config/driver, and virt driver. I know we don't like networking things to be conditional on the virt driver, but Ironic is working on feature parity with virt for networking, and baremetal networking is vastly different than virt networking. I think we're going to have to accept that. // jim Thanks, John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][security-group] rules for filter mac-addresses
On Thu, Jul 16, 2015 at 08:59:19PM PDT, Richard Woo wrote: Sean, I agreed with you. But after I read Yan's user case. I think the FWaaS API may become too complex for that case. Can you expand on this? I'd like to know more since if the FwaaS API is too complex we need to take steps to improve it. -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [horizon] Unified interface for all regions
Hi, As anyone wondered if it could be possible/feasible to have an unified interface where all instances (or resources) are listed in one single page for all regions available in the catalog? What would be the challenges to make it happen? (so you don't have to toggle between regions) -- Mathieu __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [os-ansible-deployment] Core nomination for Matt Kassawara (sam-i-am)
Matt does add value, and I definitely don't want to imply that what he does isn't great work or that it isn't helpful to the project, however its hard to +1 a Core reviewer who has 1 review in the liberty timeframe. Since one of the primary purposes of core reviewers is to actively review code it doesn't make much sense to me. If Matt becomes more active performing quality reviews then I have no qualms. On Fri, Jul 17, 2015 at 4:14 PM, Kevin Carter kevin.car...@rackspace.com wrote: Hello all, I would like to nominate Matt Kassawara (IRC: sam-i-am) to the OpenStack Ansible deployment core team. Matt has been instrumental in building out our current install and use documentation[0], he is just about always in the community channel(s) helping folks, is a great technical resource for all things networking / OpenStack, and is one of the main people we already rely on to ensure we're documenting the right things in the right places. IMHO, its about time he be given Core powers within the OSAD project. Please respond with +1/-1s and or any other concerns. As a reminder, we are using the voting process outlined at [ https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess ] to add members to our core team. -- Kevin Carter IRC: cloudnull [0] https://review.openstack.org/#/q/owner:%22Matthew+Kassawara%22+status:merged+project:stackforge/os-ansible-deployment,n,z __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library
Alex, Great that you did this. Now I think I can prepare fuel-main patch to invoke this script right before building fuel-library package. I'll add you to review it. Is it ok if I do this monday morning? Vladimir Kozhukalov On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Vladimir, On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Gathering upstream modules certainly should be implemented as a separate script so as to make it possible to use it wherever we need this (tests, builds, etc.) According to builds there are two things 1) We have so called perestroika package build system (Dmitry Burmistrov is a main contributor here). By the end of next week we are going to switch building all the packages to perestroika. And in order to gather upstream modules right before building fuel-library package, we need to change perestroika build scripts. 2) Currently we build packages using make system and you are right about the place where you need to make changes. https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 If you create shell script, I'll help you to add it to make code. I have updated my review[0] to extract the update logic to it's own bash script that can be invoked by the build scripts. Let me know what would be the best way to wedge this in there. I think for the perestroika this would also be needed for the fuel-library build, so if you point me at that I can see if I can help make that change as well. Thanks, -Alex [0] https://review.openstack.org/#/c/202763/ Vladimir Kozhukalov On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko adide...@mirantis.com wrote: I believe build_repo function is the best way to do this [0]. So for fuel-library we'll need to run a shell script right from the repo before 'touch $$@'. We can make it either conditional ( test -f ./path/additional_build_script.sh bash ./path/additional_build_script.sh ) or as additional parameter to function and add it in fuel-library call [1] Regards, Alex [0] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L16-L37 [1] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L45 On Fri, Jul 17, 2015 at 2:37 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Alex, On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, I think that we should provide a separate script that will fetch the upstream modules into fuel-library/deployment/puppet/ directory. It will allow us to have everything in a single place and use this script in ISO build process and CI jobs. Right. That is what I'm going for. The issue I need help with is the best way to execute this as part of the build process. From what i understand of the build process is that we are using git archive for all pieces so I'm not sure how to wedge in an extra script execution to do the module fetch. The creation of the script isn't the issue, the issue is how can I properly run it as part of the build process. Regards, Alex Thanks, -Alex On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz aschu...@mirantis.com wrote: Hello everyone, I have committed the initial configuration required to start leveraging librarian-puppet as part of the way we pull in upstream puppet modules[0]. Additionally, I have also committed a change that would pull in the openstack-ironic module[1]. The one piece that is missing from this being a complete solution is the ability to run librarian-puppet as part of our build process for the fuel-library. I've looked into the fuel-main build scripts and I think it's over my head to figure this out just by looking. Can anyone explain to me or assist me in how I could go about modifying the existing build system to be able to run librarian-puppet to prepare the source for the package? In my initial investigation, it looks like it would be a modification of the fuel-main/packages/module.mk[3] file. I basically need to do the prepare_library[3] function from the 202763 review[0] after we've pulled all the sources together to fetch the upstream modules. Thanks, -Alex [0] https://review.openstack.org/202763 [1] https://review.openstack.org/202767 [2] https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 [3] https://review.openstack.org/#/c/202763/1/utils/jenkins/fuel_noop_tests.rb __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [all][api] New API Guidelines read for cross project review
On 07/17/2015 12:33 PM, Thierry Carrez wrote: michael mccune wrote: On 07/17/2015 05:50 AM, Thierry Carrez wrote: Note that we won't be having a cross-project meeting on July 21st, so these won't get the opportunity to get discussed in that forum. So you might want to delay that final approval for an extra week... Your call. thanks Thierry, i don't think it will hurt to wait an extra week. OK, added to week after next's meeting agenda: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting Cheers, thank you kindly sir ;) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Josh, How about a defibrillators :) or a phoenix reference! but seriously, we probably need some official-ish name like Community outreach or Ecosystem curators.. Thanks, dims On Fri, Jul 17, 2015 at 1:24 PM, Joshua Harlow harlo...@outlook.com wrote: Well we already have a debtcollector[1] library, It serves similar purposes for actively maintained libraries (not dead/abandoned ones), So how about a group named 'the debtcollectors' [1] http://docs.openstack.org/developer/debtcollector/ Thierry Carrez wrote: Joshua Harlow wrote: Sounds good to me, +1 I know that some of the oslo core (I've done a little) and others (victor does a-lot of it) have been taking over this duty already but some kind of miniature group that has this a main goal would be cool to. And now for the hardest part... pick a name ! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Unified interface for all regions
It is certainly possible. And a common request. I have it as a priority to look into during the latter half of Liberty. There are two factors that prompted the current model. Taking the example of the instances page (as it exists today). 1) The resulting page would be making 6 API calls to 3 services multiplied by the number of regions. With the existing Django tooling, that's all done serially and in deployments of any size rendering that page server side can be slow to the point of nearly unusable. 2) When the user decides to create and instance, horizon needs to provide a filtering of endpoints that make logical sense. Allowing tying of compute, image, block, and network across regions won't make sense for most of those. So the existing implementation provides the filtering upfront, when the region is selected. In Liberty, the goal is to give an overview page that is cross-region. That would be written leveraging JavaScript to make the API calls asynchronously. And trying to act on a particular instance would filter you down to a region. At least that's my goal for Liberty. David On Fri, Jul 17, 2015 at 12:08 PM, Mathieu Gagné mga...@iweb.com wrote: Hi, As anyone wondered if it could be possible/feasible to have an unified interface where all instances (or resources) are listed in one single page for all regions available in the catalog? What would be the challenges to make it happen? (so you don't have to toggle between regions) -- Mathieu __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [sahara] keystone session upgrade
On 18 Jul 2015 6:29 am, michael mccune m...@redhat.com wrote: On 07/16/2015 04:31 PM, michael mccune wrote: i will also likely be rewriting the spec to encompass these changes if i can get them working locally. just wanted to follow up before i rewrite the spec. i think the most sensible approach at this point is to store an auth plugin object in our context. this will alleviate some of our reliance on the username/tenant_id/etc. authentication values that we currently use. this object will also be used in conjunction with the session cache to produce clients. the session cache will be removed from the context and instead become a singleton type object in the sahara.service.sessions module. the cache will contain several specific functions for creating session objects for our different needs. for example, nova session will need to pass the specific nova certificate to the session. for non-specific needs the session object can be shared between several clients. the clients themselves will use a combination of auth plugin object and session object for creation. in this manner we can associate different authentications with the sessions as needed and still share the connection pooling and caching that occurs in the session object. this will also allow us to continue to create admin clients as needed, we can either pass an admin authentication object to the client or set the context to have an admin authenticated plugin object. there are still a few questions to be answered about trust scoping, but i think they will fit in this model. i would still be curious to hear any thoughts about this approach, but i will continue to test it and work towards rewriting the spec. regards, mike So I'm not familiar with how Sahara handles contexts however from a theoretical stand point anything that is defined in config should be able to be cached globally. So service specific sessions, and admin auth. The context typically would contain things relevant to this request, however for convenience it might be worth having a pointer from context to the global. You then create clients then with the combination of session+auth. You don't need/want to attach the auth plugin to the session here as that makes it difficult to reuse. When using sessions like this client creation is cheap (no requests are made) so there's no reason to hang on to the client objects themselves. I'm not sure if that helped at all but catch me on IRC and I'll help out with what I can. Jamie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library
Not until we start using it then any ci that tests with that module will validate the modules inclusion. You can check the output of the jobs as we are printing what modules are managed by librarian. -Alex On Jul 17, 2015 6:17 PM, Andrew Woodward xar...@gmail.com wrote: Fantastic, do we have some way to validate that the module was pulled in properly as part of fuel-library CI? On Fri, Jul 17, 2015 at 2:48 PM Alex Schultz aschu...@mirantis.com wrote: Hey All, I've figured it out without having to modify the fuel-main build code. I've updated the fuel-library spec with a build action that invokes the script to pull down external modules. Please take some time to review the two reviews out there for this change to see if there are any issues with the way it is implemented. https://review.openstack.org/#/c/202763/ https://review.openstack.org/#/c/202767/ This is a first step towards being able to pull in unmodified external puppet modules. Thanks, -Alex On Fri, Jul 17, 2015 at 4:23 PM, Andrew Woodward awoodw...@mirantis.com wrote: On Fri, Jul 17, 2015 at 12:24 PM Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Great that you did this. Now I think I can prepare fuel-main patch to invoke this script right before building fuel-library package. I'll add you to review it. Is it ok if I do this monday morning? Keep in minde we agreeded to a deadline to get this sorted and in shape to land by EOD monday or we will have to retain the old, and crappy fork method. If possible please work out how this needs to work as early as possible so Alex can continue. Vladimir Kozhukalov On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Vladimir, On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Gathering upstream modules certainly should be implemented as a separate script so as to make it possible to use it wherever we need this (tests, builds, etc.) According to builds there are two things 1) We have so called perestroika package build system (Dmitry Burmistrov is a main contributor here). By the end of next week we are going to switch building all the packages to perestroika. And in order to gather upstream modules right before building fuel-library package, we need to change perestroika build scripts. 2) Currently we build packages using make system and you are right about the place where you need to make changes. https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 If you create shell script, I'll help you to add it to make code. I have updated my review[0] to extract the update logic to it's own bash script that can be invoked by the build scripts. Let me know what would be the best way to wedge this in there. I think for the perestroika this would also be needed for the fuel-library build, so if you point me at that I can see if I can help make that change as well. Thanks, -Alex [0] https://review.openstack.org/#/c/202763/ Vladimir Kozhukalov On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko adide...@mirantis.com wrote: I believe build_repo function is the best way to do this [0]. So for fuel-library we'll need to run a shell script right from the repo before 'touch $$@'. We can make it either conditional ( test -f ./path/additional_build_script.sh bash ./path/additional_build_script.sh ) or as additional parameter to function and add it in fuel-library call [1] Regards, Alex [0] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L16-L37 [1] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L45 On Fri, Jul 17, 2015 at 2:37 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Alex, On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, I think that we should provide a separate script that will fetch the upstream modules into fuel-library/deployment/puppet/ directory. It will allow us to have everything in a single place and use this script in ISO build process and CI jobs. Right. That is what I'm going for. The issue I need help with is the best way to execute this as part of the build process. From what i understand of the build process is that we are using git archive for all pieces so I'm not sure how to wedge in an extra script execution to do the module fetch. The creation of the script isn't the issue, the issue is how can I properly run it as part of the build process. Regards, Alex Thanks, -Alex On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz aschu...@mirantis.com wrote: Hello everyone, I have committed the initial configuration required to start leveraging librarian-puppet as part of the way we pull in upstream puppet modules[0]. Additionally, I have also committed a change that would pull in the openstack-ironic module[1]. The one piece that is missing from this being a complete
[openstack-dev] [fuel][puppet] Managing upstream puppet modules in fuel-library under librarian
One of the concerns raised by TC in response to the proposal to add Fuel to OpenStack Projects [0] is the fact that fuel-library includes copies of upstream Puppet modules, most importantly from OpenStack Puppet [1]. [0] https://review.openstack.org/199232 [1] https://lwn.net/Articles/648331/ I have brought this up in the Fuel weekly meeting [2], and we have agreed to start implementing the proposal from Alex Schultz to use puppet-librarian to manage upstream modules [3]. [2] http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-07-16-16.00.log.html#l-245 [3] http://lists.openstack.org/pipermail/openstack-dev/2015-June/067806.html We are days away from Feature Freeze for Fuel 7.0 scheduled for July 23 [4], so it's not reasonable to make librarian mandatory for all upstream modules just yet, but I believe that we should make full migration to librarian a blocker requirement for Fuel 8.0. [4] https://wiki.openstack.org/wiki/Fuel/7.0_Release_Schedule In the meanwhile, we're going to try to implement integration of the newly added puppet-ironic module under librarian [5][6][7]. [5] https://review.openstack.org/194184 [6] https://review.openstack.org/202763 [7] https://review.openstack.org/202767 To make sure this effort does not block integration of Ironic support in Fuel 7.0 and does not impact the Feature Freeze, we've set a deadline for this effort until Tuesday July 21. Fuelers and other Puppet experts, please help Alex and Pavlo get this done on time by reviewing their changes and offering advice. It is a small but crucial step towards full convergence with upstream, it would help a lot if we could confirm now that this approach is viable. Thank you, -- Dmitry Borodaenko __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
On Fri, Jul 17, 2015 at 8:52 PM, Julien Danjou jul...@danjou.info wrote: On Thu, Jul 16 2015, Angus Salkeld wrote: Hi Angus, I just saw this, and I am concerned this is going to kill Heat's gate (and user's templates). Will this be hidden within the client so that as long as we have aodh enabled in our gate's devstack this will just work? As Gordon said, don't worry, we'll do everything to not break Heat's gate, managing transition. We're setting up a plan and I think Mehdi already has patches doing magic so it's transparent and painless for everyone. OK, thanks - phew. -Angus -- Julien Danjou # Free Software hacker # http://julien.danjou.info __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [os-ansible-deployment] Core nomination for Matt Kassawara (sam-i-am)
To be clear Matt has been active an active reviewer. The previous reference link simply showed commits owned by him which also pertained to our project. Here is a complete list of changes that he's reviewed[0][1] in the OSAD project. -- Kevin Carter IRC: cloudnull [0] https://review.openstack.org/#/q/project:stackforge/os-ansible-deployment+reviewer:%22Matthew+Kassawara%22,n,z [1] https://review.openstack.org/#/q/project:stackforge/os-ansible-deployment-specs+reviewer:%22Matthew+Kassawara%22,n,z From: Andy McCrae andy.mcc...@gmail.com Sent: Friday, July 17, 2015 1:40 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [os-ansible-deployment] Core nomination for Matt Kassawara (sam-i-am) Matt does add value, and I definitely don't want to imply that what he does isn't great work or that it isn't helpful to the project, however its hard to +1 a Core reviewer who has 1 review in the liberty timeframe. Since one of the primary purposes of core reviewers is to actively review code it doesn't make much sense to me. If Matt becomes more active performing quality reviews then I have no qualms. On Fri, Jul 17, 2015 at 4:14 PM, Kevin Carter kevin.car...@rackspace.commailto:kevin.car...@rackspace.com wrote: Hello all, I would like to nominate Matt Kassawara (IRC: sam-i-am) to the OpenStack Ansible deployment core team. Matt has been instrumental in building out our current install and use documentation[0], he is just about always in the community channel(s) helping folks, is a great technical resource for all things networking / OpenStack, and is one of the main people we already rely on to ensure we're documenting the right things in the right places. IMHO, its about time he be given Core powers within the OSAD project. Please respond with +1/-1s and or any other concerns. As a reminder, we are using the voting process outlined at [ https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess ] to add members to our core team. -- Kevin Carter IRC: cloudnull [0] https://review.openstack.org/#/q/owner:%22Matthew+Kassawara%22+status:merged+project:stackforge/os-ansible-deployment,n,z __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Exposing provider networks in network_data.json
which requires VLAN info to be pushed to the host. I keep hearing bare metal will never need to know about VLANs so I want to quash that ASAP. That's leaking implementation details though if the bare metal host only needs to be on one network. It also creates a security risk if the bare metal node is untrusted. If the tagging is to make it so it can access multiple networks, then that makes sense for now but it should ultimately be replaced by the vlan trunk ports extension being worked on this cycle that decouples the underlying network transport from what gets tagged to the VM/bare metal. On Jul 17, 2015 11:47 AM, Jim Rollenhagen j...@jimrollenhagen.com wrote: On Fri, Jul 17, 2015 at 10:56:36AM -0600, Kevin Benton wrote: Check out my comments on the review. Only Neutron knows whether or not an instance needs to do manual tagging based on the plugin/driver loaded. For example, Ironic/bare metal ports can be bound by neutron with a correct driver so they shouldn't get the VLAN information at the instance level in those cases. Nova has no way to know whether Neutron is configured this way so Neutron should have an explicit response in the port binding information indicating that an instance needs to tag. Agree. However, I just want to point out that there are neutron drivers that exist today[0] that support bonded NICs with trunked VLANs, which requires VLAN info to be pushed to the host. I keep hearing bare metal will never need to know about VLANs so I want to quash that ASAP. As far as Neutron sending the flag to decide whether the instance should tag packets, +1, I think that should work. // jim On Fri, Jul 17, 2015 at 9:51 AM, Jim Rollenhagen j...@jimrollenhagen.com wrote: On Fri, Jul 17, 2015 at 01:06:46PM +0100, John Garbutt wrote: On 17 July 2015 at 11:23, Sean Dague s...@dague.net wrote: On 07/16/2015 06:06 PM, Sean M. Collins wrote: On Thu, Jul 16, 2015 at 01:23:29PM PDT, Mathieu Gagné wrote: So it looks like there is a missing part in this feature. There should be a way to hide this information if the instance does not require to configure vlan interfaces to make network functional. I just commented on the review, but the provider network API extension is admin only, most likely for the reasons that I think someone has already mentioned, that it exposes details of the phyiscal network layout that should not be exposed to tenants. So, clearly, under some circumstances the network operator wants to expose this information, because there was the request for that feature. The question in my mind is what circumstances are those, and what additional information needs to be provided here. There is always a balance between the private cloud case which wants to enable more self service from users (and where the users are often also the operators), and the public cloud case where the users are outsiders and we want to hide as much as possible from them. For instance, would an additional attribute on a provider network that says this is cool to tell people about be an acceptable approach? Is there some other creative way to tell our infrastructure that these artifacts are meant to be exposed in this installation? Just kicking around ideas, because I know a pile of gate hardware for everyone to use is at the other side of answers to these questions. And given that we've been running full capacity for days now, keeping this ball moving forward would be great. Maybe we just need to add policy around who gets to see that extra detail, and maybe hide it by default? Would that deal with the concerns here? I'm not so sure. There are certain Neutron plugins that work with certain virt drivers (Ironic) that require this information to be passed to all instances built by that virt driver. However, it doesn't (and probably shouldn't, as to not confuse cloud-init/etc) need to be passed to other instances. I think the conditional for passing this as metadata is going to need to be some combination of operator config, Neutron config/driver, and virt driver. I know we don't like networking things to be conditional on the virt driver, but Ironic is working on feature parity with virt for networking, and baremetal networking is vastly different than virt networking. I think we're going to have to accept that. // jim Thanks, John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack
Re: [openstack-dev] [Murano] Should we move to #openstack-murano ?
Heat does seem to use #heat though. But I have to agree, that most os OpenStack projects use #openstack-something I do not have a strong opinion about the idea, but I’m pretty sure nobody came to #openstack-murano and asked anything there. People usually do not ask questions in empty channels ;))) -- Kirill Zaitsev Murano team Software Engineer Mirantis, Inc On 17 Jul 2015 at 19:23:30, Ekaterina Chernova (efedor...@mirantis.com) wrote: Hi guys! Currently Murano holds the #murano IRC channel. But all openstack projects have the openstack- prefix in their channel’s name. So I have a question: should we move to #openstack-murano? I think it’s a good idea, since it’s more obvious to go to #openstack-murano if one needs help with murano. Do you know if anybody tried to get help at #openstack-murano and discovered that this is not the official Murano channel ? Would it be hard to migrate from one channel to another? Regards, Kate. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
On 17 Jul 2015 1:38 pm, Morgan Fainberg morgan.fainb...@gmail.com wrote: On Jul 17, 2015, at 04:36, Victor Stinner vstin...@redhat.com wrote: SNIP FYI some colleagues just forked python-ldap in https://github.com/pyldap/pyldap/ to add Python 3 support. Stay tuned ;-) I highly recommend contributing to the ldap3 project instead of continuing the python-ldap work. Ldap3 is (imho) a much better design and really (if anything) simply lacks a compatibility layer. Keystone will be moving to ldap3 (regardless of the compat module) either this cycle or next. As a point of reference, openstack/anchor went to ldap3 last week uneventfully, to achieve py3 support. There is a pending global-requirements change to bring it into there. Thanks -- Kind Regards, Dave Walker __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules
Igor, There shouldn't be any holywars as we are going to add our tests to Puppet manifests projects. We'll be able to resolve fast enough. In case of problems we can stick librarian to particular commit in upstream repo. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Fri, Jul 17, 2015 at 8:19 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hello guys, Update 'make iso' scripts: * Make them use 'r10k' (or other tool) to download upstream modules based on 'Puppetfile' I foreseen holywars with our Build team. AFAIK they are deeply concerned about Internet access during ISO build process. Hence, they'll propose to package upstream puppet manifests, and that can complicate our experience to work with upstream flexibly. Thanks, Igor On Thu, Jul 16, 2015 at 11:55 PM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, On Thu, Jul 16, 2015 at 9:01 AM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, guys, what if we simplify things a bit? All we need is: Remove all the community modules from fuel-library. Create 'Puppetfile' with list of community modules and their versions that we currently use. Make sure all our customizations are proposed to the upstream modules (via gerrit or github pull-requests). Create a separate file with list of patches for each module we need to cherry-pick (we need to support gerrit reviews and github pull-requests). Update 'make iso' scripts: Make them use 'r10k' (or other tool) to download upstream modules based on 'Puppetfile' I am giving +1 to librarian here. Iterate over list of patches for each module and cherry-pick them (just like we do for custom ISO build. I'm not sure if librarian provides such possibility) Puppetlabs is in transition of moving all modules to openstack. We may use pull-requests here just specifying repository. However, I am thinking about hacking librarian to add cherry-pick option. Eventually, when all the functionality we rely on is accepted in upstream modules, we'll get rid of file with list of patches for modules. But meanwhile it should be much easier to manage modules and customization in such way. Regards, Alex On Fri, Jul 10, 2015 at 5:25 PM, Alex Schultz aschu...@mirantis.com wrote: Done. Sorry about that. -Alex On Fri, Jul 10, 2015 at 9:22 AM, Simon Pasquier spasqu...@mirantis.com wrote: Alex, could you enable the comments for all on your document? Thanks! Simon On Thu, Jul 9, 2015 at 11:07 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote: Hello everyone, I took some time this morning to write out a document[0] that outlines one possible ways for us to manage our upstream modules in a more consistent fashion. I know we've had a few emails bouncing around lately around this topic of our use of upstream modules and how can we improve this. I thought I would throw out my idea of leveraging librarian-puppet to manage the upstream modules within our fuel-library repository. Ideally, all upstream modules should come from upstream sources and be removed from the fuel-library itself. Unfortunately because of the way our repository sits today, this is a very large undertaking and we do not currently have a way to manage the inclusion of the modules in an automated way. I believe this is where librarian-puppet can come in handy and provide a way to manage the modules. Please take a look at my document[0] and let me know if there are any questions. Thanks, -Alex [0] https://docs.google.com/document/d/13aK1QOujp2leuHmbGMwNeZIRDr1bFgJi88nxE642xLA/edit?usp=sharing The document is great, Alex! I'm fully support the idea to start adapting fuel-library by the suggested scheme. The monitoring feature of ibrarian looks not intrusive and we have no blockers to start using the librarian just immediately. -- Best regards, Bogdan Dobrelya, Irc #bogdando __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] 7/17 state of the gate (you know, fires)
We started the day with a mock 1.1.4 release breaking unit tests for a few projects (nova, cinder, ironic at least). The nova blocker was tracked with bug 1475661. We got a g-r change up to block mock!=1.1.4 but that didn't fix the issue because oslo.versionedobjects pulls mock in before pip processes the !=. Luckily lifeless reverted the regression and released mock 1.2 so we should be OK on that front for now. However, cinder/glance/nova, which gate on the ceph job, are blocked by bug 1475811 which is a regression with the rbd driver in glance_store 0.7.0, which was put into upper-constraints.txt today. I have a patch up for glance_store here: https://review.openstack.org/#/c/203294/ And an exclusion of 0.7.0 in g-r here: https://review.openstack.org/#/c/203295/ If the glance core team could get around to approving that fix and releasing 0.7.1 it would unblock the gate for glance/cinder/nova and make me happy. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] 7/17 state of the gate (you know, fires)
On 7/17/2015 7:51 PM, Matt Riedemann wrote: We started the day with a mock 1.1.4 release breaking unit tests for a few projects (nova, cinder, ironic at least). The nova blocker was tracked with bug 1475661. We got a g-r change up to block mock!=1.1.4 but that didn't fix the issue because oslo.versionedobjects pulls mock in before pip processes the !=. Luckily lifeless reverted the regression and released mock 1.2 so we should be OK on that front for now. However, cinder/glance/nova, which gate on the ceph job, are blocked by bug 1475811 which is a regression with the rbd driver in glance_store 0.7.0, which was put into upper-constraints.txt today. I have a patch up for glance_store here: https://review.openstack.org/#/c/203294/ And an exclusion of 0.7.0 in g-r here: https://review.openstack.org/#/c/203295/ If the glance core team could get around to approving that fix and releasing 0.7.1 it would unblock the gate for glance/cinder/nova and make me happy. We should probably also make this happen to avoid this again with the rbd backend in glance_store: https://review.openstack.org/#/c/203299 -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library
On Fri, Jul 17, 2015 at 12:24 PM Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Great that you did this. Now I think I can prepare fuel-main patch to invoke this script right before building fuel-library package. I'll add you to review it. Is it ok if I do this monday morning? Keep in minde we agreeded to a deadline to get this sorted and in shape to land by EOD monday or we will have to retain the old, and crappy fork method. If possible please work out how this needs to work as early as possible so Alex can continue. Vladimir Kozhukalov On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Vladimir, On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Gathering upstream modules certainly should be implemented as a separate script so as to make it possible to use it wherever we need this (tests, builds, etc.) According to builds there are two things 1) We have so called perestroika package build system (Dmitry Burmistrov is a main contributor here). By the end of next week we are going to switch building all the packages to perestroika. And in order to gather upstream modules right before building fuel-library package, we need to change perestroika build scripts. 2) Currently we build packages using make system and you are right about the place where you need to make changes. https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 If you create shell script, I'll help you to add it to make code. I have updated my review[0] to extract the update logic to it's own bash script that can be invoked by the build scripts. Let me know what would be the best way to wedge this in there. I think for the perestroika this would also be needed for the fuel-library build, so if you point me at that I can see if I can help make that change as well. Thanks, -Alex [0] https://review.openstack.org/#/c/202763/ Vladimir Kozhukalov On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko adide...@mirantis.com wrote: I believe build_repo function is the best way to do this [0]. So for fuel-library we'll need to run a shell script right from the repo before 'touch $$@'. We can make it either conditional ( test -f ./path/additional_build_script.sh bash ./path/additional_build_script.sh ) or as additional parameter to function and add it in fuel-library call [1] Regards, Alex [0] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L16-L37 [1] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L45 On Fri, Jul 17, 2015 at 2:37 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Alex, On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, I think that we should provide a separate script that will fetch the upstream modules into fuel-library/deployment/puppet/ directory. It will allow us to have everything in a single place and use this script in ISO build process and CI jobs. Right. That is what I'm going for. The issue I need help with is the best way to execute this as part of the build process. From what i understand of the build process is that we are using git archive for all pieces so I'm not sure how to wedge in an extra script execution to do the module fetch. The creation of the script isn't the issue, the issue is how can I properly run it as part of the build process. Regards, Alex Thanks, -Alex On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz aschu...@mirantis.com wrote: Hello everyone, I have committed the initial configuration required to start leveraging librarian-puppet as part of the way we pull in upstream puppet modules[0]. Additionally, I have also committed a change that would pull in the openstack-ironic module[1]. The one piece that is missing from this being a complete solution is the ability to run librarian-puppet as part of our build process for the fuel-library. I've looked into the fuel-main build scripts and I think it's over my head to figure this out just by looking. Can anyone explain to me or assist me in how I could go about modifying the existing build system to be able to run librarian-puppet to prepare the source for the package? In my initial investigation, it looks like it would be a modification of the fuel-main/packages/module.mk[3] file. I basically need to do the prepare_library[3] function from the 202763 review[0] after we've pulled all the sources together to fetch the upstream modules. Thanks, -Alex [0] https://review.openstack.org/202763 [1] https://review.openstack.org/202767 [2] https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 [3] https://review.openstack.org/#/c/202763/1/utils/jenkins/fuel_noop_tests.rb __ OpenStack Development Mailing List (not for usage questions)
Re: [openstack-dev] [Murano] Should we move to #openstack-murano ?
+1 from me. First time I join to this channel before #murano. Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2015-07-17 19:33 GMT+03:00 Lee Calcote lee.calc...@seagate.com: +1, Kate. Lee -- Lee Calcote Director, Software Engineering | Cloud Systems and Solutions Seagate Technology | 10200 S. De Anza Blvd., Cupertino, CA 95014 (W) 408-658-1861 (C) 512-810-2771 (T) @lcalcote On Jul 17, 2015, at 11:26 AM, Victor Ryzhenkin vryzhen...@mirantis.com wrote: Hi, Kate! So I have a question: should we move to *#openstack-murano*? I think it’s a good idea, since it’s more obvious to go to *#openstack-murano* if one needs help with murano. I like this idea. Strong +1 to it. -- Victor Ryzhenkin Junior QA Engeneer freerunner on #freenode Включено 17 июля 2015 г. в 19:23:36, Ekaterina Chernova ( efedor...@mirantis.com) написал: Hi guys! Currently Murano holds the *#murano* IRC channel. But all openstack projects have the openstack- prefix in their channel’s name. So I have a question: should we move to *#openstack-murano*? I think it’s a good idea, since it’s more obvious to go to *#openstack-murano* if one needs help with murano. Do you know if anybody tried to get help at *#openstack-murano* and discovered that this is not the official Murano channel ? Would it be hard to migrate from one channel to another? Regards, Kate. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org ?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddevd=AwICAgc=IGDlg0lD0b-nebmJJ0Kp8Ar=I3cSIvyDkys1wUZdtxxtF5qxRkoDWv_Y7wNzrd3ReMUm=adKlfMyngJxcdIXIPM9W6VVMLHMA9FDNtEbjRiBSJv0s=1mjbCcPOcrLy18LVat6mo3EXOX-1qEM87rnAnp83H5ce= __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [sahara] keystone session upgrade
On 07/16/2015 04:31 PM, michael mccune wrote: i will also likely be rewriting the spec to encompass these changes if i can get them working locally. just wanted to follow up before i rewrite the spec. i think the most sensible approach at this point is to store an auth plugin object in our context. this will alleviate some of our reliance on the username/tenant_id/etc. authentication values that we currently use. this object will also be used in conjunction with the session cache to produce clients. the session cache will be removed from the context and instead become a singleton type object in the sahara.service.sessions module. the cache will contain several specific functions for creating session objects for our different needs. for example, nova session will need to pass the specific nova certificate to the session. for non-specific needs the session object can be shared between several clients. the clients themselves will use a combination of auth plugin object and session object for creation. in this manner we can associate different authentications with the sessions as needed and still share the connection pooling and caching that occurs in the session object. this will also allow us to continue to create admin clients as needed, we can either pass an admin authentication object to the client or set the context to have an admin authenticated plugin object. there are still a few questions to be answered about trust scoping, but i think they will fit in this model. i would still be curious to hear any thoughts about this approach, but i will continue to test it and work towards rewriting the spec. regards, mike __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library
Hey Vladimir, So I've been playing with it at the moment because I think the better place to do the script execution is as part of the build process controlled by the fuel-library7.0 spec file[0]. It seems to be a valid way to do it (and would work for our CI jobs to) but the issue i'm running into is the use of ruby/bundler to pull in these packages. Any thoughts on the best way to try and provide the required build environment tools since it appears we build on Centos 6.5 at the moment so I'm running into ruby 1.8.7 issues. -Alex [0] https://review.openstack.org/#/c/202763/9/specs/fuel-library7.0.spec On Fri, Jul 17, 2015 at 2:24 PM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Great that you did this. Now I think I can prepare fuel-main patch to invoke this script right before building fuel-library package. I'll add you to review it. Is it ok if I do this monday morning? Vladimir Kozhukalov On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Vladimir, On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Gathering upstream modules certainly should be implemented as a separate script so as to make it possible to use it wherever we need this (tests, builds, etc.) According to builds there are two things 1) We have so called perestroika package build system (Dmitry Burmistrov is a main contributor here). By the end of next week we are going to switch building all the packages to perestroika. And in order to gather upstream modules right before building fuel-library package, we need to change perestroika build scripts. 2) Currently we build packages using make system and you are right about the place where you need to make changes. https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 If you create shell script, I'll help you to add it to make code. I have updated my review[0] to extract the update logic to it's own bash script that can be invoked by the build scripts. Let me know what would be the best way to wedge this in there. I think for the perestroika this would also be needed for the fuel-library build, so if you point me at that I can see if I can help make that change as well. Thanks, -Alex [0] https://review.openstack.org/#/c/202763/ Vladimir Kozhukalov On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko adide...@mirantis.com wrote: I believe build_repo function is the best way to do this [0]. So for fuel-library we'll need to run a shell script right from the repo before 'touch $$@'. We can make it either conditional ( test -f ./path/additional_build_script.sh bash ./path/additional_build_script.sh ) or as additional parameter to function and add it in fuel-library call [1] Regards, Alex [0] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L16-L37 [1] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L45 On Fri, Jul 17, 2015 at 2:37 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Alex, On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, I think that we should provide a separate script that will fetch the upstream modules into fuel-library/deployment/puppet/ directory. It will allow us to have everything in a single place and use this script in ISO build process and CI jobs. Right. That is what I'm going for. The issue I need help with is the best way to execute this as part of the build process. From what i understand of the build process is that we are using git archive for all pieces so I'm not sure how to wedge in an extra script execution to do the module fetch. The creation of the script isn't the issue, the issue is how can I properly run it as part of the build process. Regards, Alex Thanks, -Alex On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz aschu...@mirantis.com wrote: Hello everyone, I have committed the initial configuration required to start leveraging librarian-puppet as part of the way we pull in upstream puppet modules[0]. Additionally, I have also committed a change that would pull in the openstack-ironic module[1]. The one piece that is missing from this being a complete solution is the ability to run librarian-puppet as part of our build process for the fuel-library. I've looked into the fuel-main build scripts and I think it's over my head to figure this out just by looking. Can anyone explain to me or assist me in how I could go about modifying the existing build system to be able to run librarian-puppet to prepare the source for the package? In my initial investigation, it looks like it would be a modification of the fuel-main/packages/module.mk[3] file. I basically need to do the prepare_library[3] function from the 202763 review[0] after we've pulled all the sources together to fetch the upstream modules. Thanks, -Alex [0]
Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library
Hey All, I've figured it out without having to modify the fuel-main build code. I've updated the fuel-library spec with a build action that invokes the script to pull down external modules. Please take some time to review the two reviews out there for this change to see if there are any issues with the way it is implemented. https://review.openstack.org/#/c/202763/ https://review.openstack.org/#/c/202767/ This is a first step towards being able to pull in unmodified external puppet modules. Thanks, -Alex On Fri, Jul 17, 2015 at 4:23 PM, Andrew Woodward awoodw...@mirantis.com wrote: On Fri, Jul 17, 2015 at 12:24 PM Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Great that you did this. Now I think I can prepare fuel-main patch to invoke this script right before building fuel-library package. I'll add you to review it. Is it ok if I do this monday morning? Keep in minde we agreeded to a deadline to get this sorted and in shape to land by EOD monday or we will have to retain the old, and crappy fork method. If possible please work out how this needs to work as early as possible so Alex can continue. Vladimir Kozhukalov On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Vladimir, On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Gathering upstream modules certainly should be implemented as a separate script so as to make it possible to use it wherever we need this (tests, builds, etc.) According to builds there are two things 1) We have so called perestroika package build system (Dmitry Burmistrov is a main contributor here). By the end of next week we are going to switch building all the packages to perestroika. And in order to gather upstream modules right before building fuel-library package, we need to change perestroika build scripts. 2) Currently we build packages using make system and you are right about the place where you need to make changes. https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 If you create shell script, I'll help you to add it to make code. I have updated my review[0] to extract the update logic to it's own bash script that can be invoked by the build scripts. Let me know what would be the best way to wedge this in there. I think for the perestroika this would also be needed for the fuel-library build, so if you point me at that I can see if I can help make that change as well. Thanks, -Alex [0] https://review.openstack.org/#/c/202763/ Vladimir Kozhukalov On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko adide...@mirantis.com wrote: I believe build_repo function is the best way to do this [0]. So for fuel-library we'll need to run a shell script right from the repo before 'touch $$@'. We can make it either conditional ( test -f ./path/additional_build_script.sh bash ./path/additional_build_script.sh ) or as additional parameter to function and add it in fuel-library call [1] Regards, Alex [0] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L16-L37 [1] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L45 On Fri, Jul 17, 2015 at 2:37 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Alex, On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, I think that we should provide a separate script that will fetch the upstream modules into fuel-library/deployment/puppet/ directory. It will allow us to have everything in a single place and use this script in ISO build process and CI jobs. Right. That is what I'm going for. The issue I need help with is the best way to execute this as part of the build process. From what i understand of the build process is that we are using git archive for all pieces so I'm not sure how to wedge in an extra script execution to do the module fetch. The creation of the script isn't the issue, the issue is how can I properly run it as part of the build process. Regards, Alex Thanks, -Alex On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz aschu...@mirantis.com wrote: Hello everyone, I have committed the initial configuration required to start leveraging librarian-puppet as part of the way we pull in upstream puppet modules[0]. Additionally, I have also committed a change that would pull in the openstack-ironic module[1]. The one piece that is missing from this being a complete solution is the ability to run librarian-puppet as part of our build process for the fuel-library. I've looked into the fuel-main build scripts and I think it's over my head to figure this out just by looking. Can anyone explain to me or assist me in how I could go about modifying the existing build system to be able to run librarian-puppet to prepare the source for the package? In my initial investigation, it looks like it would be a modification of the
Re: [openstack-dev] [nova] Status of identity v3 support
On 7/15/2015 5:38 PM, melanie witt wrote: Hi Everyone, Recently I have started reviewing the patch series about nested quotas in nova [1] and I'm having trouble understanding where we currently are with identity v3 support in nova. From what I read in a semi recent proposal [2] I think things mostly just work if you configure to run with v3, but there are some gaps. Nested quotas use the concept of parent/child projects in keystone v3 to allow parent projects to delegate quota management to subprojects. This means we'd start getting requests with a token scoped to the parent project to modify quota of a child project. With keystone v3 we could get requests with tokens scoped to parent projects that act upon child project resources for all APIs in general. The first patch in the series [3] removes the top-level validation check for context.project_id != project_id in URL, since with v3 it's a supported thing for a parent project to act on child project resources. (I don't think it's completely correct in that I think it would allow unrelated projects to act on one another) Doing this fails the keypairs and security groups tempest tests [4] that verify that one project cannot create keypairs or security group rules in a different project. Question: How can we handle project_id mismatch in a way that supports both keystone v2 and v3? Do we augment the check to fall back on checking if is parent of using keystone API if there's a project_id mismatch? Question: Do we intend to, for example, allow creation of keypairs by a parent on behalf of child being that the private key is returned to the caller? Basically, I feel stuck on these reviews because it appears to me that nova doesn't fully support identity v3 yet. From what I checked, there aren't yet Tempest jobs running against identity v3 either. Can anyone shed some light on this as I'm trying to see a way forward with the nested quotas reviews? Thanks, -melanie (irc: melwitt) [1] https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nested-quota-driver-api,n,z [2] https://review.openstack.org/#/c/103617/ [3] https://review.openstack.org/182140/ [4] http://logs.openstack.org/40/182140/12/check/check-tempest-dsvm-full/8e51c94/logs/testr_results.html.gz __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I've added this to the meetup etherpad for next week: https://etherpad.openstack.org/p/liberty-nova-midcycle Since bknudson worked on the keystone v3 spec for nova and will be sitting in during the meetup next week at some point (since he's local). -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Python 3: 5 more projects with a py34 voting gate, only 4 remaing
On 7/17/2015 6:32 AM, Victor Stinner wrote: Hi, We are close to having a voting py34 gate on all OpenStack libraries and applications. I just made the py34 gate voting for the 5 following projects: * keystone * heat * glance_store: Glance library (py34 is already voting in Glance) * os-brick: Cinder library (py34 is already voting in Cinder) * sqlalchemy-migrate If we can get this working then we can make py34 voting/gating in sqlalchemy-migrate: https://review.openstack.org/#/c/202170/ A voting py34 gate means that we cannot reintroduce Python 3 regressions in the code tested by tox -e py34. Currently, only a small subset of test suites is executed on Python 3.4, but the subset is growing constantly and it already helps to detect various kinds of Python 3 issues. Sirushti Murugesan (who is porting Heat to Python 3) and me proposed a talk Python 3 is coming! to the next OpenStack Summit at Tokyo. We will explain the plan to port OpenStack to Python in depth. There are only 4 remaining projects without py34 voting gate: (1) swift: I sent patches, see the Fix tox -e py34 patch: https://review.openstack.org/#/q/project:openstack/swift+branch:master+topic:py3,n,z (2) horizon: I sent patches: https://review.openstack.org/#/q/topic:bp/porting-python3+project:openstack/horizon,n,z (3) keystonemiddleware: blocked by python-memcached, I sent a pull request 3 months ago and I'm still waiting... https://github.com/linsomniac/python-memcached/pull/67 I may fork the project if the maintainer never reply. Read the current thread [all] Non-responsive upstream libraries (python34 specifically) on openstack-dev. (4) python-savannaaclient: We haven't enough tests to ensure that savanna client works correctly on py33, so, it's kind of premature step. We already have py33 and pypy jobs in experimental pipeline. This client can be ported later. Note: The py34 gate of oslo.messaging is currently non voting because of a bug in Python 3.4.0, fix not backported to Ubuntu Trusty LTS yet: https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1367907 The bug was fixed in Python 3.4 in May 2014 and was reported to Ubuntu in September 2014. Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library
Fantastic, do we have some way to validate that the module was pulled in properly as part of fuel-library CI? On Fri, Jul 17, 2015 at 2:48 PM Alex Schultz aschu...@mirantis.com wrote: Hey All, I've figured it out without having to modify the fuel-main build code. I've updated the fuel-library spec with a build action that invokes the script to pull down external modules. Please take some time to review the two reviews out there for this change to see if there are any issues with the way it is implemented. https://review.openstack.org/#/c/202763/ https://review.openstack.org/#/c/202767/ This is a first step towards being able to pull in unmodified external puppet modules. Thanks, -Alex On Fri, Jul 17, 2015 at 4:23 PM, Andrew Woodward awoodw...@mirantis.com wrote: On Fri, Jul 17, 2015 at 12:24 PM Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Great that you did this. Now I think I can prepare fuel-main patch to invoke this script right before building fuel-library package. I'll add you to review it. Is it ok if I do this monday morning? Keep in minde we agreeded to a deadline to get this sorted and in shape to land by EOD monday or we will have to retain the old, and crappy fork method. If possible please work out how this needs to work as early as possible so Alex can continue. Vladimir Kozhukalov On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Vladimir, On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Gathering upstream modules certainly should be implemented as a separate script so as to make it possible to use it wherever we need this (tests, builds, etc.) According to builds there are two things 1) We have so called perestroika package build system (Dmitry Burmistrov is a main contributor here). By the end of next week we are going to switch building all the packages to perestroika. And in order to gather upstream modules right before building fuel-library package, we need to change perestroika build scripts. 2) Currently we build packages using make system and you are right about the place where you need to make changes. https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 If you create shell script, I'll help you to add it to make code. I have updated my review[0] to extract the update logic to it's own bash script that can be invoked by the build scripts. Let me know what would be the best way to wedge this in there. I think for the perestroika this would also be needed for the fuel-library build, so if you point me at that I can see if I can help make that change as well. Thanks, -Alex [0] https://review.openstack.org/#/c/202763/ Vladimir Kozhukalov On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko adide...@mirantis.com wrote: I believe build_repo function is the best way to do this [0]. So for fuel-library we'll need to run a shell script right from the repo before 'touch $$@'. We can make it either conditional ( test -f ./path/additional_build_script.sh bash ./path/additional_build_script.sh ) or as additional parameter to function and add it in fuel-library call [1] Regards, Alex [0] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L16-L37 [1] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L45 On Fri, Jul 17, 2015 at 2:37 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Alex, On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, I think that we should provide a separate script that will fetch the upstream modules into fuel-library/deployment/puppet/ directory. It will allow us to have everything in a single place and use this script in ISO build process and CI jobs. Right. That is what I'm going for. The issue I need help with is the best way to execute this as part of the build process. From what i understand of the build process is that we are using git archive for all pieces so I'm not sure how to wedge in an extra script execution to do the module fetch. The creation of the script isn't the issue, the issue is how can I properly run it as part of the build process. Regards, Alex Thanks, -Alex On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz aschu...@mirantis.com wrote: Hello everyone, I have committed the initial configuration required to start leveraging librarian-puppet as part of the way we pull in upstream puppet modules[0]. Additionally, I have also committed a change that would pull in the openstack-ironic module[1]. The one piece that is missing from this being a complete solution is the ability to run librarian-puppet as part of our build process for the fuel-library. I've looked into the fuel-main build scripts and I think it's over my head to figure this out just by looking. Can anyone explain to me or assist me in how I could go about
