Re: [openstack-dev] [openstack][neutron] Debugging L3 Agent with PyCharm
File - Settings - Python Debugger Mark Gevent compatible debugging On Thu, Mar 19, 2015 at 12:06 AM, Daniel Comnea comnea.d...@gmail.com wrote: Gal, while i don't have an answer to your question, can you pls share how you enabled the Gevent debugging? Thx, Dani On Wed, Mar 18, 2015 at 10:16 AM, Gal Sagie gal.sa...@gmail.com wrote: Hello all, I am trying to debug the L3-agent code with pycharm, but the debugger doesnt stop on my break points. I have enabled PyCharm Gevent compatible debugging but that doesnt solve the issue (I am able to debug neutron server correctly) Anyone might know what is the problem? Thanks Gal. __ 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 -- Best Regards , The G. __ 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] [designate] Designate performance issues
Hi all. I have setup kilo designate services with powerdns backend and mysql innodb storage in a single node. The services function well at first. However, after inserting 13k A records via API within 3 domains (5k, 5k, 3k for each), the service stops working. designate-api returns 500 and many RPCs timeout designate-central takes 100% cpu, seems trying hard updating domains but failed designate-mdns also takes 100% cpu, flooded with Including all tenants items in query results logs powerdns gets timeout errors during AXFR zones The server doesn't seem to turn any better after suffering in this state for hours. What I could do to recover the service is to cleanup databases and restart the service. My question is: 1. Is it not recommended to create too many records in a single domain? 2. Any suggestions to improve this situation? -- Best Regards, Zhang Gengyuan __ 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] All Cinder Volume Drivers Must Have A Third Party CI by March 19, 2014
Hi Mike, Regarding the GlusterFS CI: As I am dealing with end to end CI process of GlusterFS, please modify the contact person to bharat.kobag...@redhat.com. Because of this I may miss important announcements from you regarding the CI. On 03/19/2015 11:11 AM, Mike Perez wrote: The deadline is almost near. First off I want to thank all driver maintainers who are reporting successfully with their driver CI in Cinder reviews. For many of you, I know you discovered how useful the CI is, in just the bugs it has caught or revealed. OpenStack users that use your solution will appreciate the added stability as well. I have been keeping a report of the different vendors, which I promised to make public: https://docs.google.com/spreadsheets/d/1GrIzXY4djNbJnF3RMw44_2e3aTWgBbgnBlSKafEDNGQ/edit?usp=sharing If you're not marked with a light green or dark green color and you believe this is a mistake, please let me know on IRC via thingee or this email address, and provide proof of multiple reviews your CI has posted results to. For the drivers that have not responded and won't be able to make the deadline. Proposing your driver back into Cinder in Liberty will require a CI reporting before merge back in. I want to make this as easy as possible to be merged back into tree, so I will just do a diff of what's being proposed and what was previously in tree. This should cut down on a review time quite a bit. Drivers that are removed in the Kilo release will be mentioned in the release notes if they were in prior to Kilo. -- Mike Perez On Thu, Jan 15, 2015 at 7:31 PM, Mike Perez thin...@gmail.com wrote: *Note: A more detailed email about this has been sent to all Cinder volume driver maintainers directly.* In the Jan 14th 2015 16:00 UTC Cinder IRC meeting [1], it was agreed by Cinder core and participating vendors that the deadline for vendors to have a third party CI would be: March 19th 2015 There are requirements set for OpenStack Third Party CI's [2]. In addition Cinder third party CI's must: 1) Test all volume drivers your company has integrated in Cinder. 2) Test all fabrics your solution uses. For example, if your company has two volume drivers in Cinder and they both use ISCSI and FibreChannel, you would need to have a CI that tests against four backends and reports the results for each backend, for every Cinder upstream patch. To test we're using a subset of tests in Tempest [6]. To get started, read OpenStack's third party testing documentation [32]. There are a variety of solutions [3] that help setting up a CI, third party mentoring meetings [4], and designated people to answer questions with setting up a third party CI in the #openstack-cinder room [5]. If a solution is not being tested in a CI system and reporting to OpenStack gerrit Cinder patches by the deadline of March 19th 2015, a volume driver could be removed from the Cinder repository as of the Kilo release. Without a CI system, Cinder core is unable to verify your driver works in the Kilo release of Cinder. We will make sure OpenStack users are aware of this via the OpenStack users mailing list and Kilo release notes. Cinder third party CI's have been discussed throughout a variety of ways last year: * Cinder IRC Meetings: [1][9][10][11][12][13][14][15][16] * Midcycle meetups: [17] * OpenStack dev list: [18][19][20][21][22][23][24][25][26][27][28][29] * Design summit sessions: [30][31] If there is something not clear about this email, please email me *directly* with your question. You can also reach me as thingee on Freenode IRC in the #openstack-cinder channel. Again I want you all to be successful in this, and take advantage of this testing you will have with your product. Please communicate with me and reach out to the team for help. -- Mike Perez [1] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-14-16.00.log.html#l-21 [2] - http://ci.openstack.org/third_party.html#requirements [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Existing_CI_Solutions [4] - https://wiki.openstack.org/wiki/Meetings/ThirdParty [5] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Questions [6] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F [7] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-12-10-16.00.log.html#l-471 [8] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19-16.00.log.html#l-34 [9] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-29-16.00.log.html#l-224 [10] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-15-16.00.log.html#l-59 [11] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-08-16.00.log.html#l-17 [12] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-17-16.00.log.html#l-244 [13] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-07-02-16.01.log.html#l-141 [14] -
Re: [openstack-dev] [Neutron] Neutron extenstions
Forwarding my reply to the other thread here: If my memory does not fail me, changes to the API (new resources, new resource attributes or new operations allowed to resources) have always been done according to these criteria: - an opt-in approach: this means we know the expected behavior of the plugin as someone has coded the plugin in such a way that the API change is supported; - an opt-out approach: if the API change does not require explicit backend support, and hence can be deemed supported by all plugins. - a 'core' extension (ones available in neutron/extensions) should be implemented at least by the reference implementation; Now, there might have been examples in the past where criteria were not met, but these should be seen as exceptions rather than the rule, and as such, fixed as defects so that an attribute/resource/operation that is accidentally exposed to a plugin will either be honored as expected or an appropriate failure is propagated to the user. Bottom line, the server must avoid to fail silently, because failing silently is bad for the user. Now both features [1] and [2] violated the opt-in criterion above: they introduced resources attributes in the core models, forcing an undetermined behavior on plugins. I think that keeping [3,4] as is can lead to a poor user experience; IMO it's unacceptable to let a user specify the attribute, and see that ultimately the plugin does not support it. I'd be fine if this was an accident, but doing this by design is a bit evil. So, I'd suggest the following, in order to keep the features in Kilo: - Patches [3, 4] did introduce config flags to control the plugin behavior, but it looks like they were not applied correctly; for instance, the vlan_transparent case was only applied to ML2. Similarly the MTU config flag was not processed server side to ensure that plugins that do not support advertisement do not fail silently. This needs to be rectified. - As for VLAN transparency, we'd need to implement work item 5 (of 6) of spec [2], as this extension without at least a backend able to let tagged traffic pass doesn't seem right. - Ensure we sort out the API tests so that we know how the features behave. Now granted that controlling the API via config flags is not the best solution, as this was always handled through the extension mechanism, but since we've been talking about moving away from extension attributes with [5], it does sound like a reasonable stop-gap solution. Thoughts? Armando [1] http://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html [2] http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html [3] https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/mtu-selection-and-advertisement,n,z [4] https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/nfv-vlan-trunks,n,z [5] https://review.openstack.org/#/c/136760/ On 19 March 2015 at 14:56, Ian Wells ijw.ubu...@cack.org.uk wrote: On 19 March 2015 at 11:44, Gary Kotton gkot...@vmware.com wrote: Hi, Just the fact that we did this does not make it right. But I guess that we are starting to bend the rules. I think that we really need to be far more diligent about this kind of stuff. Having said that we decided the following on IRC: 1. Mtu will be left in the core (all plugins should be aware of this and treat it if necessary) 2. Vlan-transparency will be moved to an extension. Pritesh is working on this. The spec started out as an extension, and in its public review people requested that it not be an extension and that it should instead be core. I accept that we can change our minds, but I believe there should be a good reason for doing so. You haven't given that reason here and you haven't even said who the 'we' is that decided this. Also, as the spec author, I had a conversation with you all but there was no decision at the end of it (I presume that came afterward) and I feel that I have a reasonable right to be involved. Could you at least summarise your reasoning here? I admit that I prefer this to be in core, but I'm not terribly choosy and that's not why I'm asking. I'm more concerned that this is changing our mind at literally the last moment, and in turn wasting a developer's time, when there was a perfectly good process to debate this before coding was begun, and again when the code was up for review, both of which apparently failed. I'd like to understand how we avoid getting here again in the future. I'd also like to be certain we are not simply reversing a choice on a whim. -- Ian. __ 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] [Group-Based-Policy] Service Chain Instance ownership
Hello Folks, [tl;dr] On implicit chains, the Service Chain Instance ownership in GBP is inconsistent, depending on the actor triggering the chain. Possible solution is to have all the implicit SCI owned by an admin, or by the provider of the chain. Any suggestion is welcome. [boringpostwithexampleandstuff] I've recently file a bug [0] regarding Service Chain Instance ownership, and I would like to get some advice on how to proceed with it. Let's take the following final state as an example: PTG-A ---PRS-Chain---PTG-B PTG A is providing a PRS with a redirect action, which is consumed by PTG-B. Reaching this state triggers an implicit SCI creation based on the policy action. The above state can be reached in multiple ways, some of them are: - PTG-A provides PRS-Chain (which is already consumed by PTG-B); - PTG-B consumes PRS-Chain (which is already provided by PTG-A); - Redirect action is added to PRS-Chain (which is already provided and consumed). Depending on how that state is reached, in today's implementation the tenant owning the SCI may be ultimately different! This is definitively a problem, especially when PTG-A and PTG-B are owned by different tenants. If having inconsistent behavior on the same state isn't bad enough, another issue is that whoever triggers the SCI deletion should also own the SCI or will get an exception! And this is definitively not part of the intent. In short, we need to decide who has to own the chain instances (and with them, the network services themselves). There are two main choices: - An Admin owns them all. This will not impact the users' quota, and makes it easier to bridge different tenants' networks (when needed/applicable). The downside (?) is that the user will never see the SCI and will never be able to control the services without admin permissions; - The Provider is always the owner. This solution is trickier as far as quota are concerned, especially when the services are created using VMs (NFV). does the provider need to care about that? why has my VM limit suddenly dropped to 0 now that I'm providing this cursed PRS? On the upside, the provider can control and modify the service itself if he needs to. I personally am a fan of the first option, the user should only care about the Intent, and not about this kind of details. But I would like to have some insight from the community, especially from other projects that may have had this issue and can *provide* (ahah) a bit of their wisdom :) Thanks, Ivar. [0] https://bugs.launchpad.net/group-based-policy/+bug/1432816 __ 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] VLAN transparency support
If my memory does not fail me, changes to the API (new resources, new resource attributes or new operations allowed to resources) have always been done according to these criteria: - an opt-in approach: this means we know the expected behavior of the plugin as someone has coded the plugin in such a way that the API change is supported; - an opt-out approach: if the API change does not require explicit backend support, and hence can be deemed supported by all plugins. - a 'core' extension (ones available in neutron/extensions) should be implemented at least by the reference implementation; Now, there might have been examples in the past where criteria were not met, but these should be seen as exceptions rather than the rule, and as such, fixed as defects so that an attribute/resource/operation that is accidentally exposed to a plugin will either be honored as expected or an appropriate failure is propagated to the user. Bottom line, the server must avoid to fail silently, because failing silently is bad for the user. Now both features [1] and [2] violated the opt-in criterion above: they introduced resources attributes in the core models, forcing an undetermined behavior on plugins. I think that keeping [3,4] as is can lead to a poor user experience; IMO it's unacceptable to let a user specify the attribute, and see that ultimately the plugin does not support it. I'd be fine if this was an accident, but doing this by design is a bit evil. So, I'd suggest the following, in order to keep the features in Kilo: - Patches [3, 4] did introduce config flags to control the plugin behavior, but it looks like they were not applied correctly; for instance, the vlan_transparent case was only applied to ML2. Similarly the MTU config flag was not processed server side to ensure that plugins that do not support advertisement do not fail silently. This needs to be rectified. - As for VLAN transparency, we'd need to implement work item 5 (of 6) of spec [2], as this extension without at least a backend able to let tagged traffic pass doesn't seem right. - Ensure we sort out the API tests so that we know how the features behave. Now granted that controlling the API via config flags is not the best solution, as this was always handled through the extension mechanism, but since we've been talking about moving away from extension attributes with [5], it does sound like a reasonable stop-gap solution. Thoughts? Armando [1] http://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html [2] http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html [3] https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/mtu-selection-and-advertisement,n,z [4] https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/nfv-vlan-trunks,n,z [5] https://review.openstack.org/#/c/136760/ On 19 March 2015 at 12:01, Gary Kotton gkot...@vmware.com wrote: With regards to the MTU can you please point me to where we validate that the MTU defined by the tenant is actually = the supported MTU on the network. I did not see this in the code (maybe I missed something). From: Ian Wells ijw.ubu...@cack.org.uk Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 8:44 PM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] VLAN transparency support Per the other discussion on attributes, I believe the change walks in historical footsteps and it's a matter of project policy choice. That aside, you raised a couple of other issues on IRC: - backward compatibility with plugins that haven't adapted their API - this is addressed in the spec, which should have been implemented in the patches (otherwise I will downvote the patch myself) - behaviour should be as before with the additional feature that you can now tell more about what the plugin is thinking - whether they should be core or an extension - this is a more personal opinion, but on the grounds that all networks are either trunks or not, and all networks have MTUs, I think they do want to be core. I would like to see plugin developers strongly encouraged to consider what they can do on both elements, whereas an extension tends to sideline functionality from view so that plugin writers don't even know it's there for consideration. Aside from that, I'd like to emphasise the value of these patches, so hopefully we can find a way to get them in in some form in this cycle. I admit I'm interested in them because they make it easier to do NFV. But they also help normal cloud users and operators, who otherwise have to do some really strange things [1]. I think it's maybe a little unfair to post reversion patches before discussion, particularly when the patch works, passes tests and implements an approved
[openstack-dev] Refrain Refrain
I OK kook i rigor w assessment of ofiii __ 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][Cinder] Questions re progress
So others have/will chime in here... one thing I think is kinda missing in the statement above is the single host, that's actually the whole point of Ceph and other vendor driven clustered storage technologies out there. There's a ton to choose from at this point, open source as well as proprietary and a lot of them are really really good. This is also very much what DRBD aims to solve for you. You're not tying data access to a single host/node, that's kinda the whole point. Current status of the DRBD driver is: you can have redundant (replicated) storage in Cinder, but the connection to Nova is still done via iSCSI. Granted in the case of DRBD we've still got a ways to go and something we haven't even scratched the surface on much is virtual/shared IP's for targets but we're getting there albeit slowly (there are folks who are doing this already but haven't contributed their work back upstream), so in that case yes we still have a shortcoming in that if the node that's acting as your target server goes down you're kinda hosed. The WIP is that the Nova nodes use DRBD as a transport protocol to the storage nodes, too; that would implicitly be a multi-connection setup. The Nova side https://review.openstack.org/#/c/149244/ got delayed to L, sadly, and so the Cinder side https://review.openstack.org/#/c/156212/ is on hold, too. (We've got github repositories where I try to keep these branches up-to-date for people who want to test, BTW.) Of course, if the hypervisor crashes, you'll have to restart the VMs (or create new ones). If you've got any questions, please don't hesitate to ask me (or drbd-user, if you prefer that). Regards, Phil -- : Ing. Philipp Marek : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com : DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ 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] Let's stick to OpenStack global requirements
Just one question regarding this bit: There are some plans (unfortunately I do not know details, so maybe someone from OSCI could tell more) to split those repositories Splitting of repositories doesn't help to solve python packages conflicts because master node uses a number of openstack components. Anyway it should be done for 7.0 milestone in order to separatre master-node distro from environment one. (e.g. if we going to move master-node to debian) Correct me if I am wrong, but isn't it what we have containers on master node for? We could use their separation to have conflicting versions of python packages for components that are in separate containers (like nailgun). Regards, Maciej Kwiek On Thu, Mar 19, 2015 at 12:01 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: Roman, I like this proposal very much, thanks for the idea and for putting together a straightforward process. I assume you meant: If a requirement that previously was only in Fuel Requirements is merged to Global Requirements, it should be removed from *Fuel* Requirements. Sebastian, We have found ways to resolve the conflicts between clvm and docker, and between ruby versions 1.8 and 2.1, without introducing a separate package repo for Fuel master. I've updated the blueprint to make note of that: https://blueprints.launchpad.net/fuel/+spec/separate-repo-for-master-node On Wed, Mar 18, 2015 at 9:25 AM, Sebastian Kalinowski skalinow...@mirantis.com wrote: I assume that you considered a situation when we have a common repository with RPMs for Fuel master and for nodes. There are some plans (unfortunately I do not know details, so maybe someone from OSCI could tell more) to split those repositories. How this workflow will work with those separated repos? Will we still need it? Thanks! Sebastian 2015-03-18 11:04 GMT+01:00 Roman Prykhodchenko m...@romcheg.me: Hi folks, before you say «romcheg, go away and never come back again!», please read the story that caused me to propose this and the proposed solution. Perhaps it makes you reconsider :) As you know for different reasons, among which are being able to set up everything online and bringing up-to-date packages, we maintain an OSCI repository which is used for building ISOs and deploying OpenStack services. Managing that repo is a pretty hard job. Thus a dedicated group of people is devoted to perform that duty, they are always busy because of a lot of responsibilities they have. At the same time Fuel’s developers are pretty energetic and always want to add new features to Fuel. For that they love to use different libraries, many of which aren’t in the OSCI mirror yet. So they ask OSCI guys to add more and more of those and I guess that’s pretty fine except one little thing — sometimes those libraries conflict with ones, required by OpenStack services. To prevent that from happening someone has to check every patch against the OSCI repo and OpenStack’s global requirements, to detect whether a version bump or adding a new library is required an whether it can be performed. As you can guess, there’s too much of a human factor so statistically no one does that until problems appear. Moreover, theres’ nothing but a «it’s not compatible with OpenStack» yelling from OSCI team that stops developers to change dependencies in Fuel. All the stuff described above causes sometimes tremendous time losses and is very problem-prone. I’d like to propose to make everyone’s life easier by following these steps: - Create a new project called Fuel Requirements, all changes to it should go through a standard review procedure - We strict ourselves to use only packages from both Fuel Requirements and Global Requirements for the version of OpenStack, Fuel is installing in the following manner: - If a requirement is in Global Requirements, the version spec in all Fuel’s components should be exactly like that. - OSCI mirror should contain the maximum version of a requirement that matches its version specification. - If a requirement is not in the global requirements list, then Fuel Requirements list should be used to check whether all Fuel’s components require the same version of a library/package. - OSCI mirror should contain the maximum version of a requirement that matches its version specification. - If a requirement that previously was only in Fuel Requirements is merged to Global Requirements, it should be removed from Global Requirements - Set up CI jobs in both OpenStack CI and FuelCI to check all patches against both Global Requirements and Fuel Requirements and block, if either of checks doesn’t pass - Set up CI jobs to notify OSCI team if either Global Requirements or Fuel Requirements are changed. - Set up requirements proposal jobs that will
Re: [openstack-dev] [Fuel] FFE python-fuelclient improvements
https://review.openstack.org/#/q/status:open+project:stackforge/python-fuelclient+branch:master+topic:bp/re-thinking-fuel-client,n,z https://review.openstack.org/#/q/status:open+project:stackforge/python-fuelclient+branch:master+topic:bp/re-thinking-fuel-client,n,z 17 бер. 2015 о 18:51 Mike Scherbakov mscherba...@mirantis.com написав(ла): Roman, it would be great if you share the links. Thanks! On Tue, Mar 17, 2015 at 5:52 AM, Igor Kalnitsky ikalnit...@mirantis.com mailto:ikalnit...@mirantis.com wrote: Yep, I think we can do merge them. +1 from my side. On Tue, Mar 17, 2015 at 12:50 PM, Evgeniy L e...@mirantis.com mailto:e...@mirantis.com wrote: +1, because those patches are simple don't look destructive. On Mon, Mar 16, 2015 at 7:43 PM, Roman Prykhodchenko m...@romcheg.me mailto:m...@romcheg.me wrote: Hi folks, due to some technical issues we were unable to merge Cliff integration patches to keep ISO build jobs alive. Since now the problem is fixed and we are unblocked, I’d like to ask for a FFE in order to merge that all. - romcheg __ 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 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://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?subject:unsubscribe http://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 -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][FFE] - IdP ID (remote_id) registration and validation
This is a good workaround to allow the authentication on the IdP but with the
new websso is problematic because
you do not know which mapping to use but you have the Shib-Identity-Provider.
With the new information
the entityIDs are associated with the keystone IdP so it is easy to find the
right one. With this approach
you have to analyse all the mapping and select the first that can apply.
Marco
On Wed, Mar 18, 2015 at 05:54:36PM +, Yee, Guang wrote:
I think we can create a mapping which restricts which IdP it is applicable.
When playing around with K2K, I've experimented with multiple IdPs. I
basically chained the IdPs in shibboleth2.xml like this
MetadataProvider type=Chaining
MetadataProvider type=XML file=/etc/keystone/acme_idp_metadata.xml/
MetadataProvider type=XML file=/etc/keystone/beta_idp_metadata.xml/
/MetadataProvider
And with a mapping intended for Acme IdP, we can ensure that only Acme users
can map to group '1234567890'.
{
mapping: {
rules: [
{
local: [
{
user: {
name: {0}
}
},
{
group: {
id: 1234567890
}
}
],
remote: [
{
type: openstack_user
},
{
type: Shib-Identity-Provider,
any_one_of: [
https://acme.com/v3/OS-FEDERATION/saml2/idp;
]
}
]
}
]
}
}
Shibboleth do convey the Shib-Identity-Provider attribute in the request
environment. With this mechanism we should be able to create a rule for
multiple IdPs as well.
Guang
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Wednesday, March 18, 2015 2:41 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Keystone][FFE] - IdP ID (remote_id)
registration and validation
In my opinion you have got into this situation because your federation trust
model is essentially misguided. As I have been arguing since the inception of
federated Keystone, you should have rules for trusted IdPs (already done),
trusted attributes (not done), and then one set of mapping rules that apply
to all IdPs and all attributes (not done). If you had followed this model
(the one Kent originally implemented) you would not be in this situation now.
Concerning the remote user ID, we can guarantee that it is always globally
unique by concatenating the IDP name with the IdP issued user ID, so this
wont cause a problem in mapping rules.
Concerning other identity attributes, there are two types:
- globally known and assigned attributes (such email address and other LDAP
ones) that have unique IDs regardless of the IDP that issued them - the
eduPerson schema attributes are of this type, so the mapping rules for these
are IDP independent, and the trusted IDP rules ensure that you filter out
untrusted ones
- locally issued attributes that mean different things to different IDPs. In
this case you need to concatenate the name of the IDP to the attribute to
make it globally unique, and then the mapping rules will always apply. The
trusted IDP rules will again filter these out or let them pass.
So instead of fixing the model, you are adding more layers of complexity to
the implementation in order to fix conceptual errors in your federation model.
Sadly yours
David
On 17/03/2015 22:28, Marek Denis wrote:
Hello,
One very important feature that we have been working on in the Kilo
development cycle is management of remote_id attributes tied to
Identity Providers in keystone.
This work is crucial for:
- Secure OpenStack identity federation configuration. User is
required to specify what Identity Provider (IdP) issues an assertion
as well as what protocol (s)he wishes to use (typically it would be
SAML2 or OpenId Connect). Based on that knowledge (arbitrarily
specified by a user), keystone fetches mapping rules configured for
{IdP, protocol} pair and applies it on the assertion. As an effect a
set of groups is returned, and by membership of those dynamically
assigned groups (and later roles), an ephemeral user is being granted
access to certain OpenStack resources. Without remote_id attributes, a
user, can arbitrarily choose pair {Identity Provider, protocol}
without respect of issuing Identity Provider. This may lead to a
situation where Identity Provider X issues an assertion, but user
chooses mapping ruleset dedicated for Identity Provider Y, effectively
being granted improper groups (roles).
Re: [openstack-dev] [Fuel] FFE python-fuelclient improvements
+1 from me also On Thu, Mar 19, 2015 at 1:07 PM, Roman Prykhodchenko m...@romcheg.me wrote: https://review.openstack.org/#/q/status:open+project:stackforge/python-fuelclient+branch:master+topic:bp/re-thinking-fuel-client,n,z 17 бер. 2015 о 18:51 Mike Scherbakov mscherba...@mirantis.com написав(ла): Roman, it would be great if you share the links. Thanks! On Tue, Mar 17, 2015 at 5:52 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Yep, I think we can do merge them. +1 from my side. On Tue, Mar 17, 2015 at 12:50 PM, Evgeniy L e...@mirantis.com wrote: +1, because those patches are simple don't look destructive. On Mon, Mar 16, 2015 at 7:43 PM, Roman Prykhodchenko m...@romcheg.me wrote: Hi folks, due to some technical issues we were unable to merge Cliff integration patches to keep ISO build jobs alive. Since now the problem is fixed and we are unblocked, I’d like to ask for a FFE in order to merge that all. - romcheg __ 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 __ 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 __ 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://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 -- Best regards, Nick Markov __ 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] [infra][horizon] Need help at debugging requirements issue
Hello, I was trying to raise the cap for Django in[1]. It looks quite simple, current requirements is Django=1.4.2,1.7 and I simply removed the upper boundary: Django=1.4.2 with the result, django-nose is not installed any more. (That's a rest dependency for horizon), it's listed in the same global-requirements file: django-nose (no version requirement). Sadly, I can not figure out, why that happens and how to fix that. In local tests, this just works. Any hints please? Thanks, Matthias [1] https://review.openstack.org/#/c/155353/ -- Matthias Runge mru...@redhat.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
[openstack-dev] [heat][congress] Stack lifecycle plugpoint as an enabler for cloud provider's services
Hi, I'm looking at this interesting blueprint https://blueprints.launchpad.net/heat/+spec/stack-lifecycle-plugpoint and I hope you can easily clarify some things to me. I see the following statements related to this BP: * [in problem description section]: There are at least two primary use cases. (1) Enabling holistic (whole-pattern) scheduling of the virtual resources in a template instance (stack) prior to creating or deleting them. This would usually include making decisions about where to host virtual resources in the physical infrastructure to satisfy policy requirements. * [in proposed change section]: Pre and post operation methods should not modify the parameter stack(s). Any modifications would be considered to be a bug. * [in Patch set 7 comment by Thomas]: Are the plug-ins allowed to modify the stack? If yes, what parts can they modify? If not, should some code be added to restrict modifications? * [in Patch set 8 comment by Bill] : @Thomas Spatzier, The cleanest approach would be to not allow changes to the stack parameter(s). Since this is cloud-provider-supplied code, I think that it is reasonable to not enforce this restriction, and to treat any modifications of the stack parameter(s) as a defect in the cloud provider's extension code. From the problem description one might understand it's desired to allow modification of resource placement (i.e. making decisions where to host...) by cloud provider plug-point code. Does should not modify the parameter stack blocks this desired capability? Or is it just a rule not to touch original parameters' values but still allow modifying, let's say availability_zone property as long it's not effected by stack parameters? In case the original purpose of plugpoint mechanism doesn't allow changing the stack, I'd suggest letting the user creating the stack, explicitly 'grant' the cloud provider to enhance his stack characteristics by enabling cloud provider's extra services. By 'explicitly grant' I thought on introducing a sort of a Policy resource type that the stack creator will be able to express his desired services he want to leverage. In case such grant appears in the stack, the plug-point code is allowed to modify the stack to provide the desired service. I guess it may be a possible enabler to Congress' policies as well. Thanks, -Avi __ 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] Let's stick to OpenStack global requirements
Folks, I assume you meant: If a requirement that previously was only in Fuel Requirements is merged to Global Requirements, it should be removed from *Fuel* Requirements». Exactly. I'm not sure it's good idea. We should stay so close to upstream distro as we can. It should be very important reason to update package against it's upstream distro The issue is the following: OpenStack’s components are tested against those versions of dependencies, that are specified in their requirements. IIRC those requirements are set up by pip so CI nodes contain latest versions of python packages that match their specs. The question is whether it’s required to ship OpenStack services with packages from a distro or with packages, that are used for testing. Splitting of repositories doesn't help to solve python packages conflicts because master node uses a number of openstack components. On the master node itself conflicts won’t happen because the components are run in their containers. - romcheg 19 бер. 2015 о 10:47 Dmitry Burmistrov dburmist...@mirantis.com написав(ла): Roman, all - OSCI mirror should contain the maximum version of a requirement that matches its version specification. I'm not sure it's good idea. We should stay so close to upstream distro as we can. It should be very important reason to update package against it's upstream distro version. If we update some package, we should maintain it too. Tracking bugs, CVEs and so on. The more packages, the more efforts to support it. - Set up CI jobs to notify OSCI team if either Global Requirements or Fuel Requirements are changed. - Set up requirements proposal jobs that will automatically propose changes to all fuel projects once either of requirements lists was changed Need to be discussed and investigated. Sebastian, Dmitry, There are some plans (unfortunately I do not know details, so maybe someone from OSCI could tell more) to split those repositories Splitting of repositories doesn't help to solve python packages conflicts because master node uses a number of openstack components. Anyway it should be done for 7.0 milestone in order to separatre master-node distro from environment one. (e.g. if we going to move master-node to debian) On Thu, Mar 19, 2015 at 12:01 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: Roman, I like this proposal very much, thanks for the idea and for putting together a straightforward process. I assume you meant: If a requirement that previously was only in Fuel Requirements is merged to Global Requirements, it should be removed from *Fuel* Requirements. Sebastian, We have found ways to resolve the conflicts between clvm and docker, and between ruby versions 1.8 and 2.1, without introducing a separate package repo for Fuel master. I've updated the blueprint to make note of that: https://blueprints.launchpad.net/fuel/+spec/separate-repo-for-master-node On Wed, Mar 18, 2015 at 9:25 AM, Sebastian Kalinowski skalinow...@mirantis.com wrote: I assume that you considered a situation when we have a common repository with RPMs for Fuel master and for nodes. There are some plans (unfortunately I do not know details, so maybe someone from OSCI could tell more) to split those repositories. How this workflow will work with those separated repos? Will we still need it? Thanks! Sebastian 2015-03-18 11:04 GMT+01:00 Roman Prykhodchenko m...@romcheg.me: Hi folks, before you say «romcheg, go away and never come back again!», please read the story that caused me to propose this and the proposed solution. Perhaps it makes you reconsider :) As you know for different reasons, among which are being able to set up everything online and bringing up-to-date packages, we maintain an OSCI repository which is used for building ISOs and deploying OpenStack services. Managing that repo is a pretty hard job. Thus a dedicated group of people is devoted to perform that duty, they are always busy because of a lot of responsibilities they have. At the same time Fuel’s developers are pretty energetic and always want to add new features to Fuel. For that they love to use different libraries, many of which aren’t in the OSCI mirror yet. So they ask OSCI guys to add more and more of those and I guess that’s pretty fine except one little thing — sometimes those libraries conflict with ones, required by OpenStack services. To prevent that from happening someone has to check every patch against the OSCI repo and OpenStack’s global requirements, to detect whether a version bump or adding a new library is required an whether it can be performed. As you can guess, there’s too much of a human factor so statistically no one does that until problems appear. Moreover, theres’ nothing but a «it’s not compatible with OpenStack» yelling from OSCI team that stops developers to change dependencies in Fuel. All the stuff
[openstack-dev] [Ceilometer]Add hardware pollster of memory buffer and cache
Hello everyone, I am using Ceilometer to monitor both physical servers and virtutal machines in IAAS. And I found current Ceilometer only support 4 memory oid of SNMP: _memory_total_oid = 1.3.6.1.4.1.2021.4.5.0 _memory_avail_real_oid = 1.3.6.1.4.1.2021.4.6.0 _memory_total_swap_oid = 1.3.6.1.4.1.2021.4.3.0 _memory_avail_swap_oid = 1.3.6.1.4.1.2021.4.4.0 But in practice, memory cache and buffer are also very useful infomation. So I'd like to add two hardware pollster, MemoryCachePollster and MemoryBufferPollster. And I want to know is there anyone else insterested in it and should I submit blueprint on launchpad? Thanks. -- Luo gangyiluogan...@chinamobile.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] [Nova][Cinder] Questions re progress
Hi Adam, Disclaimer: i work for a company interested in providing solutions based on openstack, but this email should not be considered marketing/promotional Regarding your second question Using Swift as a back-end for Cinder, we already have a solution for this, a part of which is a Cinder driver (already merged), and another part is our custom middle layer between swift and fuse (available partially open-source, for free). This solution allows you to use your swift cluster as shared storage for your nova compute nodes (using cinder volume driver) so all nodes can see all the volumes. If you would like more details you can contact me at this email address. *Eduard * __ 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] Let's stick to OpenStack global requirements
Roman, all - OSCI mirror should contain the maximum version of a requirement that matches its version specification. I'm not sure it's good idea. We should stay so close to upstream distro as we can. It should be very important reason to update package against it's upstream distro version. If we update some package, we should maintain it too. Tracking bugs, CVEs and so on. The more packages, the more efforts to support it. - Set up CI jobs to notify OSCI team if either Global Requirements or Fuel Requirements are changed. - Set up requirements proposal jobs that will automatically propose changes to all fuel projects once either of requirements lists was changed Need to be discussed and investigated. Sebastian, Dmitry, There are some plans (unfortunately I do not know details, so maybe someone from OSCI could tell more) to split those repositories Splitting of repositories doesn't help to solve python packages conflicts because master node uses a number of openstack components. Anyway it should be done for 7.0 milestone in order to separatre master-node distro from environment one. (e.g. if we going to move master-node to debian) On Thu, Mar 19, 2015 at 12:01 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: Roman, I like this proposal very much, thanks for the idea and for putting together a straightforward process. I assume you meant: If a requirement that previously was only in Fuel Requirements is merged to Global Requirements, it should be removed from *Fuel* Requirements. Sebastian, We have found ways to resolve the conflicts between clvm and docker, and between ruby versions 1.8 and 2.1, without introducing a separate package repo for Fuel master. I've updated the blueprint to make note of that: https://blueprints.launchpad.net/fuel/+spec/separate-repo-for-master-node On Wed, Mar 18, 2015 at 9:25 AM, Sebastian Kalinowski skalinow...@mirantis.com wrote: I assume that you considered a situation when we have a common repository with RPMs for Fuel master and for nodes. There are some plans (unfortunately I do not know details, so maybe someone from OSCI could tell more) to split those repositories. How this workflow will work with those separated repos? Will we still need it? Thanks! Sebastian 2015-03-18 11:04 GMT+01:00 Roman Prykhodchenko m...@romcheg.me: Hi folks, before you say «romcheg, go away and never come back again!», please read the story that caused me to propose this and the proposed solution. Perhaps it makes you reconsider :) As you know for different reasons, among which are being able to set up everything online and bringing up-to-date packages, we maintain an OSCI repository which is used for building ISOs and deploying OpenStack services. Managing that repo is a pretty hard job. Thus a dedicated group of people is devoted to perform that duty, they are always busy because of a lot of responsibilities they have. At the same time Fuel’s developers are pretty energetic and always want to add new features to Fuel. For that they love to use different libraries, many of which aren’t in the OSCI mirror yet. So they ask OSCI guys to add more and more of those and I guess that’s pretty fine except one little thing — sometimes those libraries conflict with ones, required by OpenStack services. To prevent that from happening someone has to check every patch against the OSCI repo and OpenStack’s global requirements, to detect whether a version bump or adding a new library is required an whether it can be performed. As you can guess, there’s too much of a human factor so statistically no one does that until problems appear. Moreover, theres’ nothing but a «it’s not compatible with OpenStack» yelling from OSCI team that stops developers to change dependencies in Fuel. All the stuff described above causes sometimes tremendous time losses and is very problem-prone. I’d like to propose to make everyone’s life easier by following these steps: - Create a new project called Fuel Requirements, all changes to it should go through a standard review procedure - We strict ourselves to use only packages from both Fuel Requirements and Global Requirements for the version of OpenStack, Fuel is installing in the following manner: - If a requirement is in Global Requirements, the version spec in all Fuel’s components should be exactly like that. - OSCI mirror should contain the maximum version of a requirement that matches its version specification. - If a requirement is not in the global requirements list, then Fuel Requirements list should be used to check whether all Fuel’s components require the same version of a library/package. - OSCI mirror should contain the maximum version of a requirement that matches its version specification. - If a requirement that previously was only in Fuel Requirements is merged to Global Requirements, it should be removed from Global
[openstack-dev] [Neutron] VLAN transparency support
Hi, It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others. I do not think that this is the correct way to go and we should do this as all other extensions have been maintained. I have posted a revert (https://review.openstack.org/#/c/165776/) - please feel free to knack if it is invalid. Thanks Gary __ 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] VLAN transparency support
Hi, This patch has the same addition too - https://review.openstack.org/#/c/154921/. We should also revert that one. Thanks Gary From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN transparency support Hi, It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others. I do not think that this is the correct way to go and we should do this as all other extensions have been maintained. I have posted a revert (https://review.openstack.org/#/c/165776/) - please feel free to knack if it is invalid. Thanks Gary __ 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] Mellanox request for permission for Nova CI
Hi Joe, Sorry for the late response. Here are some latest logs for the Nova CI: http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20150318_1650/ http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20150318_1506/ http://144.76.193.39/ci-artifacts/37/165437/1/check-nova/Check-MLNX-Nova-ML2-Sriov-driver/e90a677/ http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20150318_1851/ I can provide more if needed. Thanks, Nurit. From: Joe Gordon [mailto:joe.gord...@gmail.com] Sent: Wednesday, March 11, 2015 7:50 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Mellanox request for permission for Nova CI On Wed, Mar 11, 2015 at 12:49 AM, Nurit Vilosny nur...@mellanox.commailto:nur...@mellanox.com wrote: Hi , I would like to ask for a CI permission to start commenting on Nova branch. Mellanox is engaged in pci pass-through features for quite some time now. We have an operating Neutron CI for ~2 years, and since the pci pass-through features are part of Nova as well, we would like to start monitoring Nova’s patches. Our CI had been silently running locally over the past couple of weeks, and I would like to step ahead, and start commenting in a non-voting mode. During this period we will be closely monitor our systems and be ready to solve any problem that might occur. Do you have a link to the output of your testing system, so we can check what its testing etc. Thanks, Nurit Vilosny SW Cloud Solutions Manager Mellanox Technologies 13 Zarchin St. Raanana, Israel Office: 972-74-712-9410 Cell: 972-54-4713000 Fax: 972-74-712-9111 __ 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] Let's stick to OpenStack global requirements
Folks, Correct me if I am wrong, but isn't it what we have containers on master node for? On the master node itself conflicts won’t happen because the components are run in their containers. Do you propose to use _separate_ package repository for each docker container? (It means separate gerrit project for each package of each container, including openstack projects) On Thu, Mar 19, 2015 at 1:16 PM, Roman Prykhodchenko m...@romcheg.me wrote: Folks, I assume you meant: If a requirement that previously was only in Fuel Requirements is merged to Global Requirements, it should be removed from *Fuel* Requirements». Exactly. I'm not sure it's good idea. We should stay so close to upstream distro as we can. It should be very important reason to update package against it's upstream distro The issue is the following: OpenStack’s components are tested against those versions of dependencies, that are specified in their requirements. IIRC those requirements are set up by pip so CI nodes contain latest versions of python packages that match their specs. The question is whether it’s required to ship OpenStack services with packages from a distro or with packages, that are used for testing. Splitting of repositories doesn't help to solve python packages conflicts because master node uses a number of openstack components. On the master node itself conflicts won’t happen because the components are run in their containers. - romcheg 19 бер. 2015 о 10:47 Dmitry Burmistrov dburmist...@mirantis.com написав(ла): Roman, all - OSCI mirror should contain the maximum version of a requirement that matches its version specification. I'm not sure it's good idea. We should stay so close to upstream distro as we can. It should be very important reason to update package against it's upstream distro version. If we update some package, we should maintain it too. Tracking bugs, CVEs and so on. The more packages, the more efforts to support it. - Set up CI jobs to notify OSCI team if either Global Requirements or Fuel Requirements are changed. - Set up requirements proposal jobs that will automatically propose changes to all fuel projects once either of requirements lists was changed Need to be discussed and investigated. Sebastian, Dmitry, There are some plans (unfortunately I do not know details, so maybe someone from OSCI could tell more) to split those repositories Splitting of repositories doesn't help to solve python packages conflicts because master node uses a number of openstack components. Anyway it should be done for 7.0 milestone in order to separatre master-node distro from environment one. (e.g. if we going to move master-node to debian) On Thu, Mar 19, 2015 at 12:01 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: Roman, I like this proposal very much, thanks for the idea and for putting together a straightforward process. I assume you meant: If a requirement that previously was only in Fuel Requirements is merged to Global Requirements, it should be removed from *Fuel* Requirements. Sebastian, We have found ways to resolve the conflicts between clvm and docker, and between ruby versions 1.8 and 2.1, without introducing a separate package repo for Fuel master. I've updated the blueprint to make note of that: https://blueprints.launchpad.net/fuel/+spec/separate-repo-for-master-node On Wed, Mar 18, 2015 at 9:25 AM, Sebastian Kalinowski skalinow...@mirantis.com wrote: I assume that you considered a situation when we have a common repository with RPMs for Fuel master and for nodes. There are some plans (unfortunately I do not know details, so maybe someone from OSCI could tell more) to split those repositories. How this workflow will work with those separated repos? Will we still need it? Thanks! Sebastian 2015-03-18 11:04 GMT+01:00 Roman Prykhodchenko m...@romcheg.me: Hi folks, before you say «romcheg, go away and never come back again!», please read the story that caused me to propose this and the proposed solution. Perhaps it makes you reconsider :) As you know for different reasons, among which are being able to set up everything online and bringing up-to-date packages, we maintain an OSCI repository which is used for building ISOs and deploying OpenStack services. Managing that repo is a pretty hard job. Thus a dedicated group of people is devoted to perform that duty, they are always busy because of a lot of responsibilities they have. At the same time Fuel’s developers are pretty energetic and always want to add new features to Fuel. For that they love to use different libraries, many of which aren’t in the OSCI mirror yet. So they ask OSCI guys to add more and more of those and I guess that’s pretty fine except one little thing — sometimes those libraries conflict with ones, required by OpenStack services. To prevent that from happening someone has to check every
Re: [openstack-dev] [Fuel] Let's stick to OpenStack global requirements
I guess it would depend on how many docker containers are running on master node and if we are able to pull off such stunt :). I am not familiar with the amount of work needed to do sth like that, so the proposition may be silly. Just let me know if it is. On Thu, Mar 19, 2015 at 11:51 AM, Dmitry Burmistrov dburmist...@mirantis.com wrote: Folks, Correct me if I am wrong, but isn't it what we have containers on master node for? On the master node itself conflicts won’t happen because the components are run in their containers. Do you propose to use _separate_ package repository for each docker container? (It means separate gerrit project for each package of each container, including openstack projects) On Thu, Mar 19, 2015 at 1:16 PM, Roman Prykhodchenko m...@romcheg.me wrote: Folks, I assume you meant: If a requirement that previously was only in Fuel Requirements is merged to Global Requirements, it should be removed from *Fuel* Requirements». Exactly. I'm not sure it's good idea. We should stay so close to upstream distro as we can. It should be very important reason to update package against it's upstream distro The issue is the following: OpenStack’s components are tested against those versions of dependencies, that are specified in their requirements. IIRC those requirements are set up by pip so CI nodes contain latest versions of python packages that match their specs. The question is whether it’s required to ship OpenStack services with packages from a distro or with packages, that are used for testing. Splitting of repositories doesn't help to solve python packages conflicts because master node uses a number of openstack components. On the master node itself conflicts won’t happen because the components are run in their containers. - romcheg 19 бер. 2015 о 10:47 Dmitry Burmistrov dburmist...@mirantis.com написав(ла): Roman, all - OSCI mirror should contain the maximum version of a requirement that matches its version specification. I'm not sure it's good idea. We should stay so close to upstream distro as we can. It should be very important reason to update package against it's upstream distro version. If we update some package, we should maintain it too. Tracking bugs, CVEs and so on. The more packages, the more efforts to support it. - Set up CI jobs to notify OSCI team if either Global Requirements or Fuel Requirements are changed. - Set up requirements proposal jobs that will automatically propose changes to all fuel projects once either of requirements lists was changed Need to be discussed and investigated. Sebastian, Dmitry, There are some plans (unfortunately I do not know details, so maybe someone from OSCI could tell more) to split those repositories Splitting of repositories doesn't help to solve python packages conflicts because master node uses a number of openstack components. Anyway it should be done for 7.0 milestone in order to separatre master-node distro from environment one. (e.g. if we going to move master-node to debian) On Thu, Mar 19, 2015 at 12:01 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: Roman, I like this proposal very much, thanks for the idea and for putting together a straightforward process. I assume you meant: If a requirement that previously was only in Fuel Requirements is merged to Global Requirements, it should be removed from *Fuel* Requirements. Sebastian, We have found ways to resolve the conflicts between clvm and docker, and between ruby versions 1.8 and 2.1, without introducing a separate package repo for Fuel master. I've updated the blueprint to make note of that: https://blueprints.launchpad.net/fuel/+spec/separate-repo-for-master-node On Wed, Mar 18, 2015 at 9:25 AM, Sebastian Kalinowski skalinow...@mirantis.com wrote: I assume that you considered a situation when we have a common repository with RPMs for Fuel master and for nodes. There are some plans (unfortunately I do not know details, so maybe someone from OSCI could tell more) to split those repositories. How this workflow will work with those separated repos? Will we still need it? Thanks! Sebastian 2015-03-18 11:04 GMT+01:00 Roman Prykhodchenko m...@romcheg.me: Hi folks, before you say «romcheg, go away and never come back again!», please read the story that caused me to propose this and the proposed solution. Perhaps it makes you reconsider :) As you know for different reasons, among which are being able to set up everything online and bringing up-to-date packages, we maintain an OSCI repository which is used for building ISOs and deploying OpenStack services. Managing that repo is a pretty hard job. Thus a dedicated group of people is devoted to perform that duty, they are always busy because of a lot of responsibilities they
[openstack-dev] [oslo.config][kolla] modular backends for oslo.cfg
Hello, While on a long oversea flight with Sebastien Han we were talking how he had implemented ceph-docker with central configuration over etcd. We quickly came up to the conclusion that if we wanted to have that in Kolla it would be neat if it was done straight from oslo.config so that would quickly override the default keys in a central point. There is multiple advantage to use that method not just for containers but as well to avoid issues when orchestrating an openstack deployment. I have heard arguments that this should be the job of an ansible/puppet/chef tool and while I completely agree I just don't think it has to write to files the tool would just write to the etcd database. I have quickly came up with a quick and dirty POC on oslo.cfg here : https://github.com/chmouel/oslo.config/commit/01ee54dd5219b1434eaac422055b58e77694d89f and the demo : https://gist.github.com/chmouel/05fb715f96344161268c What others thinks about it ? I believe if we wanted to do that we would have to add a stevesdor based modular backend support directly to oslo.cfg first and have an etcd backend implemented. Chmouel PS: I am using etcd here cause it's easy and fancy but this could be any backends like a DB/NoSQL/Swift or whatever if we wanted __ 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] development tools
Hello, Some time ago I wrote some small tools that make Fuel development easier and it was suggested to add info about them to the documentation -- here's the review link [1]. Evgenyi Li correctly pointed out that we already have something like fuel_development already in fuel-web. I think though that we shouldn't mix such stuff directly into fuel-web, I mean we recently migrated CLI to a separate repo to make fuel-web thinner. So a suggestion -- maybe make these tools more official and create stackforge repos for them? I think dev ecosystem could benefit by having some standard way of dealing with the ISO (for example we get questions from people how to apply new openstack.yaml config to the DB). At the same time we could get rid of fuel_development and merge that into the new repos (it has the useful 'revert' functionality that I didn't think of :)) P. [1] https://review.openstack.org/#/c/140355/9/docs/develop/env.rst __ 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] [Kolla] PTL Candidacy
Congrats, sdake !! -- pshige 2015-03-18 16:09 GMT+09:00 Daniel Comnea comnea.d...@gmail.com: Congrats Steve! On Wed, Mar 18, 2015 at 12:51 AM, Daneyon Hansen (danehans) daneh...@cisco.com wrote: Congratulations Steve! Regards, Daneyon Hansen Software Engineer Email: daneh...@cisco.com Phone: 303-718-0400 http://about.me/daneyon_hansen From: Angus Salkeld asalk...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, March 17, 2015 at 5:05 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Kolla] PTL Candidacy There have been no other candidates within the allowed time, so congratulations Steve on being the new Kolla PTL. Regards Angus Salkeld On Thu, Mar 12, 2015 at 8:13 PM, Angus Salkeld asalk...@mirantis.com wrote: Candidacy confirmed. -Angus On Thu, Mar 12, 2015 at 6:54 PM, Steven Dake (stdake) std...@cisco.com wrote: I am running for PTL for the Kolla project. I have been executing in an unofficial PTL capacity for the project for the Kilo cycle, but I feel it is important for our community to have an elected PTL and have asked Angus Salkeld, who has no outcome in the election, to officiate the election [1]. For the Kilo cycle our community went from zero LOC to a fully working implementation of most of the services based upon Kubernetes as the backend. Recently I led the effort to remove Kubernetes as a backend and provide container contents, building, and management on bare metal using docker-compose which is nearly finished. At the conclusion of Kilo, it should be possible from one shell script to start an AIO full deployment of all of the current OpenStack git-namespaced services using containers built from RPM packaging. For Liberty, I’d like to take our community and code to the next level. Since our containers are fairly solid, I’d like to integrate with existing projects such as TripleO, os-ansible-deployment, or Fuel. Alternatively the community has shown some interest in creating a multi-node HA-ified installation toolchain. I am deeply committed to leading the community where the core developers want the project to go, wherever that may be. I am strongly in favor of adding HA features to our container architecture. I would like to add .deb package support and from-source support to our docker container build system. I would like to implement a reference architecture where our containers can be used as a building block for deploying a reference platform of 3 controller nodes, ~100 compute nodes, and ~10 storage nodes. I am open to expanding our scope to address full deployment, but would prefer to merge our work with one or more existing upstreams such as TripelO, os-ansible-deployment, and Fuel. Finally I want to finish the job on functional testing, so all of our containers are functionally checked and gated per commit on Fedora, CentOS, and Ubuntu. I am experienced as a PTL, leading the Heat Orchestration program from zero LOC through OpenStack integration for 3 development cycles. I write code as a PTL and was instrumental in getting the Magnum Container Service code-base kicked off from zero LOC where Adrian Otto serves as PTL. My past experiences include leading Corosync from zero LOC to a stable building block of High Availability in Linux. Prior to that I was part of a team that implemented Carrier Grade Linux. I have a deep and broad understanding of open source, software development, high performance team leadership, and distributed computing. I would be pleased to serve as PTL for Kolla for the Liberty cycle and welcome your vote. Regards -steve [1] https://wiki.openstack.org/wiki/Kolla/PTL_Elections_March_2015 __ 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
Re: [openstack-dev] [Keystone][FFE] - IdP ID (remote_id) registration and validation
This is more in line with my argument that we should not have 100
different end points and mapping rules for a federation of 100 IdPs, but
rather one end point and one mapping for all trusted IdPs. But I still
think that in order to make this design waterproof we need a trusted
attributes policy as well, to ensure that:
i) all untrusted and unthought off attributes are discarded before the
mapping takes place, so that mistakes are not inadvertently made in the
mapping rules
ii) all attribute types are checked to make sure that they are all
globally unique before mapping takes place
regards
David
On 18/03/2015 17:54, Yee, Guang wrote:
I think we can create a mapping which restricts which IdP it is
applicable. When playing around with K2K, I've experimented with
multiple IdPs. I basically chained the IdPs in shibboleth2.xml like
this
MetadataProvider type=Chaining MetadataProvider type=XML
file=/etc/keystone/acme_idp_metadata.xml/ MetadataProvider
type=XML file=/etc/keystone/beta_idp_metadata.xml/
/MetadataProvider
And with a mapping intended for Acme IdP, we can ensure that only
Acme users can map to group '1234567890'.
{ mapping: { rules: [ { local: [ { user: { name: {0} }
}, { group: { id: 1234567890 } } ], remote: [ { type:
openstack_user }, { type: Shib-Identity-Provider, any_one_of:
[ https://acme.com/v3/OS-FEDERATION/saml2/idp; ] } ] } ] } }
Shibboleth do convey the Shib-Identity-Provider attribute in the
request environment. With this mechanism we should be able to create
a rule for multiple IdPs as well.
Guang
-Original Message- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Wednesday, March 18, 2015 2:41
AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev]
[Keystone][FFE] - IdP ID (remote_id) registration and validation
In my opinion you have got into this situation because your
federation trust model is essentially misguided. As I have been
arguing since the inception of federated Keystone, you should have
rules for trusted IdPs (already done), trusted attributes (not done),
and then one set of mapping rules that apply to all IdPs and all
attributes (not done). If you had followed this model (the one Kent
originally implemented) you would not be in this situation now.
Concerning the remote user ID, we can guarantee that it is always
globally unique by concatenating the IDP name with the IdP issued
user ID, so this wont cause a problem in mapping rules.
Concerning other identity attributes, there are two types: - globally
known and assigned attributes (such email address and other LDAP
ones) that have unique IDs regardless of the IDP that issued them -
the eduPerson schema attributes are of this type, so the mapping
rules for these are IDP independent, and the trusted IDP rules ensure
that you filter out untrusted ones - locally issued attributes that
mean different things to different IDPs. In this case you need to
concatenate the name of the IDP to the attribute to make it globally
unique, and then the mapping rules will always apply. The trusted IDP
rules will again filter these out or let them pass.
So instead of fixing the model, you are adding more layers of
complexity to the implementation in order to fix conceptual errors in
your federation model.
Sadly yours
David
On 17/03/2015 22:28, Marek Denis wrote:
Hello,
One very important feature that we have been working on in the Kilo
development cycle is management of remote_id attributes tied to
Identity Providers in keystone.
This work is crucial for:
- Secure OpenStack identity federation configuration. User is
required to specify what Identity Provider (IdP) issues an
assertion as well as what protocol (s)he wishes to use (typically
it would be SAML2 or OpenId Connect). Based on that knowledge
(arbitrarily specified by a user), keystone fetches mapping rules
configured for {IdP, protocol} pair and applies it on the
assertion. As an effect a set of groups is returned, and by
membership of those dynamically assigned groups (and later roles),
an ephemeral user is being granted access to certain OpenStack
resources. Without remote_id attributes, a user, can arbitrarily
choose pair {Identity Provider, protocol} without respect of
issuing Identity Provider. This may lead to a situation where
Identity Provider X issues an assertion, but user chooses mapping
ruleset dedicated for Identity Provider Y, effectively being
granted improper groups (roles). As part of various federation
protocols, every Identity Provider issues an identifier allowing
trusting peers (Keystone servers in this case) to reliably
identify issuer of the assertion. That said, remote_id attributes
allow cloud administrators to match assertions with Identity
Providers objects configured in keystone (i.e. situation depicted
above would not happen, as keystone object Identity Provider Y
would accept assertions issued by
Re: [openstack-dev] [Neutron] Neutron extenstions
Hi, Changed the subject so that it may draw a little attention. There were 2 patches approved that kind of break the API (in my humble opinion): https://review.openstack.org/#/c/154921/ and https://review.openstack.org/#/c/158420/ In both of these two new fields were added to the base attributes - mtu and vlan_transparency Reverts for them are: https://review.openstack.org/165801 (mtu) and https://review.openstack.org/165776 (vlan transparency). In my opinion these should be added as separate extensions. Thanks Gary From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 2:32 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] VLAN transparency support Hi, This patch has the same addition too - https://review.openstack.org/#/c/154921/. We should also revert that one. Thanks Gary From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN transparency support Hi, It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others. I do not think that this is the correct way to go and we should do this as all other extensions have been maintained. I have posted a revert (https://review.openstack.org/#/c/165776/) - please feel free to knack if it is invalid. Thanks Gary __ 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] PTL elections
On Wed, Mar 18, 2015 at 6:59 AM, Serg Melikyan smelik...@mirantis.com wrote: Thank you! On Wed, Mar 18, 2015 at 8:28 AM, Sergey Lukjanov slukja...@mirantis.com wrote: The PTL candidacy proposal time frame ended and we have only one candidate. So, Serg Melikyan, my congratulations! Results documented in https://wiki.openstack.org/wiki/Murano/PTL_Elections_Kilo_Liberty#PTL On Wed, Mar 11, 2015 at 2:04 AM, Sergey Lukjanov slukja...@mirantis.com wrote: Hi folks, due to the requirement to have officially elected PTL, we're running elections for the Murano PTL for Kilo and Liberty cycles. Schedule and policies are fully aligned with official OpenStack PTLs elections. You can find more info in official elections wiki page [0] and the same page for Murano elections [1], additionally some more info in the past official nominations opening email [2]. Timeline: till 05:59 UTC March 17, 2015: Open candidacy to PTL positions March 17, 2015 - 1300 UTC March 24, 2015: PTL elections To announce your candidacy please start a new openstack-dev at lists.openstack.org mailing list thread with the following subject: [murano] PTL Candidacy. [0] https://wiki.openstack.org/wiki/PTL_Elections_March/April_2014 [1] https://wiki.openstack.org/wiki/Murano/PTL_Elections_Kilo_Liberty [2] http://lists.openstack.org/pipermail/openstack-dev/2014-March/031239.html Thank you. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. __ 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 -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com +7 (495) 640-4904, 0261 +7 (903) 156-0836 __ 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 Certainly not disputing/challenging this, but I'm slightly confused; isn't the proposal deadline April 4? You referenced it yourself in the link here: [1]. Or is there some special process unique to Murano? [1] https://wiki.openstack.org/wiki/PTL_Elections_March/April_2014 __ 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] Memory recommendation for running magnum with devstack
Team, Do we have a ballpark amount for the memory of the devstack machine to run magnum? I am running devstack as a VM with (4 VCPU/50G-Disk/8G-Mem) and running magnum on it as per[1]. I am observing the kube-Nodes goes often in SHUTOFF state. If I do 'nova reset-state', the instance goes into ERROR state with message indicating that it has run out of memory[2]. Do we have any recommendation on the size of the RAM for the deployment described in[1]? -- Regards, SURO [1] -https://github.com/stackforge/magnum/blob/master/doc/source/dev/dev-quickstart.rst [2] - internal error: process exited while connecting to monitor: Cannot set up guest memory 'pc.ram' __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder] Status of Huawei Volume CI
Hi Mike, Regarding the Huawei Volume CI: As I am dealing with the CI process of Huawei, please modify the contact person to liuxin...@huawei.commailto:liuxin...@huawei.com, so I won't miss important announcements from you regarding the CI. The CI of huawei 18000 ISCSI and huawei 18000 FC have posted results to lots of review, the most resently posts are: *https://review.openstack.org/#/c/165796/ Post time: 2015-3-19 0:14:56 *https://review.openstack.org/#/c/164697/ Post time: 2015-3-18 23:55:37 *https://review.openstack.org/164702/ Post time: 2015-3-18 23:55:37 *https://review.openstack.org/#/c/152401/ Post time: 3-18 23:08:45 So can this mean that the huawei 18000 ISCSI and huawei 18000 FC may probably be marked with a light green color as Reporting/WIP Reporting in Cinder upstream, not stable? Thanks and regards, Liu __ 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} Separating Ceph pools depending on storage type
Hello, I want to initiate a discussion about different backend storage types for Ceph. Now all types of drives (HDD, SAS, SSD) are treated the same way, so the performance can vary widely. It would be good to detect SSD drives and create separate Ceph pool for them. From the user perspective, it should be able to select pool when scheduling an instance (scenario for high-IOPS needed VM, like database). Regards, Kamil Rogon --- Intel Technology Poland sp. z o.o. KRS 101882 ul. Slowackiego 173 80-298 Gdansk smime.p7s Description: S/MIME cryptographic signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder] May you reconsider about huawei driver?
Hi Mike, I have seen the patch at https://review.openstack.org/#/c/165990/ saying that huawei driver will be removed because “the maintainer does not have a CI reporting to ensure their driver integration is successful”. But in fact we really have a CI months ago and it is really reporting to reviews, the most resently posts are: *https://review.openstack.org/#/c/165796/ Post time: 2015-3-19 0:14:56 *https://review.openstack.org/#/c/164697/ Post time: 2015-3-18 23:55:37 *https://review.openstack.org/164702/ Post time: 2015-3-18 23:55:37 *https://review.openstack.org/#/c/152401/ Post time: 3-18 23:08:45 And if you want, I will give you more proof of reviews. Thanks and regards, Liu __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder] I will add Dorado and T CI within one week if I can't revome Dorado and T driver
Hi Mike, * Maybe I have a misunderstandapp:ds:misunderstand of the warningapp:ds:warning you said that all drivers must have a CI. I have taken that as if the Dorado and T driver did not have a CI then the Dorado and T driver will be removed from the community individually. If I can't remove Dorado and T driver individually, will you please give me some time to add CI for these two drivers? I promise to add the CI for the following drivers within one week: HuaweiOceanStor Dorado ISCSI HuaweiOceanStor Dorado FC HuaweiOceanStor T Series ISCSI HuaweiOceanStor T Series FC And I promise these CI can post results to cinder reviews. Thanks and regards, Liu __ 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] Memory recommendation for running magnum with devstack
Hi Surojit, I think 8G of RAM and 80G of disk should be considered the minimum. The guide will create 3 m1.small VMs (each with 2G of RAM and 20G of disk), and 2 volumes (5G each). In your case, I am not sure why you get the memory error. Probably, you could walk-around it by creating a flavor with less computing resources, then use the new flavor to create the cluster: # create a new flavor with 1G of RAM and 10G of disk $ nova flavor-create m2.small 1234 1024 10 1 $ magnum baymodel-create --name testbaymodel --image-id fedora-21-atomic \ --keypair-id testkey \ --external-network-id $NIC_ID \ --dns-nameserver 8.8.8.8 --flavor-id m2.small \ --docker-volume-size 5 Thanks, Hongbin On Thu, Mar 19, 2015 at 11:06 PM, Surojit Pathak suro.p...@gmail.com wrote: Team, Do we have a ballpark amount for the memory of the devstack machine to run magnum? I am running devstack as a VM with (4 VCPU/50G-Disk/8G-Mem) and running magnum on it as per[1]. I am observing the kube-Nodes goes often in SHUTOFF state. If I do 'nova reset-state', the instance goes into ERROR state with message indicating that it has run out of memory[2]. Do we have any recommendation on the size of the RAM for the deployment described in[1]? -- Regards, SURO [1] -https://github.com/stackforge/magnum/blob/master/ doc/source/dev/dev-quickstart.rst [2] - internal error: process exited while connecting to monitor: Cannot set up guest memory 'pc.ram' __ 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] Neutron extenstions
There are precedents for this. For example, the attributes that currently exist for IPv6 advertisement are very similar: - added during the run of a stable Neutron API - properties added on a Neutron object (MTU and VLAN affect network, but IPv6 affects subnet - same principle though) - settable, but with defaults so they're optional - turn up in output when the subnet information is fetched With the one caveat (write your code to ignore properties you don't understand) this seems to address backward compatibility in both the IPv6 and the MTU/VLAN attribute changes - if you completely ignore the attribute behaviour is enough the way it used to be that your app won't break. Now, it may be that no-one noticed the ipv6 changes as they went through, but given the long debate about what the attributes should look like at the time they did get reasonable attention. Do we want to change the rules for future API changes? -- Ian. On 19 March 2015 at 10:07, Gary Kotton gkot...@vmware.com wrote: Hi, Until now all changes to the API’s have been made in separate extensions and not in the base. These should actually be on the provider networks extension. First this code is not supported by any of the plugins other than the ML2 (I am not sure if this break things – it certain broke the unit tests). Secondly these two changes do not have open source reference implementations (but that is digressing from the problem). I really think that we need to revert these and have the extensions done in the standard fasion. Thanks Gary From: Brandon Logan brandon.lo...@rackspace.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 6:20 PM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Neutron extenstions Isn't this argument as to whether those fields should be turned off/on, versus just always being on? Are there any guidelines as to what fields are allowed to be added in that base resource attr map? If ML2 needs these and other fields, should they just always be on? Thanks, Brandon -- *From:* Doug Wiegley doug...@parksidesoftware.com *Sent:* Thursday, March 19, 2015 11:01 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron] Neutron extenstions Hi Gary, First I’m seeing these, but I don’t see that they’re required on input, unless I’m mis-reading those reviews. Additional of new output fields to a json object, or adding optional inputs, is not generally considered to be backwards incompatible behavior in an API. Does OpenStack have a stricter standard on that? Thanks, doug On Mar 19, 2015, at 6:37 AM, Gary Kotton gkot...@vmware.com wrote: Hi, Changed the subject so that it may draw a little attention. There were 2 patches approved that kind of break the API (in my humble opinion): https://review.openstack.org/#/c/154921/ and https://review.openstack.org/#/c/158420/ In both of these two new fields were added to the base attributes – mtu and vlan_transparency Reverts for them are: https://review.openstack.org/165801 (mtu) and https://review.openstack.org/165776 (vlan transparency). In my opinion these should be added as separate extensions. Thanks Gary From: Gary Kotton gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 2:32 PM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] VLAN transparency support Hi, This patch has the same addition too - https://review.openstack.org/#/c/154921/. We should also revert that one. Thanks Gary From: Gary Kotton gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN transparency support Hi, It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others. I do not think that this is the correct way to go and we should do this as all other extensions have been maintained. I have posted a revert ( https://review.openstack.org/#/c/165776/) – please feel free to knack if it is invalid. Thanks Gary __ 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] [Fuel] development tools
+1 -- there is no point for commiting that review with external urls if those repos are to be created in stackforge. P. On 03/19/2015 03:02 PM, Evgeniy L wrote: Hi folks, I agree, lets create separate repo with its own cores and remove fuel_development from fuel-web. But in this case I'm not sure if we should merge the patch which has links to non-stackforge repositories, because location is going to be changed soon. Also it will be cool to publish it on pypi. Thanks, On Thu, Mar 19, 2015 at 4:21 PM, Sebastian Kalinowski skalinow...@mirantis.com mailto:skalinow...@mirantis.com wrote: As I wrote in the review already: I like the idea of merging those two tools and making a separate repository. After that we could make they more visible in our documentation and wiki so they could benefit from being used by broader audience. Same for vagrant configuration - if it's useful (and it is since newcomers are using them) we could at least move under Mirantis organization on Github. Best, Seabastian 2015-03-19 13:49 GMT+01:00 Przemyslaw Kaminski pkamin...@mirantis.com mailto:pkamin...@mirantis.com: Hello, Some time ago I wrote some small tools that make Fuel development easier and it was suggested to add info about them to the documentation -- here's the review link [1]. Evgenyi Li correctly pointed out that we already have something like fuel_development already in fuel-web. I think though that we shouldn't mix such stuff directly into fuel-web, I mean we recently migrated CLI to a separate repo to make fuel-web thinner. So a suggestion -- maybe make these tools more official and create stackforge repos for them? I think dev ecosystem could benefit by having some standard way of dealing with the ISO (for example we get questions from people how to apply new openstack.yaml config to the DB). At the same time we could get rid of fuel_development and merge that into the new repos (it has the useful 'revert' functionality that I didn't think of :)) P. [1] https://review.openstack.org/#/c/140355/9/docs/develop/env.rst __ 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 __ 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 __ 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] development tools
+1 for moving fuel_development into separate repo. On Thu, Mar 19, 2015 at 5:02 PM, Evgeniy L e...@mirantis.com wrote: Hi folks, I agree, lets create separate repo with its own cores and remove fuel_development from fuel-web. But in this case I'm not sure if we should merge the patch which has links to non-stackforge repositories, because location is going to be changed soon. Also it will be cool to publish it on pypi. Thanks, On Thu, Mar 19, 2015 at 4:21 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: As I wrote in the review already: I like the idea of merging those two tools and making a separate repository. After that we could make they more visible in our documentation and wiki so they could benefit from being used by broader audience. Same for vagrant configuration - if it's useful (and it is since newcomers are using them) we could at least move under Mirantis organization on Github. Best, Seabastian 2015-03-19 13:49 GMT+01:00 Przemyslaw Kaminski pkamin...@mirantis.com: Hello, Some time ago I wrote some small tools that make Fuel development easier and it was suggested to add info about them to the documentation -- here's the review link [1]. Evgenyi Li correctly pointed out that we already have something like fuel_development already in fuel-web. I think though that we shouldn't mix such stuff directly into fuel-web, I mean we recently migrated CLI to a separate repo to make fuel-web thinner. So a suggestion -- maybe make these tools more official and create stackforge repos for them? I think dev ecosystem could benefit by having some standard way of dealing with the ISO (for example we get questions from people how to apply new openstack.yaml config to the DB). At the same time we could get rid of fuel_development and merge that into the new repos (it has the useful 'revert' functionality that I didn't think of :)) P. [1] https://review.openstack.org/#/c/140355/9/docs/develop/env.rst __ 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] development tools
Hi folks, I agree, lets create separate repo with its own cores and remove fuel_development from fuel-web. But in this case I'm not sure if we should merge the patch which has links to non-stackforge repositories, because location is going to be changed soon. Also it will be cool to publish it on pypi. Thanks, On Thu, Mar 19, 2015 at 4:21 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: As I wrote in the review already: I like the idea of merging those two tools and making a separate repository. After that we could make they more visible in our documentation and wiki so they could benefit from being used by broader audience. Same for vagrant configuration - if it's useful (and it is since newcomers are using them) we could at least move under Mirantis organization on Github. Best, Seabastian 2015-03-19 13:49 GMT+01:00 Przemyslaw Kaminski pkamin...@mirantis.com: Hello, Some time ago I wrote some small tools that make Fuel development easier and it was suggested to add info about them to the documentation -- here's the review link [1]. Evgenyi Li correctly pointed out that we already have something like fuel_development already in fuel-web. I think though that we shouldn't mix such stuff directly into fuel-web, I mean we recently migrated CLI to a separate repo to make fuel-web thinner. So a suggestion -- maybe make these tools more official and create stackforge repos for them? I think dev ecosystem could benefit by having some standard way of dealing with the ISO (for example we get questions from people how to apply new openstack.yaml config to the DB). At the same time we could get rid of fuel_development and merge that into the new repos (it has the useful 'revert' functionality that I didn't think of :)) P. [1] https://review.openstack.org/#/c/140355/9/docs/develop/env.rst __ 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] [designate] Designate performance issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/19/2015 07:41 AM, stanzgy wrote: Hi all. I have setup kilo designate services with powerdns backend and mysql innodb storage in a single node. The services function well at first. However, after inserting 13k A records via API within 3 domains (5k, 5k, 3k for each), the service stops working. designate-api returns 500 and many RPCs timeout designate-central takes 100% cpu, seems trying hard updating domains but failed designate-mdns also takes 100% cpu, flooded with Including all tenants items in query results logs powerdns gets timeout errors during AXFR zones The server doesn't seem to turn any better after suffering in this state for hours. What I could do to recover the service is to cleanup databases and restart the service. My question is: 1. Is it not recommended to create too many records in a single domain? 2. Any suggestions to improve this situation? -- Best Regards, Zhang Gengyuan http://www.hp.com/ First off, for that initial burst of activity, I would disable debug level logging. How did you try and add them? Was it via a calling the API as fast as possible until it fell over? I would recommend rate limiting the initial import if it was. Do you have any logs from the services? Graham __ 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] development tools
As I wrote in the review already: I like the idea of merging those two tools and making a separate repository. After that we could make they more visible in our documentation and wiki so they could benefit from being used by broader audience. Same for vagrant configuration - if it's useful (and it is since newcomers are using them) we could at least move under Mirantis organization on Github. Best, Seabastian 2015-03-19 13:49 GMT+01:00 Przemyslaw Kaminski pkamin...@mirantis.com: Hello, Some time ago I wrote some small tools that make Fuel development easier and it was suggested to add info about them to the documentation -- here's the review link [1]. Evgenyi Li correctly pointed out that we already have something like fuel_development already in fuel-web. I think though that we shouldn't mix such stuff directly into fuel-web, I mean we recently migrated CLI to a separate repo to make fuel-web thinner. So a suggestion -- maybe make these tools more official and create stackforge repos for them? I think dev ecosystem could benefit by having some standard way of dealing with the ISO (for example we get questions from people how to apply new openstack.yaml config to the DB). At the same time we could get rid of fuel_development and merge that into the new repos (it has the useful 'revert' functionality that I didn't think of :)) P. [1] https://review.openstack.org/#/c/140355/9/docs/develop/env.rst __ 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] [designate] Designate performance issues
Hi Zhang, Thank you for reporting the bug. The number of records does not seem too high. At this point I do not have a suggestion to improve the situation, but I will investigate this. Could you file a bug report? Relevant log snippets would also be helpful. --vinod From: stanzgy stan@gmail.commailto:stan@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 2:39 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [designate] Designate performance issues Hi all. I have setup kilo designate services with powerdns backend and mysql innodb storage in a single node. The services function well at first. However, after inserting 13k A records via API within 3 domains (5k, 5k, 3k for each), the service stops working. designate-api returns 500 and many RPCs timeout designate-central takes 100% cpu, seems trying hard updating domains but failed designate-mdns also takes 100% cpu, flooded with Including all tenants items in query results logs powerdns gets timeout errors during AXFR zones The server doesn't seem to turn any better after suffering in this state for hours. What I could do to recover the service is to cleanup databases and restart the service. My question is: 1. Is it not recommended to create too many records in a single domain? 2. Any suggestions to improve this situation? -- Best Regards, Zhang Gengyuan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][FFE] secure boot support in iLO drivers
Corrected [1] is below (link for pxe_ilo patch review): [1] https://review.openstack.org/#/c/154808/ On Thu, Mar 19, 2015 at 10:24 PM, Devananda van der Veen devananda@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, This feature [0] enables secure boot mode for hardware which supports UEFI. Ironic added support for UEFI in Juno. This is an incremental improvement, allowing those users to benefit more from their hardware's security features. After this morning's final round of reviews to get features in, we agreed to defer the pxe_ilo driver changes, as those are the highest risk component of the secure boot blueprint, but grant a short extension for the other two drivers (iscsi_ilo and agent_ilo) which do not require PXE booting. The remaining changes are already either approved or very close to, and we're confident this can be landed in the next couple days without impact outside of those drivers. As such, I have blocked the pxe_ilo patch [1], retargeted the blueprint to RC1, and am granting an exception for those drivers. I'll re-review the status of this on Monday, March 23rd. [0] https://blueprints.launchpad.net/ironic/+spec/uefi-secure-boot [1] https://review.openstack.org/#/c/159322/ - -Devananda -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlUK/woACgkQhFvuBniJg6demgCgxiSlIAPPSqNwUK8gGo2qOpxF gsEAoM65a5bTlBlaPKOKfpcJsN67INnW =bdk6 -END 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 __ 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] [Ironic][FFE] secure boot support in iLO drivers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, This feature [0] enables secure boot mode for hardware which supports UEFI. Ironic added support for UEFI in Juno. This is an incremental improvement, allowing those users to benefit more from their hardware's security features. After this morning's final round of reviews to get features in, we agreed to defer the pxe_ilo driver changes, as those are the highest risk component of the secure boot blueprint, but grant a short extension for the other two drivers (iscsi_ilo and agent_ilo) which do not require PXE booting. The remaining changes are already either approved or very close to, and we're confident this can be landed in the next couple days without impact outside of those drivers. As such, I have blocked the pxe_ilo patch [1], retargeted the blueprint to RC1, and am granting an exception for those drivers. I'll re-review the status of this on Monday, March 23rd. [0] https://blueprints.launchpad.net/ironic/+spec/uefi-secure-boot [1] https://review.openstack.org/#/c/159322/ - -Devananda -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlUK/woACgkQhFvuBniJg6demgCgxiSlIAPPSqNwUK8gGo2qOpxF gsEAoM65a5bTlBlaPKOKfpcJsN67INnW =bdk6 -END 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] Let's stick to OpenStack global requirements
On Thu, Mar 19, 2015 at 3:16 AM, Roman Prykhodchenko m...@romcheg.me wrote: I'm not sure it's good idea. We should stay so close to upstream distro as we can. It should be very important reason to update package against it's upstream distro The issue is the following: OpenStack’s components are tested against those versions of dependencies, that are specified in their requirements. IIRC those requirements are set up by pip so CI nodes contain latest versions of python packages that match their specs. The question is whether it’s required to ship OpenStack services with packages from a distro or with packages, that are used for testing. Dmitry has raised a valid point: when the base distro already has a package that satisfies both Fuel and OpenStack global requirements, we should keep that package even if a more recent version is available from PyPi. I think this rule fits fine within the general frame of Roman's proposal: - if the base distro already has a package that satisfies OpenStack global requirements (or Fuel requirements), the distro package is used; - else, OSCI mirror should contain the maximum version of a requirement that matches its version specification. -DmitryB __ 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] Neutron extenstions
Hi, Until now all changes to the API’s have been made in separate extensions and not in the base. These should actually be on the provider networks extension. First this code is not supported by any of the plugins other than the ML2 (I am not sure if this break things – it certain broke the unit tests). Secondly these two changes do not have open source reference implementations (but that is digressing from the problem). I really think that we need to revert these and have the extensions done in the standard fasion. Thanks Gary From: Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 6:20 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Neutron extenstions Isn't this argument as to whether those fields should be turned off/on, versus just always being on? Are there any guidelines as to what fields are allowed to be added in that base resource attr map? If ML2 needs these and other fields, should they just always be on? Thanks, Brandon From: Doug Wiegley doug...@parksidesoftware.commailto:doug...@parksidesoftware.com Sent: Thursday, March 19, 2015 11:01 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Neutron extenstions Hi Gary, First I’m seeing these, but I don’t see that they’re required on input, unless I’m mis-reading those reviews. Additional of new output fields to a json object, or adding optional inputs, is not generally considered to be backwards incompatible behavior in an API. Does OpenStack have a stricter standard on that? Thanks, doug On Mar 19, 2015, at 6:37 AM, Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com wrote: Hi, Changed the subject so that it may draw a little attention. There were 2 patches approved that kind of break the API (in my humble opinion): https://review.openstack.org/#/c/154921/ and https://review.openstack.org/#/c/158420/ In both of these two new fields were added to the base attributes – mtu and vlan_transparency Reverts for them are: https://review.openstack.org/165801 (mtu) and https://review.openstack.org/165776 (vlan transparency). In my opinion these should be added as separate extensions. Thanks Gary From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 2:32 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] VLAN transparency support Hi, This patch has the same addition too - https://review.openstack.org/#/c/154921/. We should also revert that one. Thanks Gary From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN transparency support Hi, It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others. I do not think that this is the correct way to go and we should do this as all other extensions have been maintained. I have posted a revert (https://review.openstack.org/#/c/165776/) – please feel free to knack if it is invalid. Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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] Stable/icehouse: oslo.messaging RPCClient segmentation fault core dumped
Hello everyone,
I have dug into this problem and I realized that this piece of code is working
on a CentOS 6.6 running Openstack stable icehouse installed with RDO.
My guess is that there may be an issue either with the operating system or with
the devstack installation.
If you have any clue, please let me know.
Thanks best regards,
Romain Ziba.
De : ZIBA Romain
Envoyé : mercredi 18 mars 2015 13:07
À : openstack-dev@lists.openstack.org
Objet : Stable/icehouse: oslo.messaging RPCClient segmentation fault core dumped
Hello everyone,
I am having an issue using the RPCClient of the oslo.messaging package
delivered through the stable/icehouse release of devstack (v 1.4.1).
With this simple script:
import sys
from oslo.config import cfg
from oslo import messaging
from project.openstack.common import log
LOG = log.getLogger(__name__)
log_levels = (cfg.CONF.default_log_levels +
['stevedore=INFO', 'keystoneclient=INFO'])
cfg.set_defaults(log.log_opts, default_log_levels=log_levels)
argv = sys.argv
cfg.CONF(argv[1:], project='test_rpc_server')
log.setup('test_rpc_server')
transport_url = 'rabbit://guest:guest@localhost:5672/'
transport = messaging.get_transport(cfg.CONF, transport_url)
target = messaging.Target(topic='test_rpc', server='server1')
client = messaging.RPCClient(transport, target)
ctxt = {'some':'context'}
try:
res = client.call(ctxt, 'call_method_1')
except Exception as e:
LOG.debug(e)
print res
svcdev@svcdev-openstack: python rpc_client.py
2015-03-18 11:44:01.018 15967 INFO oslo.messaging._drivers.impl_rabbit [-]
Connecting to AMQP server on localhost:5672
2015-03-18 11:44:01.125 15967 INFO oslo.messaging._drivers.impl_rabbit [-]
Connected to AMQP server on localhost:5672
2015-03-18 11:44:01.134 15967 INFO oslo.messaging._drivers.impl_rabbit [-]
Connecting to AMQP server on localhost:5672
2015-03-18 11:44:01.169 15967 INFO oslo.messaging._drivers.impl_rabbit [-]
Connected to AMQP server on localhost:5672
Segmentation fault (core dumped)
The last Python method called is the following one (in librabbitmq package, v
1.0.3):
def basic_publish(self, body, exchange='', routing_key='',
mandatory=False, immediate=False, **properties):
if isinstance(body, tuple):
body, properties = body
elif isinstance(body, self.Message):
body, properties = body.body, body.properties
return self.connection._basic_publish(self.channel_id,
body, exchange, routing_key, properties,
mandatory or False, immediate or False)
The script crashes after trying to call _basic_publish.
For information, I've got the trusty's rabbitmq-server version (v 3.2.4-1).
Plus, replacing the call method by a cast method makes that a message is queued.
Could you please tell me if I'm doing something wrong? Is there a bug in the
c-library used by librabbitmq?
Thanks beforehand,
Romain Ziba.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][FFE] secure boot support in iLO drivers
woops! thanks... -Devananda On Thu, Mar 19, 2015 at 10:04 AM, Ramakrishnan G rameshg87.openst...@gmail.com wrote: Corrected [1] is below (link for pxe_ilo patch review): [1] https://review.openstack.org/#/c/154808/ On Thu, Mar 19, 2015 at 10:24 PM, Devananda van der Veen devananda@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, This feature [0] enables secure boot mode for hardware which supports UEFI. Ironic added support for UEFI in Juno. This is an incremental improvement, allowing those users to benefit more from their hardware's security features. After this morning's final round of reviews to get features in, we agreed to defer the pxe_ilo driver changes, as those are the highest risk component of the secure boot blueprint, but grant a short extension for the other two drivers (iscsi_ilo and agent_ilo) which do not require PXE booting. The remaining changes are already either approved or very close to, and we're confident this can be landed in the next couple days without impact outside of those drivers. As such, I have blocked the pxe_ilo patch [1], retargeted the blueprint to RC1, and am granting an exception for those drivers. I'll re-review the status of this on Monday, March 23rd. [0] https://blueprints.launchpad.net/ironic/+spec/uefi-secure-boot [1] https://review.openstack.org/#/c/159322/ - -Devananda -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlUK/woACgkQhFvuBniJg6demgCgxiSlIAPPSqNwUK8gGo2qOpxF gsEAoM65a5bTlBlaPKOKfpcJsN67INnW =bdk6 -END 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 __ 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] Let's stick to OpenStack global requirements
Maciej, Maintaining multiple versions of the same package concurrently and tracking their compatibility with the many different components of OpenStack and Fuel creates additional work on many different levels, from spec branch management to repo management to validation to container building and so on. Unified global requirements help avoid such work where it isn't necessary (and when you look close enough into each specific case you're likely to find that it's never really necessary). -DmitryB On Thu, Mar 19, 2015 at 4:04 AM, Maciej Kwiek mkw...@mirantis.com wrote: I guess it would depend on how many docker containers are running on master node and if we are able to pull off such stunt :). I am not familiar with the amount of work needed to do sth like that, so the proposition may be silly. Just let me know if it is. On Thu, Mar 19, 2015 at 11:51 AM, Dmitry Burmistrov dburmist...@mirantis.com wrote: Folks, Correct me if I am wrong, but isn't it what we have containers on master node for? On the master node itself conflicts won’t happen because the components are run in their containers. Do you propose to use _separate_ package repository for each docker container? (It means separate gerrit project for each package of each container, including openstack projects) On Thu, Mar 19, 2015 at 1:16 PM, Roman Prykhodchenko m...@romcheg.me wrote: Folks, I assume you meant: If a requirement that previously was only in Fuel Requirements is merged to Global Requirements, it should be removed from *Fuel* Requirements». Exactly. I'm not sure it's good idea. We should stay so close to upstream distro as we can. It should be very important reason to update package against it's upstream distro The issue is the following: OpenStack’s components are tested against those versions of dependencies, that are specified in their requirements. IIRC those requirements are set up by pip so CI nodes contain latest versions of python packages that match their specs. The question is whether it’s required to ship OpenStack services with packages from a distro or with packages, that are used for testing. Splitting of repositories doesn't help to solve python packages conflicts because master node uses a number of openstack components. On the master node itself conflicts won’t happen because the components are run in their containers. - romcheg 19 бер. 2015 о 10:47 Dmitry Burmistrov dburmist...@mirantis.com написав(ла): Roman, all - OSCI mirror should contain the maximum version of a requirement that matches its version specification. I'm not sure it's good idea. We should stay so close to upstream distro as we can. It should be very important reason to update package against it's upstream distro version. If we update some package, we should maintain it too. Tracking bugs, CVEs and so on. The more packages, the more efforts to support it. - Set up CI jobs to notify OSCI team if either Global Requirements or Fuel Requirements are changed. - Set up requirements proposal jobs that will automatically propose changes to all fuel projects once either of requirements lists was changed Need to be discussed and investigated. Sebastian, Dmitry, There are some plans (unfortunately I do not know details, so maybe someone from OSCI could tell more) to split those repositories Splitting of repositories doesn't help to solve python packages conflicts because master node uses a number of openstack components. Anyway it should be done for 7.0 milestone in order to separatre master-node distro from environment one. (e.g. if we going to move master-node to debian) On Thu, Mar 19, 2015 at 12:01 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: Roman, I like this proposal very much, thanks for the idea and for putting together a straightforward process. I assume you meant: If a requirement that previously was only in Fuel Requirements is merged to Global Requirements, it should be removed from *Fuel* Requirements. Sebastian, We have found ways to resolve the conflicts between clvm and docker, and between ruby versions 1.8 and 2.1, without introducing a separate package repo for Fuel master. I've updated the blueprint to make note of that: https://blueprints.launchpad.net/fuel/+spec/separate-repo-for-master-node On Wed, Mar 18, 2015 at 9:25 AM, Sebastian Kalinowski skalinow...@mirantis.com wrote: I assume that you considered a situation when we have a common repository with RPMs for Fuel master and for nodes. There are some plans (unfortunately I do not know details, so maybe someone from OSCI could tell more) to split those repositories. How this workflow will work with those separated repos? Will we still need it? Thanks! Sebastian 2015-03-18 11:04 GMT+01:00 Roman Prykhodchenko m...@romcheg.me: Hi folks,
Re: [openstack-dev] [Keystone][FFE] - Reseller Implementation
In addition, In the last keystone meeting in March 17 in the IRC channel http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2015-03-17.log we decided that Henry Nash (keystone core) will sponsor this feature as a FFE. Cheers, Raildo On Tue, Mar 17, 2015 at 5:36 PM Raildo Mascena rail...@gmail.com wrote: Hi Folks, We’ve discussed a lot in the last Summit about the Reseller use case. OpenStack needs to grow support for hierarchical ownership of objects.This enables the management of subsets of users and projects in a way that is much more comfortable for private clouds, besides giving to public cloud providers the option of reselling a piece of their cloud. More detailed information can be found in the spec for this change at: https://review.openstack.org/#/c/139824 The current code change for this is split into 8 patches (to make it easier to review). We currently have 7 patches in code review and we are finishing the last one. Here is the workflow of our patches: 1- Adding a field to enable the possibility to have a project with the domain feature: https://review.openstack.org/#/c/157427/ 2- Change some constraints and create some options to list projects (for is_domain flag, for parent_id): https://review.openstack.org/#/c/159944/ https://review.openstack.org/#/c/158398/ https://review.openstack.org/#/c/161378/ https://review.openstack.org/#/c/158372/ 3- Reflect domain operations to project table, mapping domains to projects that have the is_domain attribute set to True. In addition, it changes the read operations to use only the project table. Then, we will drop the Domain Table. https://review.openstack.org/#/c/143763/ https://review.openstack.org/#/c/161854/ (Only patch with work in progress) 4- Finally, the inherited role will not be applied to a subdomain and its sub hierarchy. https://review.openstack.org/#/c/164180/ Since we have the implementation almost completed, waiting for code review, I am requesting an FFE to enable the implementation of this last patch and work to have this implementation merged in Kilo. Raildo __ 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] Neutron extenstions
On Thu, Mar 19, 2015 at 11:24:16AM PDT, Ian Wells wrote: There are precedents for this. For example, the attributes that currently exist for IPv6 advertisement are very similar: I'll also note that the API changes landed in Icehouse, but the implementation missed the Icehouse deadline and was landed in Juno, so for a time the attributes were hidden from users. https://review.openstack.org/#/c/85869/ -- 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
Re: [openstack-dev] [horizon][heat]Vote for Openstack L summit topic The Heat Orchestration Template Builder: A demonstration
Nikunj, aren't you going to present this talk together with Drago Rosson since he's the sole developer of Hotbuilder? That would be fair. Anyways, thanks for advertising Hotbuilder and Merlin :), both me and Drago have been spending inexcusably too little time spreading the word in the mailing list as of late, so there was definitely a lack of news about Hotbuilder and Merlin. I'll try to shed some light onto our recent achievements. As you may already know, currently the Mistral Workbook builder is being developed as part of Merlin project. Both Mistral workbook builder and Hotbuilder use the Barricade.js library, which provides data layer abstraction for them, and is being developed also by Drago with some episodic contributions from my side. The most important difference between Hotbuilder and Mistral Workbook builder is (besides the Heat templates vs. Mistral Workbook domain) is the rest part of the technologies stack - I have employed Angular.js framework for rendering the data model expressed as Barricade.js object, while Drago used Knockout.js framework to achieve the same goals for Hotbuilder. IMHO the Angular.js usage makes the code of Workbook builder more readable :). Speaking of Hotbuilder, it's now completely opensourced at https://github.com/rackerlabs/hotbuilder and https://github.com/dragorosson/hotbuilder_horizon (the second repo is a compatibility code between the hotbuilder and horizon). My colleague Paul Karikh fork-merged 2 repos into https://github.com/pkarikh/hotbuilder_horizon_deploy, since we had some difficulties making the original code run with Horizon (so it's just the same code from Drago's repos with a couple of changes to make it work for us). AFAIK, Drago is already working on the fixes. Moreover, together with Drago we had submitted a talk about Merlin and Barricade, but since we hadn't spent enough time promoting it, it's still unknown whether it's accepted or not :(. Yet I hope we'll present a short demonstration + overview of Merlin + Barricade technologies on one of the Horizon design sessions. On Mon, Feb 23, 2015 at 4:05 PM, Aggarwal, Nikunj nikunj.aggar...@hp.com wrote: I am also looking forward to present it. Please support this by giving your vote J Regards, Nikunj *From:* Angus Salkeld [mailto:asalk...@mirantis.com] *Sent:* Monday, February 23, 2015 5:53 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [horizon][heat]Vote for Openstack L summit topic The Heat Orchestration Template Builder: A demonstration On Mon, Feb 23, 2015 at 9:18 PM, Aggarwal, Nikunj nikunj.aggar...@hp.com wrote: Hi Angus, I am working Timur and Drago on HOT builder. I am using this - https://github.com/rackerlabs/hotbuilder as the base and made some improvements over the existing code and wish to give a demonstration on how easy it is to create a HOT template from Horizon. That's awesome, looking forward to see it! -Angus Regards, Nikunj *From:* Angus Salkeld [mailto:asalk...@mirantis.com] *Sent:* Monday, February 23, 2015 4:52 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [horizon][heat]Vote for Openstack L summit topic The Heat Orchestration Template Builder: A demonstration On Sat, Feb 21, 2015 at 4:21 AM, Aggarwal, Nikunj nikunj.aggar...@hp.com wrote: Hi, I have submitted presentations for Openstack L summit : The Heat Orchestration Template Builder: A demonstration https://www.openstack.org/vote-vancouver/Presentation/the-heat-orchestration-template-builder-a-demonstration Hi Nice to see work on a HOT builder progressing, but.. are you planning on integrating this with the other HOT builder efforts? Is the code public (link)? This is more of a framework to make these easier to build: https://github.com/stackforge/merlin https://wiki.openstack.org/wiki/Merlin Timur (who works on Merlin) is working with Rackers to build this upstream - I am not sure on the progress. https://github.com/rackerlabs/hotbuilder https://github.com/rackerlabs/foundry It would be nice if we could all work together (I am hoping you are already)? Hopefully some of the others that are working on this can chip in and say where they are. -Angus Please cast your vote if you feel it is worth for presentation. Thanks Regards, Nikunj __ 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] [infra][horizon] Need help at debugging requirements issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/19/2015 10:16 AM, Matthias Runge wrote: Hello, I was trying to raise the cap for Django in[1]. It looks quite simple, current requirements is Django=1.4.2,1.7 and I simply removed the upper boundary: Django=1.4.2 with the result, django-nose is not installed any more. (That's a rest dependency for horizon), it's listed in the same global-requirements file: django-nose (no version requirement). Sadly, I can not figure out, why that happens and how to fix that. In local tests, this just works. Any hints please? Thanks, Matthias [1] https://review.openstack.org/#/c/155353/ Hi, it all comes to the fact that DEVSTACK_GATE_INSTALL_TESTONLY=1 is not specified in the requirements integration job. I think you need to set it at [1]. In that case, your test requirements will also be installed during the job. [1]: https://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/requirements.yaml#n21 /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVCuKzAAoJEC5aWaUY1u57zIQIALtX0KdW0/gjANEdAkOg3J2x Z6TimXtlxA1+l8oNt9uVmOI02cFbd0lEdXjnvb56n0R80eB77mkbg6sDJs8z0910 8tikATYgtUjeGpHLA63bnkzV0ECa3bjUGQ5c4QgBJ4AZ4e93ZrW+rO8myK8WY+rL CXgg8tPaXL1QAp9hYDpIMjE1BEUdwSYhTwBMSirlOCyGHzBHf8RHXKaaQ2epEfkM CqzO/2TZI83BiAUmKY6Y+vi4ICJU9oPFy06M/hK29YzSmzAROUIFiCyKBxISVjnN 2ovTc8SO2HgWWX3WpZQHn2E/LW4GDxcUNliQ5XJdtiSZNB7AY0dXB3XrVUcfXfI= =MWlj -END 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] [TripleO] QuintupleO Overview
On 03/17/2015 01:59 AM, Smigiel, Dariusz wrote: On 17 March 2015 at 09:30, Ben Nemec openst...@nemebean.com wrote: So I've successfully done a deployment to a QuintupleO environment. \o/ \o/ Great news! Congrats! @Ben, are you planning to keep it up-to-date or create repo with README? I would also like to be involved in TripleO wasn't confusing enough, let's add another layer [1] ;) so maybe this is good start. [1] http://blog.nemebean.com/content/quintupleo-status-update Long-term I don't intend for this to live on my blog. I know of at least a couple environments where we'd like to start using this, so my hope is that when I set those up I can clean up some of the hard-coded bits and document the process better. I also re-recorded my demo video with functional overcloud images, so I should be able to post that later today. Once I have something more documentation-y I'll send another update to the list. -Ben __ 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] VLAN transparency support
With regards to the MTU can you please point me to where we validate that the MTU defined by the tenant is actually = the supported MTU on the network. I did not see this in the code (maybe I missed something). From: Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 8:44 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] VLAN transparency support Per the other discussion on attributes, I believe the change walks in historical footsteps and it's a matter of project policy choice. That aside, you raised a couple of other issues on IRC: - backward compatibility with plugins that haven't adapted their API - this is addressed in the spec, which should have been implemented in the patches (otherwise I will downvote the patch myself) - behaviour should be as before with the additional feature that you can now tell more about what the plugin is thinking - whether they should be core or an extension - this is a more personal opinion, but on the grounds that all networks are either trunks or not, and all networks have MTUs, I think they do want to be core. I would like to see plugin developers strongly encouraged to consider what they can do on both elements, whereas an extension tends to sideline functionality from view so that plugin writers don't even know it's there for consideration. Aside from that, I'd like to emphasise the value of these patches, so hopefully we can find a way to get them in in some form in this cycle. I admit I'm interested in them because they make it easier to do NFV. But they also help normal cloud users and operators, who otherwise have to do some really strange things [1]. I think it's maybe a little unfair to post reversion patches before discussion, particularly when the patch works, passes tests and implements an approved spec correctly. -- Ian. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1138958https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1138958d=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=NzYY0bOpToH9ZNwzqI_SpQHiPFRXD_nfb1bM3qAw7Css=FlF57GYJqeWgx5ivxnK5kfWlyTIc1ZFbdlXoi2cfdhwe= (admittedly first link I found, but there's no shortage of them) On 19 March 2015 at 05:32, Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com wrote: Hi, This patch has the same addition too - https://review.openstack.org/#/c/154921/. We should also revert that one. Thanks Gary From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN transparency support Hi, It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others. I do not think that this is the correct way to go and we should do this as all other extensions have been maintained. I have posted a revert (https://review.openstack.org/#/c/165776/) - please feel free to knack if it is invalid. Thanks Gary __ 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] [oslo.config][kolla] modular backends for oslo.cfg
And don't forget about: https://review.openstack.org/#/c/130047/ Sounds pretty similar (the proxy could proxy to anything, etc.d, zookeeper, a email system, a snail, a web-service, whatever...). -Josh Davanum Srinivas wrote: Chmouel, Nice! Ben added a topic Alternative file formats for oslo.config for Liberty[1]. this would be great if we can talk about alternative backends as well :) -- dims [1] https://etherpad.openstack.org/p/liberty-oslo-summit-planning On Thu, Mar 19, 2015 at 8:31 AM, Chmouel Boudjnahchmo...@chmouel.com wrote: Hello, While on a long oversea flight with Sebastien Han we were talking how he had implemented ceph-docker with central configuration over etcd. We quickly came up to the conclusion that if we wanted to have that in Kolla it would be neat if it was done straight from oslo.config so that would quickly override the default keys in a central point. There is multiple advantage to use that method not just for containers but as well to avoid issues when orchestrating an openstack deployment. I have heard arguments that this should be the job of an ansible/puppet/chef tool and while I completely agree I just don't think it has to write to files the tool would just write to the etcd database. I have quickly came up with a quick and dirty POC on oslo.cfg here : https://github.com/chmouel/oslo.config/commit/01ee54dd5219b1434eaac422055b58e77694d89f and the demo : https://gist.github.com/chmouel/05fb715f96344161268c What others thinks about it ? I believe if we wanted to do that we would have to add a stevesdor based modular backend support directly to oslo.cfg first and have an etcd backend implemented. Chmouel PS: I am using etcd here cause it's easy and fancy but this could be any backends like a DB/NoSQL/Swift or whatever if we wanted __ 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] VLAN transparency support
Per the other discussion on attributes, I believe the change walks in historical footsteps and it's a matter of project policy choice. That aside, you raised a couple of other issues on IRC: - backward compatibility with plugins that haven't adapted their API - this is addressed in the spec, which should have been implemented in the patches (otherwise I will downvote the patch myself) - behaviour should be as before with the additional feature that you can now tell more about what the plugin is thinking - whether they should be core or an extension - this is a more personal opinion, but on the grounds that all networks are either trunks or not, and all networks have MTUs, I think they do want to be core. I would like to see plugin developers strongly encouraged to consider what they can do on both elements, whereas an extension tends to sideline functionality from view so that plugin writers don't even know it's there for consideration. Aside from that, I'd like to emphasise the value of these patches, so hopefully we can find a way to get them in in some form in this cycle. I admit I'm interested in them because they make it easier to do NFV. But they also help normal cloud users and operators, who otherwise have to do some really strange things [1]. I think it's maybe a little unfair to post reversion patches before discussion, particularly when the patch works, passes tests and implements an approved spec correctly. -- Ian. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1138958 (admittedly first link I found, but there's no shortage of them) On 19 March 2015 at 05:32, Gary Kotton gkot...@vmware.com wrote: Hi, This patch has the same addition too - https://review.openstack.org/#/c/154921/. We should also revert that one. Thanks Gary From: Gary Kotton gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN transparency support Hi, It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others. I do not think that this is the correct way to go and we should do this as all other extensions have been maintained. I have posted a revert ( https://review.openstack.org/#/c/165776/) – please feel free to knack if it is invalid. Thanks Gary __ 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] Neutron extenstions
Hi, Just the fact that we did this does not make it right. But I guess that we are starting to bend the rules. I think that we really need to be far more diligent about this kind of stuff. Having said that we decided the following on IRC: 1. Mtu will be left in the core (all plugins should be aware of this and treat it if necessary) 2. Vlan-transparency will be moved to an extension. Pritesh is working on this. Thanks Gary On 3/19/15, 8:30 PM, Sean M. Collins s...@coreitpro.com wrote: On Thu, Mar 19, 2015 at 11:24:16AM PDT, Ian Wells wrote: There are precedents for this. For example, the attributes that currently exist for IPv6 advertisement are very similar: I'll also note that the API changes landed in Icehouse, but the implementation missed the Icehouse deadline and was landed in Juno, so for a time the attributes were hidden from users. https://review.openstack.org/#/c/85869/ -- 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] [Glance] [all] glance_store release 0.4.0
The glance_store release management team is pleased to announce: Release of glance_store version 0.4.0 Please find the details related to the release at: https://launchpad.net/glance-store/+milestone/v0.4.0 Please report the issues through launchpad: https://bugs.launchpad.net/glance-store Thanks, -Nikhil __ 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] development tools
we already have a package with the name fuel-utils please see [1]. I -1'd the CR over it. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-March/059206.html On Thu, Mar 19, 2015 at 7:11 AM, Alexander Kislitsky akislit...@mirantis.com wrote: +1 for moving fuel_development into separate repo. On Thu, Mar 19, 2015 at 5:02 PM, Evgeniy L e...@mirantis.com wrote: Hi folks, I agree, lets create separate repo with its own cores and remove fuel_development from fuel-web. But in this case I'm not sure if we should merge the patch which has links to non-stackforge repositories, because location is going to be changed soon. Also it will be cool to publish it on pypi. Thanks, On Thu, Mar 19, 2015 at 4:21 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: As I wrote in the review already: I like the idea of merging those two tools and making a separate repository. After that we could make they more visible in our documentation and wiki so they could benefit from being used by broader audience. Same for vagrant configuration - if it's useful (and it is since newcomers are using them) we could at least move under Mirantis organization on Github. Best, Seabastian 2015-03-19 13:49 GMT+01:00 Przemyslaw Kaminski pkamin...@mirantis.com: Hello, Some time ago I wrote some small tools that make Fuel development easier and it was suggested to add info about them to the documentation -- here's the review link [1]. Evgenyi Li correctly pointed out that we already have something like fuel_development already in fuel-web. I think though that we shouldn't mix such stuff directly into fuel-web, I mean we recently migrated CLI to a separate repo to make fuel-web thinner. So a suggestion -- maybe make these tools more official and create stackforge repos for them? I think dev ecosystem could benefit by having some standard way of dealing with the ISO (for example we get questions from people how to apply new openstack.yaml config to the DB). At the same time we could get rid of fuel_development and merge that into the new repos (it has the useful 'revert' functionality that I didn't think of :)) P. [1] https://review.openstack.org/#/c/140355/9/docs/develop/env.rst __ 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 -- Andrew Mirantis Fuel community ambassador Ceph community __ 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] [Glance] [all] python-glanceclient release 0.17.0
The python-glanceclient release management team is pleased to announce: Release of python-glanceclient version 0.17.0 Please find the details related to the release at: https://launchpad.net/python-glanceclient/+milestone/v0.17.0 Please report the issues through launchpad: https://bugs.launchpad.net/python-glanceclient Thanks, -Nikhil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Whether microversion implementation only need to be applied to first layer API?
During http://lists.openstack.org/pipermail/openstack-dev/2015-March/059000.html, we had some discussions on whether we need version specific code remaining even we suggest user can use API version directly in API, [1][2] aiming to remove that And if we should keep following stuff , then [3][4] might be thought because of some potential issue can someone give some suggestions ? thanks [1]https://review.openstack.org/#/c/164229/ [2]https://review.openstack.org/#/c/164234/ [3]https://review.openstack.org/#/c/144998/ [4]https://review.openstack.org/#/c/145240/ Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][lbaas] canceling meeting
Hi lbaas'ers, Now that lbaasv2 has shipped, the need for a regular weekly meeting is greatly reduced. I propose that we cancel the regular meeting, and discuss neutron-y things during the neutron on-demand agenda, and octavia things in the already existing octavia meetings. Any objections/alternatives? Thanks, doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [all][qa][gabbi][rally][tempest] Extend rally verfiy to unify work with Gabbi, Tempest and all in-tree functional tests
I have an alternative solution for `rally verify project start` command.
What do you think about similar management stuff for verifiers as we have
for deployments?
It requires several changes:
- `rally verifiers` command: Implementation of new command, which will
manage(install, reinstall, remove, configure) verifiers(tempest,
project-specific functional tests, gabbi and etc), will allow users to have
several tempest verifiers with different configurations or branches and
easily switch between them.
- `rally verify` command: The original verification command will check
selected verifier and contain only verifier-specific sub-commands.
- db changes: we will need to store information about verifiers
On Thu, Mar 12, 2015 at 2:33 AM, Boris Pavlovic bo...@pavlovic.me wrote:
Alex,
* rally plugin should be a part of project (for example, located in
functional tests directory)
There are 2 issues with such solution:
1) If rally didn't load plugin, command rally verify project won't
exist
2) Putting some strange Rally plugin to source of other projects will be
quite complicated task.
I believe we should have at least POC before even asking for such
stuff.
* use {project url} instead of {project name} in rally verify command,
example:
I agree here with Andrey, it is bad UX. Forcing people to write every time
URLs is terrible.
They will build own tools on top of such solution.
What about rally verify nova start --url where --url is optional
argument?
If --url is not specified default url is used.
Best regards,
Boris Pavlovic
On Wed, Mar 11, 2015 at 7:14 PM, Andrey Kurilin akuri...@mirantis.com
wrote:
$ rally verify https://github.com/openstack/nova start
As one of end-users of Rally, I dislike such construction, because I
don't want to remember links to repos, they are too long for me:)
On Wed, Mar 11, 2015 at 12:49 PM, Aleksandr Maretskiy
amarets...@mirantis.com wrote:
The idea is great, but IMHO we can move all project-specific code out of
rally, so:
* rally plugin should be a part of project (for example, located in
functional tests directory)
* use {project url} instead of {project name} in rally verify command,
example:
$ rally verify https://github.com/openstack/nova start
On Tue, Mar 10, 2015 at 6:01 PM, Timur Nurlygayanov
tnurlygaya...@mirantis.com wrote:
Hi,
I like this idea, we use Rally for OpenStack clouds verification at
scale and it is the real issue - how to run all functional tests from each
project with the one script. If Rally will do this, I will use Rally to run
these tests.
Thank you!
On Mon, Mar 9, 2015 at 6:04 PM, Chris Dent chd...@redhat.com wrote:
On Mon, 9 Mar 2015, Davanum Srinivas wrote:
2. Is there a test project with Gabbi based tests that you know of?
In addition to the ceilometer tests that Boris pointed out gnocchi
is using it as well:
https://github.com/stackforge/gnocchi/tree/master/gnocchi/
tests/gabbi
3. What changes if any are needed in Gabbi to make this happen?
I was unable to tell from the original what this is and how gabbi
is involved but the above link ought to be able to show you how
gabbi can be used. There's also the docs (which could do with some
improvement, so suggestions or pull requests welcome):
http://gabbi.readthedocs.org/en/latest/
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
__
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
--
Timur,
Senior QA Engineer
OpenStack Projects
Mirantis Inc
__
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
--
Best regards,
Andrey Kurilin.
__
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] Neutron extenstions
On 19 March 2015 at 11:44, Gary Kotton gkot...@vmware.com wrote: Hi, Just the fact that we did this does not make it right. But I guess that we are starting to bend the rules. I think that we really need to be far more diligent about this kind of stuff. Having said that we decided the following on IRC: 1. Mtu will be left in the core (all plugins should be aware of this and treat it if necessary) 2. Vlan-transparency will be moved to an extension. Pritesh is working on this. The spec started out as an extension, and in its public review people requested that it not be an extension and that it should instead be core. I accept that we can change our minds, but I believe there should be a good reason for doing so. You haven't given that reason here and you haven't even said who the 'we' is that decided this. Also, as the spec author, I had a conversation with you all but there was no decision at the end of it (I presume that came afterward) and I feel that I have a reasonable right to be involved. Could you at least summarise your reasoning here? I admit that I prefer this to be in core, but I'm not terribly choosy and that's not why I'm asking. I'm more concerned that this is changing our mind at literally the last moment, and in turn wasting a developer's time, when there was a perfectly good process to debate this before coding was begun, and again when the code was up for review, both of which apparently failed. I'd like to understand how we avoid getting here again in the future. I'd also like to be certain we are not simply reversing a choice on a whim. -- Ian. __ 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] Neutron extenstions
?Isn't this argument as to whether those fields should be turned off/on, versus just always being on? Are there any guidelines as to what fields are allowed to be added in that base resource attr map? If ML2 needs these and other fields, should they just always be on? Thanks, Brandon From: Doug Wiegley doug...@parksidesoftware.com Sent: Thursday, March 19, 2015 11:01 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Neutron extenstions Hi Gary, First I'm seeing these, but I don't see that they're required on input, unless I'm mis-reading those reviews. Additional of new output fields to a json object, or adding optional inputs, is not generally considered to be backwards incompatible behavior in an API. Does OpenStack have a stricter standard on that? Thanks, doug On Mar 19, 2015, at 6:37 AM, Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com wrote: Hi, Changed the subject so that it may draw a little attention. There were 2 patches approved that kind of break the API (in my humble opinion): https://review.openstack.org/#/c/154921/ and https://review.openstack.org/#/c/158420/ In both of these two new fields were added to the base attributes - mtu and vlan_transparency Reverts for them are: https://review.openstack.org/165801 (mtu) and https://review.openstack.org/165776 (vlan transparency). In my opinion these should be added as separate extensions. Thanks Gary From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 2:32 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] VLAN transparency support Hi, This patch has the same addition too - https://review.openstack.org/#/c/154921/. We should also revert that one. Thanks Gary From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN transparency support Hi, It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others. I do not think that this is the correct way to go and we should do this as all other extensions have been maintained. I have posted a revert (https://review.openstack.org/#/c/165776/) - please feel free to knack if it is invalid. Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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] Neutron extenstions
Hi Gary, First I’m seeing these, but I don’t see that they’re required on input, unless I’m mis-reading those reviews. Additional of new output fields to a json object, or adding optional inputs, is not generally considered to be backwards incompatible behavior in an API. Does OpenStack have a stricter standard on that? Thanks, doug On Mar 19, 2015, at 6:37 AM, Gary Kotton gkot...@vmware.com wrote: Hi, Changed the subject so that it may draw a little attention. There were 2 patches approved that kind of break the API (in my humble opinion): https://review.openstack.org/#/c/154921 https://review.openstack.org/#/c/154921/ and https://review.openstack.org/#/c/158420 https://review.openstack.org/#/c/158420/ In both of these two new fields were added to the base attributes – mtu and vlan_transparency Reverts for them are: https://review.openstack.org/165801 https://review.openstack.org/165801 (mtu) and https://review.openstack.org/165776 https://review.openstack.org/165776 (vlan transparency). In my opinion these should be added as separate extensions. Thanks Gary From: Gary Kotton gkot...@vmware.com mailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 2:32 PM To: OpenStack List openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] VLAN transparency support Hi, This patch has the same addition too - https://review.openstack.org/#/c/154921 https://review.openstack.org/#/c/154921/. We should also revert that one. Thanks Gary From: Gary Kotton gkot...@vmware.com mailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN transparency support Hi, It appears that https://review.openstack.org/#/c/158420 https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others. I do not think that this is the correct way to go and we should do this as all other extensions have been maintained. I have posted a revert (https://review.openstack.org/#/c/165776 https://review.openstack.org/#/c/165776/) – please feel free to knack if it is invalid. Thanks Gary __ 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] [oslo.config][kolla] modular backends for oslo.cfg
Chmouel, Nice! Ben added a topic Alternative file formats for oslo.config for Liberty[1]. this would be great if we can talk about alternative backends as well :) -- dims [1] https://etherpad.openstack.org/p/liberty-oslo-summit-planning On Thu, Mar 19, 2015 at 8:31 AM, Chmouel Boudjnah chmo...@chmouel.com wrote: Hello, While on a long oversea flight with Sebastien Han we were talking how he had implemented ceph-docker with central configuration over etcd. We quickly came up to the conclusion that if we wanted to have that in Kolla it would be neat if it was done straight from oslo.config so that would quickly override the default keys in a central point. There is multiple advantage to use that method not just for containers but as well to avoid issues when orchestrating an openstack deployment. I have heard arguments that this should be the job of an ansible/puppet/chef tool and while I completely agree I just don't think it has to write to files the tool would just write to the etcd database. I have quickly came up with a quick and dirty POC on oslo.cfg here : https://github.com/chmouel/oslo.config/commit/01ee54dd5219b1434eaac422055b58e77694d89f and the demo : https://gist.github.com/chmouel/05fb715f96344161268c What others thinks about it ? I believe if we wanted to do that we would have to add a stevesdor based modular backend support directly to oslo.cfg first and have an etcd backend implemented. Chmouel PS: I am using etcd here cause it's easy and fancy but this could be any backends like a DB/NoSQL/Swift or whatever if we wanted __ 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] [Neutron] Neutron extenstions
On Thu, Mar 19, 2015 at 05:37:59AM PDT, Gary Kotton wrote: In my opinion these should be added as separate extensions. The spec that was approved for these patches does list the new attribute as being added to the Network object. http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html#rest-api-impact -- 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] [documentation]OpenStack API Reference for VPNaaS...
Hi, I created and am trying to work on https://bugs.launchpad.net/openstack-api-site/+bug/1433561. Is there someone who can advise me on how to create the WADL file for VPNaaS? I see the LBaaS one and can manually try to convert the old VPNaaS API documentation to a similar format, using a text editor, but before I go to those lengths, I'm wondering if there is a better way (tools?). In addition to the raw conversion of the content, there is namespace info and the like that I don't know how to handle. Any advice would be greatly appreciated, especially if it makes it less painful! PCM (Paul Michali) IRC pc_m (irc.freenode.com) Twitter... @pmichali __ 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] All Cinder Volume Drivers Must Have A Third Party CI by March 19, 2014
On Wed, Mar 18, 2015 at 11:38 PM, Bharat Kumar bharat.kobag...@redhat.com wrote: Regarding the GlusterFS CI: As I am dealing with end to end CI process of GlusterFS, please modify the contact person to bharat.kobag...@redhat.com. Because of this I may miss important announcements from you regarding the CI. Done. -- 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
