Re: [openstack-dev] [tc] Request to adopt security as a project team
Jeremy Stanley wrote: On 2015-04-02 15:56:31 + (+), Clark, Robert Graham wrote: Please consider this request to recognize the security team as an OpenStack project team. This is a milestone for the OpenStack Security Group and follows from our merging with the VMT. [...] With my VMT hat donned, I second this request! For the record, this means the VMT would move from being a subteam of Release Cycle Management to being a subteam of the Security Team. This makes much more sense :) -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital 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] [Ironic] [RFC/FFE] Finishing state machine work for Kilo
Hi all! Today I got an internal email, stating that new ironicclient brakes ironic-discoverd. Indeed, after rebase to the latest ironicclient git master, discoverd started receiving AVAILABLE state instead of None for newly enrolled nodes. It's not a valid state for introspection, valid are MANAGEABLE (discoverd stand-alone usage), INSPECTING (discoverd via Ironic driver) and None (Juno + discoverd stand-alone). Looks like despite introducing microversions we did manage to break 3rdparty apps relying on states... Also we're in a bit weird situation where nodes appear ready for scheduling, despite us having a special state for managing nodes _before_ being ready for scheduling. I find the situation pretty confusing, and I'd like your comments on the following proposal to be implemented before RC1: 1. add new micro-version 1.7. nodes created by API with this version will appear in state MANAGEABLE; 2. make a client release with current API version set to 1.6 (thus excluding change #1 from users of this version); 3. set current API version for ironicclient to 1.7 and release ironicclient version 2.0.0 to designate behavior changes; 4. document the whole thingy properly #1 should be a small change, but it definitely requires FFE. Thoughts? Dmitry __ 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] [Manila] Nominate Clinton Knight for core team
+1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [stable] freeze exception
Hello Folks, I'd like to request a freeze exception for the following changeset: https://review.openstack.org/169844 I believe that's an unharmful change, I apologize for getting it under review so late :) Ivar. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] OpenStack nova resize command
Hi,I have a question regarding the nova resize command. While resizing a VM in OpenStack, does the VM gets paused internally and then it is resized or the VM is resized at runtime without any downtime and the VM going down. Thanks and RegardsAbhishek Talwar =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you __ 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] The Evolution of core developer to maintainer?
Joe Gordon wrote: On Thu, Apr 2, 2015 at 3:14 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Joe Gordon wrote: I cannot speak for all projects, but at least in Nova you have to be a nova-core to be part of nova-drivers. And would you describe that as a good thing ? If John Garbutt is so deep into release liaison work that he can't sustain a review rate suitable to remain a core reviewer, would you have him removed from the maintainers group ? If someone steps up and works full-time on triaging bugs in Nova (and can't commit to do enough reviews as a result), would you exclude that person from your maintainers group ? I want to empower that person and recognize them in some semi formal capacity and make sure they have all the correct permissions. I do not want a single flat 'maintainers' group, I think we need a hierarchical notion of maintainers, where different people can end up with very different responsibilities (and ACLs -- but that is a implementation detail). OK, so I probably misread your proposal[1]. My understanding was you wanted a single flat maintainers group that would purely replace core reviewers, keep the same rights and just add duties to the already-existing reviewing duties. [1] https://review.openstack.org/#/c/163660/ Since I thought project leadership needs to be expressed in a much more diverse and inclusive way (and explicitly not tied to +2 rights), I opposed such simple renaming. From what you're saying now your objective is the same as mine. I'm not sure the maintainers group needs to be purely hierarchical (I think I'd prefer it to be a set of duties with no hierarchy between them), but I agree that: - today core reviewers are the only visible project duty, and we need to expose and reward all the others, as separate attributes - we could use a blanket term (maintainers ?) to describe the people holding one or more of those attributes. OpenStack governance mandates that core developers are ultimately the PTL's choice. Since the PTL is regularly elected by all contributors, that prevents aristocracy. Can you site your source for this? Because the earliest reference to 'Core Developer' (what you are calling core reviewer -- even though that is not the original name) that I could find says nothing about it ultimately being the PTLs choice. PTLs have (and always had) ultimate say over their project matters. That includes how to select core reviewers (or how reviews should be performed). A lot of projects let their PTL directly determine who should (and should no longer) be on the core list. https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess Now it's true that very early on, a lot of PTLs adopted a more open process to help in that selection. That doesn't mean they can't bypass the process. Personally I think that the apparently open process for core selection just resulted in reinforcing the aristocracy. This is why I encourage PTLs to own the content of core reviewing teams more directly. However in some projects, core reviewers have to be approved by existing core reviewers. That is an aristocracy. In those projects, if you Which projects do it differently? The Swift PTL always just announced additions. I seem to remember TripleO under Robert Collins directly adding members. Also Nova under Russell Bryant removed inactive members without asking for an existing core members poll. (and that is all good). That said, I agree with you that most projects copied the existing cores must agree rule. So this is where you loose me. Has there ever been a case of a project's PTL adding/removing people from the core team where the PTL goes against the majority of the core developers? You say that an early (unwritten?) goal of the system we have is to prevent 'aristocracy,' but all I see is 'aristocracy'. Obviously the PTL would only overrule the majority of his core reviewers in extreme cases. Imagine this extreme case: core reviewers in a project have become a pure aristocracy, nobody can get in anymore, fresh ideas and code are systematically rejected. There is a divide between contributors to the project (doing the work) and core reviewers. Project is completely blocked. At the next election, a PTL candidate campaigns on fixing this by dramatically changing the core team. Contributors rally to that candidacy, candidate is elected. Once elected, the PTL can fix the core team without asking the existing aristocracy blessing. Now I agree that it's a governance safety valve, designed to solve a mostly theoretical case. But sometimes having a bucket stops here rule is sufficient to prevent conflict. For example conflicts between two projects can be escalated to the TC for final resolution. In effect, that never happens: said projects usually solve the issue between themselves rather than ask the TC to arbitrate. The same effect
[openstack-dev] [stable] freeze exception
Hello Stable-Maintainers, Cores I'd like to request a freeze exception for the following change-set: https://review.openstack.org/#/c/156936/ IMO, this patch will not have any regression. Thanks Regards. Pranali Deore __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.__ 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] [Heat] [Ceilometer] [depfreeze] bug is unresolved due to requirements freeze
Pavlo Shchelokovskyy wrote: [...] We do better bump the requirements. The only projects I know of using ceilometerclient are Heat, Horizon and Ceilometer itself. No packager reported pain, so exception is granted and I approved the patch. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova][QA] Use case of Nova to boot VM from volume only
Hi, This is regarding bug - https://bugs.launchpad.net/tempest/+bug/1436314 When Nova is configured to boot VM from volume only, current Tempest integration tests will fails. We are not sure how feasible and valid this configuration is for Nova and what are the use cases of this. Before starting support this in Tempest, we would like to get some feedback and use cases about such configuration on Nova side. I am trying it by setting max_local_block_device to 0 and tests fails with 400 error[1]. Is that the right configuration to make boot from volume only or something else there on Nova config. 1- ERROR (BadRequest): Block Device Mapping is Invalid: You specified more local devices than the limit allows (HTTP 400) (Request-ID: req-3ef100c7- b5c5-4a2d-a5da-8344726336e2) -- Thanks Regards Ghanshyam Mann __ 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][Heat] Overcloud software updates and ResourceGroups
Hi,
On Fri, Apr 3, 2015 at 1:31 AM, Zane Bitter zbit...@redhat.com wrote:
A few of us have been looking for a way to perform software updates to
servers in a TripleO Heat/Puppet-based overcloud that avoids an impedance
mismatch with Heat concepts and how Heat runs its workflow. As many
talented TripleO-ers who have gone before can probably testify, that's
surprisingly difficult to do, but we did come up with an idea that I think
might work and which I'd like to get wider feedback on. For clarity, I'm
speaking here in the context of the new overcloud-without-mergepy templates.
The idea is that we create a SoftwareConfig that, when run, can update
some software on the server. (The exact mechanism for the update is not
important for this discussion; suffice to say that in principle it could be
as simple as [yum|apt-get] update.) The SoftwareConfig would have at
least one input, though it need not do anything with the value.
Then each server has that config deployed to it with a SoftwareDeployment
at the time it is created. However, it is set to execute only on the UPDATE
action. The value of (one of) the input(s) is obtained from a parameter.
As a result, we can trigger the software update by simply changing the
value of the input parameter, and the regular Heat dependency graph will be
respected. The actual input value could be by convention a uuid, a
timestamp, a random string, or just about anything so long as it changes.
Here's a trivial example of what this deployment might look like:
update_config:
type: OS::Heat::SoftwareConfig
properties:
config: {get_file: do_sw_update.sh}
inputs:
- name: update_after_time
description: Timestamp of the most recent update request
update_deployment:
type: OS::Heat::SoftwareDeployment
properties:
actions:
- UPDATE
config: {get_resource: update_config}
server: {get_resource: my_server}
input_values:
update_after_time: {get_param: update_timestamp}
(A possible future enhancement is that if you keep a mapping between
previous input values and the system state after the corresponding update,
you could even automatically handle rollbacks in the event the user decided
to cancel the update.)
And now we should be able to trigger an update to all of our servers, in
the regular Heat dependency order, by simply (thanks to the fact that
parameters now keep their previous values on stack updates unless they're
explicitly changed) running a command like:
heat stack-update my_overcloud -f $TMPL -P update_timestamp=$(date)
(A future goal of Heat is to make specifying the template again optional
too... I don't think that change landed yet, but in this case we can always
obtain the template from Tuskar, so it's not so bad.)
Astute readers may have noticed that this does not actually solve our
problem. In reality groups of similar servers are deployed within
ResourceGroups and there are no dependencies between the members. So, for
example, all of the controller nodes would be updated in parallel, with the
likely result that the overcloud could be unavailable for some time even if
it is deployed with HA.
The good news is that a solution to this problem is already implemented in
Heat: rolling updates. For example, the controller node availability
problem can be solved by setting a rolling update batch size of 1. The bad
news is that rolling updates are implemented only for AutoscalingGroups,
not ResourceGroups.
It seems we should implement rolling_updates for ResourceGroup, and even
more, rolling_create too. Just a couple of days ago we had a chat with
Sahara's PTL, Sergey Lukjanov, and he was asking if there is a way to
create a number of resources in batches, but with a single call. Sahara
does not need autoscaling, so our idea was exactly that - rolling_create
and rolling_update for ResourceGroups should solve this. Thus we have one
more use case for that, I'm going to raise a spec (or bug?) soon.
Accordingly, I propose that we switch the implementation of
overcloud-without-mergepy from ResourceGroups to AutoscalingGroups. This
would be a breaking change for overcloud updates (although no worse than
the change from merge.py over to overcloud-without-mergepy), but that also
means that there'll never be a better time than now to make it.
I suspect that some folks (Tomas?) have possibly looked into this in the
past... can anybody identify any potential obstacles to the change? Two
candidates come to mind:
1) The SoftwareDeployments (plural) resource type. I believe we carefully
designed that to work with both ResourceGroup and AutoscalingGroup though.
2) The elision feature (https://review.openstack.org/#/c/128365/). Steve,
I think this was only implemented for ResourceGroup? An AutoscalingGroup
version of this should be feasible though, or do we have better ideas for
how to solve it in that context?
[openstack-dev] Interaction between heat and nova
Hi Folks, I am trying if we can have an api call from heat to nova and hit one of the nova clients method. I want to have a check in heat and if that happens it should request nova for a change in the instance through one of nova's command. Any information regarding this. Thanks and Regards Abhishek Talwar =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you __ 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] [stable] freeze exception
Hello Stable-Maintainers, Cores I'd like to request a freeze exception for the following change-set: https://review.openstack.org/#/c/147844/ IMO, this patch will not have any regression. Thanks and Regards, Rajesh Tailor __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.__ 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] [stable] freeze exception
Hello, A request to get an exception for a fix related to PCI-Passthough. The backport seems to be reasonable and not invincible and the code is well covered by tests. The impact of this fix is to make compatible the config option 'pci_passthrough_whitelist' from icehouse to juno. https://review.openstack.org/#/c/170089/ Thanks, s __ 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] freeze exception
On Fri, Apr 03, 2015 at 09:37:30AM +0200, Sahid Orentino Ferdjaoui wrote: Hello, A request to get an exception for a fix related to PCI-Passthough. The backport seems to be reasonable and not invincible and the code is well covered by tests. s/invincible/invasive/ The impact of this fix is to make compatible the config option 'pci_passthrough_whitelist' from icehouse to juno. https://review.openstack.org/#/c/170089/ Thanks, s __ 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] Interaction between heat and nova
Abhishek, for communication with Nova Heat is using Nova's REST API via python-novaclient exclusively. So if any Nova functionality is exposed via novaclient's Python API - Heat can in principle do it. Another question is what are those check and change you are willing to do? This should be in line with Heat resource life cycle model. If it is some general thing applicable/useful to any OpenStack deployment you can propose a patch (or a spec first) and we can consider including it in upstream. If it is more specific to your deployment - you can make yourself a specialized resource as Heat resource plugin and override/extend any methods of OS::Nova::Server resource and use this plugin instead of OS::Nova::Server in your cloud (for an example see Rackspace Cloud Server resource in heat/contrib). Best regards, Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com On Fri, Apr 3, 2015 at 10:12 AM, Abhishek Talwar/HYD/TCS abhishek.tal...@tcs.com wrote: Hi Folks, I am trying if we can have an api call from heat to nova and hit one of the nova clients method. I want to have a check in heat and if that happens it should request nova for a change in the instance through one of nova's command. Any information regarding this. Thanks and Regards Abhishek Talwar =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you __ 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] [stable] freeze exception
Hi, I had like to request a freeze exception for this nova fix: https://review.openstack.org/#/c/164713/ Related bug: https://bugs.launchpad.net/nova/+bug/1406486 Suspending an instance fails when using vnic_type=direct My change is a backport from master to juno of the fix already merged into kilo. The backport didn't conflict, the change is the same: https://review.openstack.org/#/c/148096/ I compared manually using two tabs in Firefox :-) Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][QA] Use case of Nova to boot VM from volume only
On 04/03/2015 07:33 AM, GHANSHYAM MANN wrote: Hi, This is regarding bug - https://bugs.launchpad.net/tempest/+bug/1436314 When Nova is configured to boot VM from volume only, current Tempest integration tests will fails. We are not sure how feasible and valid this configuration is for Nova and what are the use cases of this. Before starting support this in Tempest, we would like to get some feedback and use cases about such configuration on Nova side. I am trying it by setting max_local_block_device to 0 and tests fails with 400 error[1]. Is that the right configuration to make boot from volume only or something else there on Nova config. 1- ERROR (BadRequest): Block Device Mapping is Invalid: You specified more local devices than the limit allows (HTTP 400) (Request-ID: req-3ef100c7-b5c5-4a2d-a5da-8344726336e2) Hey - I've responded on the bug. Let me know if the clarification makes sense to you. Cheers, Nikola __ 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] [stable] freeze exception
Hello, I'd like to request a freeze exception for this patch: https://review.openstack.org/#/c/167915/ here is the bug https://bugs.launchpad.net/nova/+bug/1408498 This patch is a bugfix of the High-priority bug. I think this is important bugfix because it fixes incorrect backporting of nova objects. If we wouldn't merge this bugfix, this bug may become cause of new bugs connected with using nova objects with different versions. __ 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] Use of heat for CI of OpenStack
I was wondering.. Is the OpenStack CI/CD Infra using Heat in any way? Do the commits trigger a new build of DevStack/OpenStack that is based on a Heat Template or just the provisioning of a regular instance and then deployment of code on top of that? -- Best Regards, Maish Saidel-Keesing __ 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] boot images in power state PAUSED for stable/juno
Hi Kevin, If you are using KVM as hyper visor and if your compute node having any issues with kvm acceleration, it can lead to the below problem - So ou can try changing the virt_type to qemu from kvm in /etc/nova/nova- compute.conf . After restarting the nova compute service - try to launch the vm again. Regards, Guna __ 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] [oslo] not running for PTL for liberty cycle
Team, I have decided not to run for PTL for Oslo for the next cycle. Serving as PTL for the last three releases has been a rewarding experience, and I think we’ve made some great strides together as a team. Now it’s time for me to step down and let someone else take the lead position. I am still committed to the mission, and I will be contributing to Oslo, but I do also want to work on some other projects that I won’t have time for if I stay in the PTL role. We have several good candidates for PTL on the team, and I expect us to have no trouble finding someone willing to step up and run. 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] [oslo] not running for PTL for liberty cycle
On 03/04/15 08:50 -0400, Doug Hellmann wrote: Team, I have decided not to run for PTL for Oslo for the next cycle. Serving as PTL for the last three releases has been a rewarding experience, and I think we’ve made some great strides together as a team. Now it’s time for me to step down and let someone else take the lead position. I am still committed to the mission, and I will be contributing to Oslo, but I do also want to work on some other projects that I won’t have time for if I stay in the PTL role. We have several good candidates for PTL on the team, and I expect us to have no trouble finding someone willing to step up and run. FWIW, I believe you did an *AMAZING* job as Oslo PTL. It was an honor to have you in that position. Thanks for your hard work. Flavio -- @flaper87 Flavio Percoco pgpPXWDzSDunl.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Problem about Juno Keystone Identity V3
Hi guys, I have done switching Keystone Identity V2 to V3 in Icehouse and it works perfect. However, I use the same way to switch Keystone Identity V2 to V3 in Juno, it doesn't work. It give me the error: ERROR: openstack Internal Server Error (HTTP 500). I traced back to the code, find the error comes from apache, but it doesn't make any sense that apache has problem, it might be some problem of keystone which lead to error of apache. Does any one have any idea of it? Thanks! -- Best regards, Amy (Yun Zhang) __ 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] Murano projects pylint job
Hi Kate and Serg Thanks for your feedback. I look forward to IRC discussion on that. Regards Filip On 04/02/2015 10:56 AM, Ekaterina Chernova wrote: Hi Filip and Serg! I support the idea! Let's discuss more details in IRC and summarize everything on the next community meeting on Tuesday. Regards, Kate. On Thu, Apr 2, 2015 at 11:31 AM, Filip Blaha filip.bl...@hp.com mailto:filip.bl...@hp.com wrote: Hi Serg we can inspire in other projects like sahara. Important is that pylint job should produce reasonable size meaningful output. Pylint without any configuration produces huge output. So we should point out which code checks are interesting for us and configure pylint accordingly. I will do some research on that. Regards Filip On 04/01/2015 05:57 PM, Serg Melikyan wrote: Hi Filip, I think adding pylint job to Murano gates is an awesome idea, have you checked out how to do this? On Wed, Apr 1, 2015 at 4:03 PM, Filip Blaha filip.bl...@hp.com mailto:filip.bl...@hp.com wrote: Hello I have noticed that some openstack projects [1] use pylint gate job. From my point of view it could simplify code reviews even as non-voing job and generally it could improve code quality. Some code issues like code duplication are not easy to discover during code review so automatic job would be helpful. Please let me know your opinion about that. Thanks [1] https://review.openstack.org/#/c/164772/ Regards Filip __ 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 -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com http://mirantis.com/ | smelik...@mirantis.com mailto: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 mailto: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] [heat][ceilometer]: scale up/ down based on number of instances in a group
Hi all, Does anyone know if the above use case has made it into the convergence project and in which release was/ is going to be merged? Thanks, Dani On Tue, Oct 28, 2014 at 5:40 PM, Daniel Comnea comnea.d...@gmail.com wrote: Thanks all for reply. I have spoke with Qiming and @Shardy (IRC nickname) and they confirmed this is not possible as of today. Someone else - sorry i forgot his nicname on IRC suggested to write a Ceilometer query to count the number of instances but what @ZhiQiang said is true and this is what we have seen via the instance sample *@Clint - *that is the case indeed *@ZhiQiang* - what do you mean by *count of resource should be queried from specific service's API*? Is it related to Ceilometer's event types configuration? *@Mike - *my use case is very simple: i have a group of instances and in case the # of instances reach the minimum number i set, i would like a new instance to be spun up - think like a cluster where i want to maintain a minimum number of members With regards to the proposal you made - https://review.openstack.org/#/c/127884/ that works but only in a specific use case hence is not generic because the assumption is that my instances are hooked behind a LBaaS which is not always the case. Looking forward to see the 'convergence' in action. Cheers, Dani On Tue, Oct 28, 2014 at 3:06 AM, Mike Spreitzer mspre...@us.ibm.com wrote: Daniel Comnea comnea.d...@gmail.com wrote on 10/27/2014 07:16:32 AM: Yes i did but if you look at this example https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml the flow is simple: CPU alarm in Ceilometer triggers the type: OS::Heat::ScalingPolicy which then triggers the type: OS::Heat::AutoScalingGroup Actually the ScalingPolicy does not trigger the ASG. BTW, ScalingPolicy is mis-named; it is not a full policy, it is only an action (the condition part is missing --- as you noted, that is in the Ceilometer alarm). The so-called ScalingPolicy does the action itself when triggered. But it respects your configured min and max size. What are you concerned about making your scaling group smaller than your configured minimum? Just checking here that there is not a misunderstanding. As Clint noted, there is a large-scale effort underway to make Heat maintain what it creates despite deletion of the underlying resources. There is also a small-scale effort underway to make ASGs recover from members stopping proper functioning for whatever reason. See https://review.openstack.org/#/c/127884/ for a proposed interface and initial implementation. Regards, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org 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] [stable] freeze exception
Hello Stable-Maintainers, Cores I'd like to request a freeze exception for the following change-set: https://review.openstack.org/142033 IMO, this patch will not have any regression. Thanks and Regards, Rajesh Tailor __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.__ 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] 答复: [heat] Application level HA via Heat
Sorry to chime in but i will throw in another use case for Steven since is
about the HA/ auto-scaling and i think it does match what i asked back in
October.
http://lists.openstack.org/pipermail/openstack-dev/2014-October/049375.html
If you need more info let me know
Dani
On Thu, Apr 2, 2015 at 10:59 AM, Huangtianhua huangtian...@huawei.com
wrote:
If we replace a autoscaling group member, we can't make sure the attached
resources keep the same, why not to call the evacuate or rebuild api of
nova,
just to add meters for ha(vm state or host state) in ceilometer, and then
signal to HA resource(such as HARestarter)?
-邮件原件-
发件人: Steven Hardy [mailto:sha...@redhat.com]
发送时间: 2014年12月23日 2:21
收件人: openstack-dev@lists.openstack.org
主题: [openstack-dev] [heat] Application level HA via Heat
Hi all,
So, lately I've been having various discussions around $subject, and I
know it's something several folks in our community are interested in, so I
wanted to get some ideas I've been pondering out there for discussion.
I'll start with a proposal of how we might replace HARestarter with
AutoScaling group, then give some initial ideas of how we might evolve that
into something capable of a sort-of active/active failover.
1. HARestarter replacement.
My position on HARestarter has long been that equivalent functionality
should be available via AutoScalingGroups of size 1. Turns out that
shouldn't be too hard to do:
resources:
server_group:
type: OS::Heat::AutoScalingGroup
properties:
min_size: 1
max_size: 1
resource:
type: ha_server.yaml
server_replacement_policy:
type: OS::Heat::ScalingPolicy
properties:
# FIXME: this adjustment_type doesn't exist yet
adjustment_type: replace_oldest
auto_scaling_group_id: {get_resource: server_group}
scaling_adjustment: 1
So, currently our ScalingPolicy resource can only support three adjustment
types, all of which change the group capacity. AutoScalingGroup already
supports batched replacements for rolling updates, so if we modify the
interface to allow a signal to trigger replacement of a group member, then
the snippet above should be logically equivalent to HARestarter AFAICT.
The steps to do this should be:
- Standardize the ScalingPolicy-AutoScaling group interface, so
aynchronous adjustments (e.g signals) between the two resources don't use
the adjust method.
- Add an option to replace a member to the signal interface of
AutoScalingGroup
- Add the new replace adjustment type to ScalingPolicy
I posted a patch which implements the first step, and the second will be
required for TripleO, e.g we should be doing it soon.
https://review.openstack.org/#/c/143496/
https://review.openstack.org/#/c/140781/
2. A possible next step towards active/active HA failover
The next part is the ability to notify before replacement that a scaling
action is about to happen (just like we do for LoadBalancer resources
already) and orchestrate some or all of the following:
- Attempt to quiesce the currently active node (may be impossible if it's
in a bad state)
- Detach resources (e.g volumes primarily?) from the current active node,
and attach them to the new active node
- Run some config action to activate the new node (e.g run some config
script to fsck and mount a volume, then start some application).
The first step is possible by putting a SofwareConfig/SoftwareDeployment
resource inside ha_server.yaml (using NO_SIGNAL so we don't fail if the
node is too bricked to respond and specifying DELETE action so it only runs
when we replace the resource).
The third step is possible either via a script inside the box which polls
for the volume attachment, or possibly via an update-only software config.
The second step is the missing piece AFAICS.
I've been wondering if we can do something inside a new heat resource,
which knows what the current active member of an ASG is, and gets
triggered on a replace signal to orchestrate e.g deleting and creating a
VolumeAttachment resource to move a volume between servers.
Something like:
resources:
server_group:
type: OS::Heat::AutoScalingGroup
properties:
min_size: 2
max_size: 2
resource:
type: ha_server.yaml
server_failover_policy:
type: OS::Heat::FailoverPolicy
properties:
auto_scaling_group_id: {get_resource: server_group}
resource:
type: OS::Cinder::VolumeAttachment
properties:
# FIXME: refs is a ResourceGroup interface not currently
# available in AutoScalingGroup
instance_uuid: {get_attr: [server_group, refs, 1]}
server_replacement_policy:
type: OS::Heat::ScalingPolicy
properties:
# FIXME: this adjustment_type doesn't exist yet
adjustment_type: replace_oldest
auto_scaling_policy_id: {get_resource:
[openstack-dev] [stable] Add project tag to your stable freeze exception request
Greetings, Just a reminder/suggestion. When sending your stable freeze exception request, please, add the project tag to thre thread so that stable maintainers of each project can chime in as well. IMHO, each exception should receive the bless of at least one of the project's stable maintainer before another stable maintaner can move it forward. Cheers, Flavio -- @flaper87 Flavio Percoco pgpwXeYEkfAoZ.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [scheduler] [gantt] Please stop using Gantt for discussing about Nova scheduler
Yes the current effort is to clean up the scheduler interfaces but one of the main goals of that clean up is to make it possible to then split out the scheduler to a separate project. I don't want to lose focus on the ultimate goal of creating the split. What we call that separate project is completely arbitrary. To me Gantt is the separate scheduler, the steps we go through to achieve that starts with the clean up and continues through the split. We can change the names but until we do the split any name we chose will still be just a goal. Calling the separate scheduler gantt or fubar or xyzzy makes no difference, we still have to clean up the scheduler interfaces and split out the code. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 -Original Message- From: Sean Dague [mailto:s...@dague.net] Sent: Thursday, April 2, 2015 4:22 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] [scheduler] [gantt] Please stop using Gantt for discussing about Nova scheduler Gantt is a dead and abandoned source tree, it also means nothing to new people joining into helping with the nova scheduler. It keeps generating confusion. Gantt is dead, the current effort is nova-scheduler improvement. Please just call it that. -Sean On 04/02/2015 04:10 AM, Sylvain Bauza wrote: Le 02/04/2015 01:28, Dugger, Donald D a écrit : I think there's a lot of `a rose by any other name would smell as sweet' going on here, we're really just arguing about how we label things. I admit I use the term gantt as a very expansive, this is the effort to clean up the current scheduler and create a separate scheduler as a service project. There should be no reason that this effort should turn off people, if you're interested in the scheduler then very quickly you will get pointed to gantt. I'd like to hear what others think but I still don't see a need to change the name (but I'm willing to change if the majority thinks we should drop gantt for now). Erm, I discussed that point during the weekly meeting and I pledged for people giving their opinion in this email. http://eavesdrop.openstack.org/meetings/gantt/2015/gantt.2015-03-31-15 .00.html As a meeting is by definition a synchronous thing, should we maybe try to async that decision using Gerrit ? I could pop up a resolution in Gerrit so that people could -1 or +1 it. -Sylvain -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 -Original Message- From: Sylvain Bauza [mailto:sba...@redhat.com] Sent: Tuesday, March 31, 2015 1:49 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] [scheduler] [gantt] Please stop using Gantt for discussing about Nova scheduler Le 31/03/2015 02:57, Dugger, Donald D a écrit : I actually prefer to use the term Gantt, it neatly encapsulates the discussions and it doesn't take much effort to realize that Gantt refers to the scheduler and, if you feel there is confusion, we can clarify things in the wiki page to emphasize the process: clean up the current scheduler interfaces and then split off the scheduler. The end goal will be the Gantt scheduler and I'd prefer not to change the discussion. Bottom line is I don't see a need to drop the Gantt reference. While I agree with you that *most* of the scheduler effort is to spin-off the scheduler as a dedicated repository whose codename is Gantt, there are some notes to do : 1. not all the efforts are related to the split, some are only reducing the tech debt within Nova (eg. bp/detach-service-from-computenode has very little impact on the scheduler itself, but rather on what is passed to the scheduler as resources) and may confuse people who could wonder why it is related to the split 2. We haven't yet agreed on a migration path for Gantt and what will become the existing nova-scheduler. I seriously doubt that the Nova community would accept to keep the existing nova-scheduler as a feature duplicate to the future Gantt codebase, but that has been not yet discussed and things can be less clear 3. Based on my experience, we are loosing contributors or people interested in the scheduler area because they just don't know that Gantt is actually at the moment the Nova scheduler. I seriously don't think that if we decide to leave the Gantt codename unused while we're working on Nova, it won't seriously impact our capacity to propose an alternative based on a separate repository, ideally as a cross-project service. It will just translate the reality, ie. that Gantt is at the moment more an idea than a project. -Sylvain -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 -Original Message- From: Sylvain Bauza [mailto:sba...@redhat.com] Sent: Monday, March 30, 2015 8:17 AM To: OpenStack
Re: [openstack-dev] [Horizon] PTL Candidacy
confirmed On 04/03/2015 01:28 PM, David Lyle wrote: I would like to announce my candidacy for Horizon PTL. I have been actively contributing to Horizon since the Grizzly Summit and I've had the pleasure of serving as PTL for the last three cycles. In Kilo, we accelerated Horizon's adoption of AngularJS. We made a great deal of progress, with a near finished replacement of the launch instance workflow, The launch instance workflow was the number one usability issue in Horizon when tested. We've also created a framework to standardize and improve how filtering, pagination and data loading is managed in tables. The utilization of this framework begins in Liberty. We've worked to better incorporate UX design into our process. The UX team is now a part of the feature design process. In Liberty, we'll look to further formalize this workflow. Additionally, we've conducted several usability studies to obtain feedback on designs and information architecture from users and potential users. The results are helping guide design as we move forward. We will continue to test new and existing interfaces and designs. Over the past three cycles, interest in Horizon has grown dramatically, but as with most of OpenStack, we are feeling those growing pains. As a horizontal integration point, Horizon needs to adapt to handle the increasing breadth of services in OpenStack. In Juno and Kilo, we built and refined a plugin system for adding new content into Horizon. In Liberty, we'll see more services utilizing this mechanism and allow service teams to retain greater control of their Horizon content. In Liberty, Horizon needs to focus on existing efforts around improving usability, better support for large deployments and more useful administrative interfaces. We've set the stage to make significant strides in Liberty. I appreciate your consideration for the opportunity to continue enabling our tremendous team of contributors to make it happen. I'm excited by the progress we've made and the prospect of seeing several of our project's long term goals become reality in Liberty. Thanks, David __ 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: OpenPGP digital 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] [stable][keystone] FFE for Speed up memcache lock
Hello, I would like to get a FFE for patch https://review.openstack.org/#/c/166496/ . The patch removes progressive calculation of sleep timeouts in memcache. The progressive calculation lead to issues on load, causing timeouts and slowness incommensurable with the load. The patch in question was already accepted in master branch. -- Best regards, Boris Bobrov __ 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][keystone] FFE for Speed up memcache lock
This would be a reasonable ffe for a stable backport if there is one. This is a significant improvement for the memcache locking retry. --Morgan. Sent via mobile On Apr 3, 2015, at 09:21, Boris Bobrov bbob...@mirantis.com wrote: Hello, I would like to get a FFE for patch https://review.openstack.org/#/c/166496/ . The patch removes progressive calculation of sleep timeouts in memcache. The progressive calculation lead to issues on load, causing timeouts and slowness incommensurable with the load. The patch in question was already accepted in master branch. -- Best regards, Boris Bobrov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [scheduler] [gantt] Please stop using Gantt for discussing about Nova scheduler
The goal is not `splitting for the sake of splitting'. The goal is to have a separate scheduler that is ultimately usable by other projects inside OpenStack. Currently Cinder has its own filter based scheduler (duplicating scheduling code in 2 places seems silly), Neutron will need scheduling services, there are multiple places where a common scheduling service would be beneficial. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 -Original Message- From: Ed Leafe [mailto:e...@leafe.com] Sent: Friday, April 3, 2015 10:59 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] [scheduler] [gantt] Please stop using Gantt for discussing about Nova scheduler -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/03/2015 11:42 AM, Dugger, Donald D wrote: Yes the current effort is to clean up the scheduler interfaces but one of the main goals of that clean up is to make it possible to then split out the scheduler to a separate project. I don't want to lose focus on the ultimate goal of creating the split. I don't agree that the ultimate goal is splitting the scheduler. IMO, the goal is to create 1) a clean, robust interface along with 2) a scalable architecture. Those improvements will 1) allow the scheduler to be split cleanly, and 2) justify splitting it out. Splitting for the sake of splitting is pointless. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJVHsbeAAoJEKMgtcocwZqLdysQAIJ6nThjqgNgJu1hLW4n6MDY Db57k+37b5M5h6Z633jrXSTWCuqjIwUIW2G1+PQMsXq7FcWguAG7fxhVizE4s0h0 RhucmNQ1GWj6eFNfpSljC0WAdZEDhuXnPcxi2OyMwRr0j2lqYcJvPKBmuobS8Rbl xD9ciIlVELtHPm2dsj1HkB8TO7fgESjdv+I2QPU9C31ubp0CYlwSAPCdAhN9g+B0 WVCEnq+7ADn95G+/z77Wlx6s83KkCh89C+h2ivgGI4mHeWJskXT9lr9lsC342DO9 GoWvDvRF5H9/imx6Jh4avipH55YCZfZ9T+2eOPVoAYkXujPiX13tqM8UkBj7KCDx /FJNatC0aTDPYGMgOW329pGWkP9n2ceW1gMlyHpmMFJHCaAdmM+gqnjnarT1UECr 13yndy9axjubisZ71hdGgBi/Sy1FbG5+XVshWyAUgzoJZurDtg4RhhUdw8n0iQKd SuA3E9Z+PI6gTulp532JdHBVOpsG2P+9QOzLwBEnpSp8WmuU8h2EVMm6A3Zdrf+4 zIUL8lvpDwZ/0KBHSF6WptZspSXe/OwOKlQYO2geHkeARANv3Tv/h3HB/7SW1Bz0 8N5K2aDK/adzfzagrV0S3f201JoFC90JSXgA4dDdtHr8/oUj1kw3QoTACVrvPvYP ayW76hfM68cjJ3DyhXys =5h63 -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
Re: [openstack-dev] [Infra] PTL Candidacy
confirmed On 04/02/2015 05:35 PM, James E. Blair wrote: I would like to announce my candidacy for the Infrastructure PTL. I have developed and operated the project infrastructure for several years and have been honored to serve as the PTL for the Kilo cycle. I was instrumental not only in creating the project gating system and development process, but also in scaling it from three projects to 600. In Juno, we have begun a real effort to make the project infrastructure consumable in its own right. We've made a lot of progress and we're seeing more people joining this effort as we get closer to the goal of re-usability. It's starting to pay off, but we still have a lot to do. We're also looking at getting into the business of operating an OpenStack cloud. This is potentially a very exciting new venture, with a heavily used production cloud available for anyone in OpenStack to see and alter its operation. We're only just starting this project and hope to settle on some parameters as soon as we finish up our current priorities. I have also proposed some major changes to the key infrastructure projects Zuul and Nodepool. In both cases, the intent is to help us continue to scale out the system to handle more projects easier, and to make the overall system more comprehensible. Those are just three of several important efforts I anticipate this cycle and they span the spectrum from software development to operations. Once again, a large part of the work of the PTL this cycle will be helping to coordinate and facilitate these efforts. I am thrilled to be a part of one of the most open free software project infrastructures, and I would very much like to continue to serve as its PTL. Thanks, Jim __ 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: OpenPGP digital 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] [Ceilometer] PTL candidacy
confirmed On 04/02/2015 04:29 PM, gordon chung wrote: hi, i'd like to announce my candidacy for PTL of Ceilometer. as a quick introduction, i've been a contributor in OpenStack for the past few years and for the majority of that time i've been primarily focused on Ceilometer where i contribute regularly to the project with code[1] and reviews[2]. i'm currently an engineer at Red Hat and have previously worked for eNovance and IBM, where in the latter's case, i helped work on advancing the adoption of cloud auditing practices within the community, which i continue to do. to model myself on past PTLs i've worked with, my main goal as PTL will be to support the community of contributors that exists within OpenStack with interests in telemetry. i believe we have a wide variety of contributors with various expertise in Ceilometer and OpenStack and while differing opinions have arisen, as a collective, we have -- and can continue to -- hash out the ideal solutions. with the politically correct portion all covered, my other interests are: stability, the transition to time-series data modeling aka Gnocchi, and events. - we've made strides in Ceilometer over the past cycles to improve stability by adding HA support, remodeling backends, and removing redundancies in Ceilometer. i want to make sure we remain critical of new changes and always ensure they do not add bloat to Ceilometer. - in regards to data storage, while Ceilometer can be used solely as a data retrieval service, i believe Gnocchi -- the modeling of data as a time-series -- will provide a scalable means to storing measurement data regarding OpenStack[3]. this work, i believe, will be important for those using Ceilometer as a complete solution. - the concept of events was realised by the team at RAX and was worked on further in the last cycle. i hope to see this functionality continue to expand by adding the ability to derive and act on events to allow greater insight into the system. - lastly, i want to emphasise documentation. Ceilometer's scope touches all projects and because of that, it can be difficult to pick up. in Kilo, we started to emphasise the importance of documentation and i hope we continue to do so going forward. [1] https://review.openstack.org/#/q/owner:%22gordon+chung%22+project:openstack/ceilometer,n,z[2] http://russellbryant.net/openstack-stats/ceilometer-reviewers-365.txt[3] http://www.slideshare.net/EoghanGlynn/rdo-hangout-on-gnocchi cheers, gord __ 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: OpenPGP digital 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] The Evolution of core developer to maintainer?
On Fri, Apr 3, 2015 at 1:39 AM, Thierry Carrez thie...@openstack.org wrote: Joe Gordon wrote: On Thu, Apr 2, 2015 at 3:14 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Joe Gordon wrote: I cannot speak for all projects, but at least in Nova you have to be a nova-core to be part of nova-drivers. And would you describe that as a good thing ? If John Garbutt is so deep into release liaison work that he can't sustain a review rate suitable to remain a core reviewer, would you have him removed from the maintainers group ? If someone steps up and works full-time on triaging bugs in Nova (and can't commit to do enough reviews as a result), would you exclude that person from your maintainers group ? I want to empower that person and recognize them in some semi formal capacity and make sure they have all the correct permissions. I do not want a single flat 'maintainers' group, I think we need a hierarchical notion of maintainers, where different people can end up with very different responsibilities (and ACLs -- but that is a implementation detail). OK, so I probably misread your proposal[1]. My understanding was you wanted a single flat maintainers group that would purely replace core reviewers, keep the same rights and just add duties to the already-existing reviewing duties. [1] https://review.openstack.org/#/c/163660/ So that proposal was not the end goal it was supposed to be a very tiny first step down this path. I see how that was misleading. Since I thought project leadership needs to be expressed in a much more diverse and inclusive way (and explicitly not tied to +2 rights), I opposed such simple renaming. From what you're saying now your objective is the same as mine. I'm not sure the maintainers group needs to be purely hierarchical (I think I'd Hierarchical, in the sense of subsystem maintainers. Not all duties would have to be that way though. prefer it to be a set of duties with no hierarchy between them), but I agree that: - today core reviewers are the only visible project duty, and we need to expose and reward all the others, as separate attributes ++ - we could use a blanket term (maintainers ?) to describe the people holding one or more of those attributes. ++ OpenStack governance mandates that core developers are ultimately the PTL's choice. Since the PTL is regularly elected by all contributors, that prevents aristocracy. Can you site your source for this? Because the earliest reference to 'Core Developer' (what you are calling core reviewer -- even though that is not the original name) that I could find says nothing about it ultimately being the PTLs choice. PTLs have (and always had) ultimate say over their project matters. That includes how to select core reviewers (or how reviews should be performed). A lot of projects let their PTL directly determine who should (and should no longer) be on the core list. https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess Now it's true that very early on, a lot of PTLs adopted a more open process to help in that selection. That doesn't mean they can't bypass the process. Personally I think that the apparently open process for core selection just resulted in reinforcing the aristocracy. This is why I encourage PTLs to own the content of core reviewing teams more directly. However in some projects, core reviewers have to be approved by existing core reviewers. That is an aristocracy. In those projects, if you Which projects do it differently? The Swift PTL always just announced additions. I seem to remember TripleO under Robert Collins directly adding members. Also Nova under Russell Bryant removed inactive members without asking for an existing core members poll. (and that is all good). That said, I agree with you that most projects copied the existing cores must agree rule. It sounds like writing down this aspect of the PTL powers may be something worth writing down in the governance repo somewhere? So this is where you loose me. Has there ever been a case of a project's PTL adding/removing people from the core team where the PTL goes against the majority of the core developers? You say that an early (unwritten?) goal of the system we have is to prevent 'aristocracy,' but all I see is 'aristocracy'. Obviously the PTL would only overrule the majority of his core reviewers in extreme cases. Imagine this extreme case: core reviewers in a project have become a pure aristocracy, nobody can get in anymore, fresh ideas and code are systematically rejected. There is a divide between While a safety valve like this is fine, I am not sure if its existence is why these issues have never arose, and have a hard time imagining this safety valve actually being used. If this did happen there is a better safety
Re: [openstack-dev] [QA] PTL Candidacy
confirmed On 04/03/2015 12:33 PM, Matthew Treinish wrote: Hi Everyone, I'd like to throw my hat into the ring for another cycle as the PTL for the QA program/team/group/whatever it's called under the new governance model. This past cycle has been a very exciting one for the QA program. We've made a bunch of progress on numerous work items to improve the growing number of projects under the QA umbrella. While this work is ongoing we've also had to adapt as the wider community has been moving to a new governance model. We've been working to make the QA program more externally accessible and consumable in preparation for a large growth in the number of projects. On the tempest side this has meant a steady expansion of code being moved into tempest-lib to provide resources, which were previously only available in tempest, externally consumable. For devstack we've seen the addition of plugin support which allows new projects to leverage deploying, testing, and developing with devstack without needing to modify devstack's code itself. Another effort which I outlined in my candidacy email for this past cycle [1] and a blog post preceding that [2] was the work to make the QA projects more modular and reusable. It turned out that this work lines up quite well with what is needed to enable the self service model we're working towards under the big tent. I expect that as we continue to evolve our current set of projects to be more modular and work under the big tent that using the tooling in different workflows will also improve. Moving into Liberty my plan is to continue heading down this same path and working to enable more projects to become self sufficient when using QA projects. To this end I expect we'll be adding a similar external plugin interface into grenade early in liberty, a continued expansion on the use of devstack plugins, and migrating more of tempest's common code over to tempest-lib. Additionally, the continued efforts that we've been pushing for some time to make tempest and the other QA projects easier to use in general, both in and out of the gate, will definitely continue. This is something we've made a lot of progress on this past cycle and think it will definitely be a continued priority for Liberty. It's been my honor to serve as the QA PTL for the past 2 cycles and I'm looking forward to helping make Liberty another great cycle. I hope to have the opportunity to continue leading the QA program as PTL and work towards making a better OpenStack with the rest of the community. Thanks, Matt Treinish [1] http://lists.openstack.org/pipermail/openstack-dev/2014-September/046704.html [2] http://blog.kortar.org/?p=4 __ 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: OpenPGP digital 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] Barbican : Unable to reterieve asymmetric order request for rsa algorithm type
Hi All ,
Could any one please let me know if Barbican would support asymmetric order
retrieval and the request .
Please find the curl command and response for creating the order and
retrieving the order
root@barbican:~# curl -X POST -H 'content-type:application/json' -H
'X-Project-Id: 12345' -d '{type : asymmetric, meta: {name:
secretnamepk2, algorithm: rsa, bit_length: 256, mode: cbc,
payload_content_type: application/octet-stream}}'
http://localhost:9311/v1/orders
{order_ref:
http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c
}root@barbican:~#
root@barbican:~# curl -H 'Accept: application/json' -H 'X-Project-Id:12345'
http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c
{status: ERROR, updated: 2015-03-30T21:36:38.102832, created:
2015-03-30T21:36:38.083428, order_ref:
http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c;,
meta: {name: secretnamepk2, algorithm: rsa,
payload_content_type: application/octet-stream, mode: cbc,
bit_length: 256, expiration: null}, *error_status_code: 400,
error_reason: Process TypeOrder issue seen - No plugin was found that
could support your request., type: asymmetric}*root@barbican:~#
*It seems that we are unable to reterive the asymmetric order request*
Could any one please help.
Any Help would be appreciated.
Thanks in Advance
On Mon, Mar 30, 2015 at 4:42 PM, Asha Seshagiri asha.seshag...@gmail.com
wrote:
Hi All ,
I would like to know whether Barbican supports asymmetric order request .
Please find the curl command and response for creating the order and
retrieving the order
root@barbican:~# curl -X POST -H 'content-type:application/json' -H
'X-Project-Id: 12345' -d '{type : asymmetric, meta: {name:
secretnamepk2, algorithm: rsa, bit_length: 256, mode: cbc,
payload_content_type: application/octet-stream}}'
http://localhost:9311/v1/orders
{order_ref:
http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c
}root@barbican:~#
root@barbican:~# curl -H 'Accept: application/json' -H
'X-Project-Id:12345'
http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c
{status: ERROR, updated: 2015-03-30T21:36:38.102832, created:
2015-03-30T21:36:38.083428, order_ref:
http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c;,
meta: {name: secretnamepk2, algorithm: rsa,
payload_content_type: application/octet-stream, mode: cbc,
bit_length: 256, expiration: null}, *error_status_code: 400,
error_reason: Process TypeOrder issue seen - No plugin was found that
could support your request., type: asymmetric}*root@barbican:~#
Could any one please help.
Thanks in Advance
--
*Thanks and Regards,*
*Asha Seshagiri*
--
*Thanks and Regards,*
*Asha Seshagiri*
__
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] [scheduler] [gantt] Please stop using Gantt for discussing about Nova scheduler
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/03/2015 11:42 AM, Dugger, Donald D wrote: Yes the current effort is to clean up the scheduler interfaces but one of the main goals of that clean up is to make it possible to then split out the scheduler to a separate project. I don't want to lose focus on the ultimate goal of creating the split. I don't agree that the ultimate goal is splitting the scheduler. IMO, the goal is to create 1) a clean, robust interface along with 2) a scalable architecture. Those improvements will 1) allow the scheduler to be split cleanly, and 2) justify splitting it out. Splitting for the sake of splitting is pointless. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJVHsbeAAoJEKMgtcocwZqLdysQAIJ6nThjqgNgJu1hLW4n6MDY Db57k+37b5M5h6Z633jrXSTWCuqjIwUIW2G1+PQMsXq7FcWguAG7fxhVizE4s0h0 RhucmNQ1GWj6eFNfpSljC0WAdZEDhuXnPcxi2OyMwRr0j2lqYcJvPKBmuobS8Rbl xD9ciIlVELtHPm2dsj1HkB8TO7fgESjdv+I2QPU9C31ubp0CYlwSAPCdAhN9g+B0 WVCEnq+7ADn95G+/z77Wlx6s83KkCh89C+h2ivgGI4mHeWJskXT9lr9lsC342DO9 GoWvDvRF5H9/imx6Jh4avipH55YCZfZ9T+2eOPVoAYkXujPiX13tqM8UkBj7KCDx /FJNatC0aTDPYGMgOW329pGWkP9n2ceW1gMlyHpmMFJHCaAdmM+gqnjnarT1UECr 13yndy9axjubisZ71hdGgBi/Sy1FbG5+XVshWyAUgzoJZurDtg4RhhUdw8n0iQKd SuA3E9Z+PI6gTulp532JdHBVOpsG2P+9QOzLwBEnpSp8WmuU8h2EVMm6A3Zdrf+4 zIUL8lvpDwZ/0KBHSF6WptZspSXe/OwOKlQYO2geHkeARANv3Tv/h3HB/7SW1Bz0 8N5K2aDK/adzfzagrV0S3f201JoFC90JSXgA4dDdtHr8/oUj1kw3QoTACVrvPvYP ayW76hfM68cjJ3DyhXys =5h63 -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] Problem about Juno Keystone Identity V3
We've run into issues with nova+neutron and keystone v3 with Juno. Specifically this one: https://bugs.launchpad.net/nova/+bug/1424462 But there may be others that I don't know about. Thanks, Kevin From: Rich Megginson [rmegg...@redhat.com] Sent: Friday, April 03, 2015 10:52 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Problem about Juno Keystone Identity V3 On 04/03/2015 09:09 AM, Amy Zhang wrote: Hi guys, I have done switching Keystone Identity V2 to V3 in Icehouse and it works perfect. However, I use the same way to switch Keystone Identity V2 to V3 in Juno, it doesn't work. It give me the error: ERROR: openstack Internal Server Error (HTTP 500). What steps did you follow? Links? I traced back to the code, find the error comes from apache, but it doesn't make any sense that apache has problem, it might be some problem of keystone which lead to error of apache. Does any one have any idea of it? Thanks! -- Best regards, Amy (Yun Zhang) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribemailto: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] [Infra] Use of heat for CI of OpenStack
Clint Byrum wrote: Excerpts from Joshua Harlow's message of 2015-04-03 10:08:07 -0700: Monty Taylor wrote: On 04/03/2015 08:55 AM, Maish Saidel-Keesing wrote: I was wondering.. Is the OpenStack CI/CD Infra using Heat in any way? Do the commits trigger a new build of DevStack/OpenStack that is based on a Heat Template or just the provisioning of a regular instance and then deployment of code on top of that? Nope - we do not use heat - we use a program called nodepool: http://git.openstack.org/cgit/openstack-infra/nodepool/ Which uses the nova api to provision servers. These servers are currently registered as jenkins slaves so that the workload run on them is defined a s jenkins job. There are a few reasons we do not use heat for this - none of them I think of as negative against heat: - Our pool spans 4 regions of 2 public clouds. Heat runs in a cloud, the positioning is wrong - Our pool is predominantly single-machines that are used once - which means a heat template would add extra complexity for not much gain. - Our current system predates the existence of heat. It is also highly specific to the task at hand - namely, ensuring that there are always test nodes available. Can these things be fixed? Heat afaik isn't a frozen piece of sofware... It would be pretty neat to use the projects that we have that others are using if we could. Might be an interesting summit topic/idea? Monty said these aren't negatives. They're just aspects. Heat is supposed to alleviate you from needing to build something specific like Nodepool. But it wasn't there, and nodepool is specific to the task, so there's no point in using Heat for it. It's like using hammer and nails to build your scaffolding because you don't have a nailgun. Was it ideal? No, but at this point, the scaffolding is built.. no point in tearing it down so you can build it again, only faster. Fair enough, if the house is built and its setup, then sure, but if its a shack and u can upgrade to a house, sometimes it is better to just remove the scaffolding and move into a house... (today must be analogy day, ha). __ 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] [QA] PTL Candidacy
Hi Everyone, I'd like to throw my hat into the ring for another cycle as the PTL for the QA program/team/group/whatever it's called under the new governance model. This past cycle has been a very exciting one for the QA program. We've made a bunch of progress on numerous work items to improve the growing number of projects under the QA umbrella. While this work is ongoing we've also had to adapt as the wider community has been moving to a new governance model. We've been working to make the QA program more externally accessible and consumable in preparation for a large growth in the number of projects. On the tempest side this has meant a steady expansion of code being moved into tempest-lib to provide resources, which were previously only available in tempest, externally consumable. For devstack we've seen the addition of plugin support which allows new projects to leverage deploying, testing, and developing with devstack without needing to modify devstack's code itself. Another effort which I outlined in my candidacy email for this past cycle [1] and a blog post preceding that [2] was the work to make the QA projects more modular and reusable. It turned out that this work lines up quite well with what is needed to enable the self service model we're working towards under the big tent. I expect that as we continue to evolve our current set of projects to be more modular and work under the big tent that using the tooling in different workflows will also improve. Moving into Liberty my plan is to continue heading down this same path and working to enable more projects to become self sufficient when using QA projects. To this end I expect we'll be adding a similar external plugin interface into grenade early in liberty, a continued expansion on the use of devstack plugins, and migrating more of tempest's common code over to tempest-lib. Additionally, the continued efforts that we've been pushing for some time to make tempest and the other QA projects easier to use in general, both in and out of the gate, will definitely continue. This is something we've made a lot of progress on this past cycle and think it will definitely be a continued priority for Liberty. It's been my honor to serve as the QA PTL for the past 2 cycles and I'm looking forward to helping make Liberty another great cycle. I hope to have the opportunity to continue leading the QA program as PTL and work towards making a better OpenStack with the rest of the community. Thanks, Matt Treinish [1] http://lists.openstack.org/pipermail/openstack-dev/2014-September/046704.html [2] http://blog.kortar.org/?p=4 pgpqXNPJyxzUK.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Barbican : Unable to reterieve asymmetric order request for rsa algorithm type
Hi All ,
Could any one please let me know if Barbican would support asymmetric order
retrieval and the request .
Please find the curl command and response for creating the order and
retrieving the order
root@barbican:~# curl -X POST -H 'content-type:application/json' -H
'X-Project-Id: 12345' -d '{type : asymmetric, meta: {name:
secretnamepk2, algorithm: rsa, bit_length: 256, mode: cbc,
payload_content_type: application/octet-stream}}'
http://localhost:9311/v1/orders
{order_ref:
http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c
}root@barbican:~#
root@barbican:~# curl -H 'Accept: application/json' -H 'X-Project-Id:12345'
http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c
{status: ERROR, updated: 2015-03-30T21:36:38.102832, created:
2015-03-30T21:36:38.083428, order_ref:
http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c ,
meta: {name: secretnamepk2, algorithm: rsa,
payload_content_type: application/octet-stream, mode: cbc,
bit_length: 256, expiration: null}, error_status_code: 400,
error_reason: Process TypeOrder issue seen - No plugin was found that
could support your request., type: asymmetric} root@barbican:~#
It seems that we are unable to reterive the asymmetric order request
Could any one please help.
Any Help would be appreciated.
Hi,
I don't know about your plugins, but I believe the default one needs at least
1024 of bit length.
--
Thomas
__
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] [Infra] Use of heat for CI of OpenStack
Excerpts from Joshua Harlow's message of 2015-04-03 10:08:07 -0700: Monty Taylor wrote: On 04/03/2015 08:55 AM, Maish Saidel-Keesing wrote: I was wondering.. Is the OpenStack CI/CD Infra using Heat in any way? Do the commits trigger a new build of DevStack/OpenStack that is based on a Heat Template or just the provisioning of a regular instance and then deployment of code on top of that? Nope - we do not use heat - we use a program called nodepool: http://git.openstack.org/cgit/openstack-infra/nodepool/ Which uses the nova api to provision servers. These servers are currently registered as jenkins slaves so that the workload run on them is defined a s jenkins job. There are a few reasons we do not use heat for this - none of them I think of as negative against heat: - Our pool spans 4 regions of 2 public clouds. Heat runs in a cloud, the positioning is wrong - Our pool is predominantly single-machines that are used once - which means a heat template would add extra complexity for not much gain. - Our current system predates the existence of heat. It is also highly specific to the task at hand - namely, ensuring that there are always test nodes available. Can these things be fixed? Heat afaik isn't a frozen piece of sofware... It would be pretty neat to use the projects that we have that others are using if we could. Might be an interesting summit topic/idea? Monty said these aren't negatives. They're just aspects. Heat is supposed to alleviate you from needing to build something specific like Nodepool. But it wasn't there, and nodepool is specific to the task, so there's no point in using Heat for it. It's like using hammer and nails to build your scaffolding because you don't have a nailgun. Was it ideal? No, but at this point, the scaffolding is built.. no point in tearing it down so you can build it again, only faster. __ 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] [Infra] Use of heat for CI of OpenStack
On 04/03/2015 08:55 AM, Maish Saidel-Keesing wrote: I was wondering.. Is the OpenStack CI/CD Infra using Heat in any way? Do the commits trigger a new build of DevStack/OpenStack that is based on a Heat Template or just the provisioning of a regular instance and then deployment of code on top of that? Nope - we do not use heat - we use a program called nodepool: http://git.openstack.org/cgit/openstack-infra/nodepool/ Which uses the nova api to provision servers. These servers are currently registered as jenkins slaves so that the workload run on them is defined a s jenkins job. There are a few reasons we do not use heat for this - none of them I think of as negative against heat: - Our pool spans 4 regions of 2 public clouds. Heat runs in a cloud, the positioning is wrong - Our pool is predominantly single-machines that are used once - which means a heat template would add extra complexity for not much gain. - Our current system predates the existence of heat. It is also highly specific to the task at hand - namely, ensuring that there are always test nodes available. __ 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] [scheduler] [gantt] Please stop using Gantt for discussing about Nova scheduler
On 04/03/2015 12:59 PM, Ed Leafe wrote: On 04/03/2015 11:42 AM, Dugger, Donald D wrote: Yes the current effort is to clean up the scheduler interfaces but one of the main goals of that clean up is to make it possible to then split out the scheduler to a separate project. I don't want to lose focus on the ultimate goal of creating the split. I don't agree that the ultimate goal is splitting the scheduler. IMO, the goal is to create 1) a clean, robust interface along with 2) a scalable architecture. Those improvements will 1) allow the scheduler to be split cleanly, and 2) justify splitting it out. Splitting for the sake of splitting is pointless. +1000 -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] PTL Candidacy
I would like to announce my candidacy for Horizon PTL. I have been actively contributing to Horizon since the Grizzly Summit and I've had the pleasure of serving as PTL for the last three cycles. In Kilo, we accelerated Horizon's adoption of AngularJS. We made a great deal of progress, with a near finished replacement of the launch instance workflow, The launch instance workflow was the number one usability issue in Horizon when tested. We've also created a framework to standardize and improve how filtering, pagination and data loading is managed in tables. The utilization of this framework begins in Liberty. We've worked to better incorporate UX design into our process. The UX team is now a part of the feature design process. In Liberty, we'll look to further formalize this workflow. Additionally, we've conducted several usability studies to obtain feedback on designs and information architecture from users and potential users. The results are helping guide design as we move forward. We will continue to test new and existing interfaces and designs. Over the past three cycles, interest in Horizon has grown dramatically, but as with most of OpenStack, we are feeling those growing pains. As a horizontal integration point, Horizon needs to adapt to handle the increasing breadth of services in OpenStack. In Juno and Kilo, we built and refined a plugin system for adding new content into Horizon. In Liberty, we'll see more services utilizing this mechanism and allow service teams to retain greater control of their Horizon content. In Liberty, Horizon needs to focus on existing efforts around improving usability, better support for large deployments and more useful administrative interfaces. We've set the stage to make significant strides in Liberty. I appreciate your consideration for the opportunity to continue enabling our tremendous team of contributors to make it happen. I'm excited by the progress we've made and the prospect of seeing several of our project's long term goals become reality in Liberty. Thanks, David __ 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] [Infra] Use of heat for CI of OpenStack
On 04/03/2015 01:08 PM, Joshua Harlow wrote: Monty Taylor wrote: On 04/03/2015 08:55 AM, Maish Saidel-Keesing wrote: I was wondering.. Is the OpenStack CI/CD Infra using Heat in any way? Do the commits trigger a new build of DevStack/OpenStack that is based on a Heat Template or just the provisioning of a regular instance and then deployment of code on top of that? Nope - we do not use heat - we use a program called nodepool: http://git.openstack.org/cgit/openstack-infra/nodepool/ Which uses the nova api to provision servers. These servers are currently registered as jenkins slaves so that the workload run on them is defined a s jenkins job. There are a few reasons we do not use heat for this - none of them I think of as negative against heat: - Our pool spans 4 regions of 2 public clouds. Heat runs in a cloud, the positioning is wrong - Our pool is predominantly single-machines that are used once - which means a heat template would add extra complexity for not much gain. - Our current system predates the existence of heat. It is also highly specific to the task at hand - namely, ensuring that there are always test nodes available. Can these things be fixed? Heat afaik isn't a frozen piece of sofware... It would be pretty neat to use the projects that we have that others are using if we could. Might be an interesting summit topic/idea? Honestly, I find it more neat that nodepool is a good example application of consuming the Nova API to build a custom workflow. I think assuming that the moment you do things with more than 1 machine you should be using Heat kind of misses the point of Nova having it's own API. We should be encouraging more applications out in the wild to use our APIs at all kinds of levels. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] PTL Candidacy
confirmed On 04/02/2015 04:31 PM, Morgan Fainberg wrote: Hello Everyone! It’s been an exciting development cycle (Kilo) and it is now time to start looking forward at Liberty and what that will hold. With that said, I’d like to ask for the community’s support to continue as the Keystone PTL for the Liberty release cycle. I came to the table last cycle with a general goal of driving towards stability and improvement on user experience[1]. For the most part the Keystone team has managed to improve on a number of the big outstanding issues: * Token Persistence issues (table bloat, etc), solved with non-persistent (Fernet) tokens. * Improvements on the Federated identity use-cases. * Hierarchical Multi-Tenancy (initial implementation) * Significant progress on Keystone V3-only deployment models (a lot of work in the Keystone Client and Keystone Middleware) * A good deal of technical debt paydown / cleanup This cycle I come back to say that I don’t want to shake things up too much. I think we have a successful team of developers, reviewers, bug-triagers, and operators collaborating to make Keystone a solid part of the OpenStack Ecosystem. I remain committed to enabling the contributors (of all walks) to be part of our community and achieve success. For the Liberty cycle I would like to see a continued focus on performance, user experience, deployer experience, and stability. What does this really mean for everyone contributing to Keystone? It means there are two clear sides for the Liberty cycle. New Feature Work: - I want to see the development community pick a solid 5 or so “new” features to land in Liberty and really hit those out of the park (focused development from the very beginning of the cycle). Generally speaking, it looks that the new feature list is lining up around providing support / significantly better experience for the other project(s) under the OpenStack tent. In short, I see Keystone new development being less about the “interesting thing Keystone can do” and more about “the great things Keystone can do for the other projects”. Non-Feature Work: - We have a lot of drivers/plugins, backends, all with their own rapidly moving interfaces that make it hard to know what to expect in the next release. It is time we sit down and commit to the interfaces for the backends, treat them as stable (just like the REST interface). A stable ABI for the Keystone backends/plugins goes a long way towards enabling our community to develop a rich set of backends/plugins for Identity, Assignment, Roles, Policy, etc. This is a further embracing of the “Big Tent” conversation; for example we can allow for constructive competition in how Keystone retrieves Identity from an Identity store (such as LDAP, AD, or SQL). Not all of the solutions need to be in the Keystone tree itself, but a developer can be assured that their driver isn’t going to need radical alterations between Liberty and the next release with this commitment to stable ABIs. Beyond the stable interface discussion, the other top “non-feature” priorities are having a fully realized functional test suite (that can be run against an arbitrary deployment of Keystone, with whichever backend/configuration is desired), a serious look at performance profiling and what we can do to solve the next level of scaling issues, the ability to deploy OpenStack without Keystone V2 enabled, and finally looking at the REST API itself so that we can identify how we can improve the end-user’s experience (the user who consumes the API itself) especially when it comes to interacting with deployments with different backend configurations. Some Concluding Thoughts: I’ll reiterate my conclusion from the last time I ran, as it still absolutely sums up my feelings: Above and beyond everything else, as PTL, I am looking to support the outstanding community of developers so that we can continue Keystone’s success. Without the dedication and hard work of everyone who has contributed to Keystone we would not be where we are today. I am extremely pleased with how far we’ve come and look forward to seeing the continued success as we move into the Liberty release cycle and beyond not just for Keystone but all of OpenStack. Cheers, Morgan Fainberg [1] http://lists.openstack.org/pipermail/openstack-dev/2014-September/046571.html __ 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: OpenPGP digital signature
Re: [openstack-dev] Problem about Juno Keystone Identity V3
On 04/03/2015 09:09 AM, Amy Zhang wrote: Hi guys, I have done switching Keystone Identity V2 to V3 in Icehouse and it works perfect. However, I use the same way to switch Keystone Identity V2 to V3 in Juno, it doesn't work. It give me the error: ERROR: openstack Internal Server Error (HTTP 500). What steps did you follow? Links? I traced back to the code, find the error comes from apache, but it doesn't make any sense that apache has problem, it might be some problem of keystone which lead to error of apache. Does any one have any idea of it? Thanks! -- Best regards, Amy (Yun Zhang) __ 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] [Infra] Use of heat for CI of OpenStack
Sean Dague wrote: On 04/03/2015 01:08 PM, Joshua Harlow wrote: Monty Taylor wrote: On 04/03/2015 08:55 AM, Maish Saidel-Keesing wrote: I was wondering.. Is the OpenStack CI/CD Infra using Heat in any way? Do the commits trigger a new build of DevStack/OpenStack that is based on a Heat Template or just the provisioning of a regular instance and then deployment of code on top of that? Nope - we do not use heat - we use a program called nodepool: http://git.openstack.org/cgit/openstack-infra/nodepool/ Which uses the nova api to provision servers. These servers are currently registered as jenkins slaves so that the workload run on them is defined a s jenkins job. There are a few reasons we do not use heat for this - none of them I think of as negative against heat: - Our pool spans 4 regions of 2 public clouds. Heat runs in a cloud, the positioning is wrong - Our pool is predominantly single-machines that are used once - which means a heat template would add extra complexity for not much gain. - Our current system predates the existence of heat. It is also highly specific to the task at hand - namely, ensuring that there are always test nodes available. Can these things be fixed? Heat afaik isn't a frozen piece of sofware... It would be pretty neat to use the projects that we have that others are using if we could. Might be an interesting summit topic/idea? Honestly, I find it more neat that nodepool is a good example application of consuming the Nova API to build a custom workflow. I think assuming that the moment you do things with more than 1 machine you should be using Heat kind of misses the point of Nova having it's own API. We should be encouraging more applications out in the wild to use our APIs at all kinds of levels. Sure, and I think that's great and is the right thing to do, but there are various levels of eating our own dogfood and it'd be nice to do that where appropriate. I know there is history here that I don't know about but the future is unwritten and it might be worthwhile to think about these kinds of things instead of just 'doing what we have always done, just because it has always been done'... -Sean __ 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] Containers and networking
This puts me in mind of a previous proposal, from the Neutron side of things. Specifically, I would look at Erik Moe's proposal for VM ports attached to multiple networks: https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms . I believe that you want logical ports hiding behind a conventional port (which that has); the logical ports attached to a variety of Neutron networks despite coming through the same VM interface (ditto); and an encap on the logical port with a segmentation ID (that uses exclusively VLANs, which probably suits here, though there's no particular reason why it has to be VLANs or why it couldn't be selectable). The original concept didn't require multiple ports attached to the same incoming subnetwork, but that's a comparatively minor adaptation. -- Ian. On 2 April 2015 at 11:35, Russell Bryant rbry...@redhat.com wrote: On 04/02/2015 01:45 PM, Kevin Benton wrote: +1. I added a suggestion for a container networking suggestion to the etherpad for neutron. It would be sad if the container solution built yet another overlay on top of the Neutron networks with yet another network management workflow. By the time the packets are traveling across the wires, it would be nice not to have double encapsulation from completely different systems. Yeah, that's what I like about this proposal. Most of the existing work in this space seems to result in double encapsulation. Now we just need to finish building it ... -- Russell Bryant __ 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] Problem about Juno Keystone Identity V3
Yeah. I'm curious too. Also, are you aware of any other issues in Juno with switching entirely over to v3? We'd like to have all of our service accounts in a non-default domain for kilo. With the nova+neutron bug fixed, thats the only one I know of preventing it. Thanks, Kevin From: Rich Megginson [rmegg...@redhat.com] Sent: Friday, April 03, 2015 12:54 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Problem about Juno Keystone Identity V3 On 04/03/2015 12:11 PM, Fox, Kevin M wrote: We've run into issues with nova+neutron and keystone v3 with Juno. Specifically this one: https://bugs.launchpad.net/nova/+bug/1424462 But there may be others that I don't know about. Yes, there are some problems with some components that don't use the keystone_authtoken section in their configs or otherwise can't use the latest python-keystonemiddleware. But I would like to know what steps worked to switch Keystone Identity from V2 to V3 in Icehouse that don't work for Juno. Thanks, Kevin From: Rich Megginson [rmegg...@redhat.commailto:rmegg...@redhat.com] Sent: Friday, April 03, 2015 10:52 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Problem about Juno Keystone Identity V3 On 04/03/2015 09:09 AM, Amy Zhang wrote: Hi guys, I have done switching Keystone Identity V2 to V3 in Icehouse and it works perfect. However, I use the same way to switch Keystone Identity V2 to V3 in Juno, it doesn't work. It give me the error: ERROR: openstack Internal Server Error (HTTP 500). What steps did you follow? Links? I traced back to the code, find the error comes from apache, but it doesn't make any sense that apache has problem, it might be some problem of keystone which lead to error of apache. Does any one have any idea of it? Thanks! -- Best regards, Amy (Yun Zhang) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribemailto: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:unsubscribemailto: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] Problem about Juno Keystone Identity V3
On 04/03/2015 12:11 PM, Fox, Kevin M wrote: We've run into issues with nova+neutron and keystone v3 with Juno. Specifically this one: https://bugs.launchpad.net/nova/+bug/1424462 But there may be others that I don't know about. Yes, there are some problems with some components that don't use the keystone_authtoken section in their configs or otherwise can't use the latest python-keystonemiddleware. But I would like to know what steps worked to switch Keystone Identity from V2 to V3 in Icehouse that don't work for Juno. Thanks, Kevin *From:* Rich Megginson [rmegg...@redhat.com] *Sent:* Friday, April 03, 2015 10:52 AM *To:* openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] Problem about Juno Keystone Identity V3 On 04/03/2015 09:09 AM, Amy Zhang wrote: Hi guys, I have done switching Keystone Identity V2 to V3 in Icehouse and it works perfect. However, I use the same way to switch Keystone Identity V2 to V3 in Juno, it doesn't work. It give me the error: ERROR: openstack Internal Server Error (HTTP 500). What steps did you follow? Links? I traced back to the code, find the error comes from apache, but it doesn't make any sense that apache has problem, it might be some problem of keystone which lead to error of apache. Does any one have any idea of it? Thanks! -- Best regards, Amy (Yun Zhang) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [barbican] Utilizing the KMIP plugin
Hello!
I am having some trouble with the kmip_plugin and would like some help.
When I make a call to barbican to store a secret it returns the following
error:
2015-04-03 12:33:17,279 - barbican.api.controllers - ERROR - Secret
creation failure seen - please contact site administrator.
Traceback (most recent call last):
File /home/swift/barbican/barbican/api/controllers/__init__.py, line
98, in handler
return fn(inst, *args, **kwargs)
File /home/swift/barbican/barbican/api/controllers/__init__.py, line
84, in enforcer
return fn(inst, *args, **kwargs)
File /home/swift/barbican/barbican/api/controllers/__init__.py, line
140, in content_types_enforcer
return fn(inst, *args, **kwargs)
File /home/swift/barbican/barbican/api/controllers/secrets.py, line
294, in on_post
transport_key_id=data.get('transport_key_id'))
File /home/swift/barbican/barbican/plugin/resources.py, line 101, in
store_secret
key_spec=key_spec, plugin_name=plugin_name)
File /home/swift/barbican/barbican/plugin/interface/secret_store.py,
line 477, in _check_plugins_configured
raise SecretStorePluginsNotConfigured()
SecretStorePluginsNotConfigured: No secret store plugins have been
configured
In the barbican-api.conf file I have set enabled_secretstore_plugins to
kmip_plugin.
I have also updated the kmip_plugin part of the file to point to the host
and port where my kmip Key Manager is running
with all the required credentials and ssl certs.
I also made sure the ssl requirements are set to permissions 400.
Is there something I am missing that is causing this problem?
Thank You!!
- Christopher Solis
Regards,
CHRIS SOLIS
Software Developer - Cloud Infrastructure Services Security
Phone: 1-512-286-6458 | Mobile:IBM
1-210-844-5913
E-mail: cnso...@us.ibm.com 11501 Burnet Rd
Austin, TX 78758-3400
United States
__
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] [scheduler] [gantt] Please stop using Gantt for discussing about Nova scheduler
Le 3 avr. 2015 19:27, Dugger, Donald D donald.d.dug...@intel.com a écrit : The goal is not `splitting for the sake of splitting'. The goal is to have a separate scheduler that is ultimately usable by other projects inside OpenStack. Currently Cinder has its own filter based scheduler (duplicating scheduling code in 2 places seems silly), Neutron will need scheduling services, there are multiple places where a common scheduling service would be beneficial. Agreed. Let's be clear : - Nova needs to reduce its tech debt for scheduling : call it n-sch effort - Nova needs to split its scheduler because it scales out development : call it n-sch split (TBD at Vancouver) - OpenStack needs a cross-project scheduler : call it Gantt All efforts are intersected but are separate. Please don't get me wrong : IMHO, all of them are useful. -Sylvain -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 -Original Message- From: Ed Leafe [mailto:e...@leafe.com] Sent: Friday, April 3, 2015 10:59 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] [scheduler] [gantt] Please stop using Gantt for discussing about Nova scheduler -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/03/2015 11:42 AM, Dugger, Donald D wrote: Yes the current effort is to clean up the scheduler interfaces but one of the main goals of that clean up is to make it possible to then split out the scheduler to a separate project. I don't want to lose focus on the ultimate goal of creating the split. I don't agree that the ultimate goal is splitting the scheduler. IMO, the goal is to create 1) a clean, robust interface along with 2) a scalable architecture. Those improvements will 1) allow the scheduler to be split cleanly, and 2) justify splitting it out. Splitting for the sake of splitting is pointless. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJVHsbeAAoJEKMgtcocwZqLdysQAIJ6nThjqgNgJu1hLW4n6MDY Db57k+37b5M5h6Z633jrXSTWCuqjIwUIW2G1+PQMsXq7FcWguAG7fxhVizE4s0h0 RhucmNQ1GWj6eFNfpSljC0WAdZEDhuXnPcxi2OyMwRr0j2lqYcJvPKBmuobS8Rbl xD9ciIlVELtHPm2dsj1HkB8TO7fgESjdv+I2QPU9C31ubp0CYlwSAPCdAhN9g+B0 WVCEnq+7ADn95G+/z77Wlx6s83KkCh89C+h2ivgGI4mHeWJskXT9lr9lsC342DO9 GoWvDvRF5H9/imx6Jh4avipH55YCZfZ9T+2eOPVoAYkXujPiX13tqM8UkBj7KCDx /FJNatC0aTDPYGMgOW329pGWkP9n2ceW1gMlyHpmMFJHCaAdmM+gqnjnarT1UECr 13yndy9axjubisZ71hdGgBi/Sy1FbG5+XVshWyAUgzoJZurDtg4RhhUdw8n0iQKd SuA3E9Z+PI6gTulp532JdHBVOpsG2P+9QOzLwBEnpSp8WmuU8h2EVMm6A3Zdrf+4 zIUL8lvpDwZ/0KBHSF6WptZspSXe/OwOKlQYO2geHkeARANv3Tv/h3HB/7SW1Bz0 8N5K2aDK/adzfzagrV0S3f201JoFC90JSXgA4dDdtHr8/oUj1kw3QoTACVrvPvYP ayW76hfM68cjJ3DyhXys =5h63 -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] Problem about Juno Keystone Identity V3
There may be some other lingering v2-only auth issues, but my guess is that the nova/neutron one is towards the end of the remaining ones. I'm looking at liberty as the release we finish any outstanding work to fully gate on v2 being disabled in a deployment. --Morgan Sent via mobile On Apr 3, 2015, at 15:24, Fox, Kevin M kevin@pnnl.gov wrote: Yeah. I'm curious too. Also, are you aware of any other issues in Juno with switching entirely over to v3? We'd like to have all of our service accounts in a non-default domain for kilo. With the nova+neutron bug fixed, thats the only one I know of preventing it. Thanks, Kevin From: Rich Megginson [rmegg...@redhat.com] Sent: Friday, April 03, 2015 12:54 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Problem about Juno Keystone Identity V3 On 04/03/2015 12:11 PM, Fox, Kevin M wrote: We've run into issues with nova+neutron and keystone v3 with Juno. Specifically this one: https://bugs.launchpad.net/nova/+bug/1424462 But there may be others that I don't know about. Yes, there are some problems with some components that don't use the keystone_authtoken section in their configs or otherwise can't use the latest python-keystonemiddleware. But I would like to know what steps worked to switch Keystone Identity from V2 to V3 in Icehouse that don't work for Juno. Thanks, Kevin From: Rich Megginson [rmegg...@redhat.com] Sent: Friday, April 03, 2015 10:52 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Problem about Juno Keystone Identity V3 On 04/03/2015 09:09 AM, Amy Zhang wrote: Hi guys, I have done switching Keystone Identity V2 to V3 in Icehouse and it works perfect. However, I use the same way to switch Keystone Identity V2 to V3 in Juno, it doesn't work. It give me the error: ERROR: openstack Internal Server Error (HTTP 500). What steps did you follow? Links? I traced back to the code, find the error comes from apache, but it doesn't make any sense that apache has problem, it might be some problem of keystone which lead to error of apache. Does any one have any idea of it? Thanks! -- Best regards, Amy (Yun Zhang) __ 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] [Manila] Nominate Clinton Knight for core team
Igor Malinovskiy imalinovskiy@... writes: +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@...?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev +1. Clinton's been giving good feedback on reviews and has been very active. We'll all have to improve our code coverage if he's core (not a bad thing) ;) __ 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] SQLite support (migrations, work-arounds, and more), is it worth it?
On Saturday 04 April 2015 03:55:59 Morgan Fainberg wrote: I am looking forward to the Liberty cycle and seeing the special casing we do for SQLite in our migrations (and elsewhere). My inclination is that we should (similar to the deprecation of eventlet) deprecate support for SQLite in Keystone. In Liberty we will have a full functional test suite that can (and will) be used to validate everything against much more real environments instead of in-process “eventlet-like” test-keystone-services; the “Restful test cases” will no longer be part of the standard unit tests (as they are functional testing). With this change I’m inclined to say SQLite (being the non-production usable DB) what it is we should look at dropping migration support for SQLite and the custom work-arounds. Most deployers and developers (as far as I know) use devstack and MySQL or Postgres to really suss out DB interactions. I am looking for feedback from the community on the general stance for SQLite, and more specifically the benefit (if any) of supporting it in Keystone. +1. Drop it and clean up tons of code used for support of sqlite only. Doing tests with mysql is as easy, as with sqlite (mysqladmin drop -f; mysqladmin create for reset), and using it by default will finally make people test their code on real rdbmses. -- С наилучшими пожеланиями, Boris __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?
I am looking forward to the Liberty cycle and seeing the special casing we do for SQLite in our migrations (and elsewhere). My inclination is that we should (similar to the deprecation of eventlet) deprecate support for SQLite in Keystone. In Liberty we will have a full functional test suite that can (and will) be used to validate everything against much more real environments instead of in-process “eventlet-like” test-keystone-services; the “Restful test cases” will no longer be part of the standard unit tests (as they are functional testing). With this change I’m inclined to say SQLite (being the non-production usable DB) what it is we should look at dropping migration support for SQLite and the custom work-arounds. Most deployers and developers (as far as I know) use devstack and MySQL or Postgres to really suss out DB interactions. I am looking for feedback from the community on the general stance for SQLite, and more specifically the benefit (if any) of supporting it in Keystone. -- Morgan Fainberg __ 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] [ovs-dev] [PATCH 8/8] [RFC] [neutron] ovn: Start work on design ocumentation.
On 04/01/2015 08:16 PM, Wang, Yalei wrote: Do we have plan to implement it in Liberity? I am really interest in and want to join it. Do you mean implement OVN and its Neutron support? If so, both efforts are well under way. We're aiming to have a first working demo by the Vancouver summit. The Neutron integration is in the stackforge/networking-ovn project. You can follow and participate in development of that project in gerrit [1]. Any discussion about it should happen on this mailing list. The development of OVN itself is happening in parallel. You can follow that via the ovs-dev mailing list [2]. The code is currently going into the 'ovn' branch of the 'ovs' git repo [3]. [1] https://review.openstack.org/#/q/project:stackforge/networking-ovn,n,z [2] http://mail.openvswitch.org/mailman/listinfo/dev [3] https://github.com/openvswitch/ovs/commits/ovn -- Russell Bryant __ 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] SQLite support (migrations, work-arounds, and more), is it worth it?
On 04/03/2015 08:55 PM, Morgan Fainberg wrote: I am looking forward to the Liberty cycle and seeing the special casing we do for SQLite in our migrations (and elsewhere). My inclination is that we should (similar to the deprecation of eventlet) deprecate support for SQLite in Keystone. In Liberty we will have a full functional test suite that can (and will) be used to validate everything against much more real environments instead of in-process “eventlet-like” test-keystone-services; the “Restful test cases” will no longer be part of the standard unit tests (as they are functional testing). With this change I’m inclined to say SQLite (being the non-production usable DB) what it is we should look at dropping migration support for SQLite and the custom work-arounds. Most deployers and developers (as far as I know) use devstack and MySQL or Postgres to really suss out DB interactions. I am looking for feedback from the community on the general stance for SQLite, and more specifically the benefit (if any) of supporting it in Keystone. Killstabstabstabdiekillkill (yes please) __ 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] [stable] [nova] FFE for libvirt: proper monitoring of live migration progress
Hello, I would like to get a FFE for patch https://review.openstack.org/#/c/162113/ which fixes an important bug (https://bugs.launchpad.net/nova/+bug/1414065) in the handling of the VM state during live migration. This patch fixes the libvirt monitoring of a live migration process, which is often needed for the use case of applying maintenance to a hypervisor. This patch changes the behavior of the live migration code from relying on the success of the migrateToURI call to actively monitoring the state of the libvirt domains to determine the status of the live migration. Regards, -- Billy Olsen __ 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] SQLite support (migrations, work-arounds, and more), is it worth it?
Fully support this. I, for one, volunteer to take on a lot of the work needed to clean up any our tests/environment to allow this to a happen. Hardly a month goes by without a fix having to be re-applied to our sql code to get round some problem that didn’t show up in original testing because SQLite is too promiscuous. Henry On 4 Apr 2015, at 01:55, Morgan Fainberg morgan.fainb...@gmail.com wrote: I am looking forward to the Liberty cycle and seeing the special casing we do for SQLite in our migrations (and elsewhere). My inclination is that we should (similar to the deprecation of eventlet) deprecate support for SQLite in Keystone. In Liberty we will have a full functional test suite that can (and will) be used to validate everything against much more real environments instead of in-process “eventlet-like” test-keystone-services; the “Restful test cases” will no longer be part of the standard unit tests (as they are functional testing). With this change I’m inclined to say SQLite (being the non-production usable DB) what it is we should look at dropping migration support for SQLite and the custom work-arounds. Most deployers and developers (as far as I know) use devstack and MySQL or Postgres to really suss out DB interactions. I am looking for feedback from the community on the general stance for SQLite, and more specifically the benefit (if any) of supporting it in Keystone. -- Morgan Fainberg __ 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] [ceilometer] Stepping down as PTL
Excerpts from Eoghan Glynn's message of 2015-04-02 10:18:22 -0400: Hi Folks, Just a quick note to say that I won't be running again for ceilometer PTL over the liberty cycle. I've taken on a new role internally that won't realistically allow me the time that the PTL role deserves. But y'all haven't seen the last of me, I'll be sticking around as a contributor, bandwidth allowing. I just wanted to take to opportunity to warmly thank everyone in the ceilometer community for their efforts over the past two cycles, and before. And I'm sure I'll be leaving the reins in good hands :) Cheers, Eoghan Thank you for serving as PTL, Eoghan. You've seen the team through some rough spots with aplomb. 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] [oslo] not running for PTL for liberty cycle
Many Many thanks for all the great work and leadership Doug! -- dims On Fri, Apr 3, 2015 at 8:50 AM, Doug Hellmann d...@doughellmann.com wrote: Team, I have decided not to run for PTL for Oslo for the next cycle. Serving as PTL for the last three releases has been a rewarding experience, and I think we’ve made some great strides together as a team. Now it’s time for me to step down and let someone else take the lead position. I am still committed to the mission, and I will be contributing to Oslo, but I do also want to work on some other projects that I won’t have time for if I stay in the PTL role. We have several good candidates for PTL on the team, and I expect us to have no trouble finding someone willing to step up and run. 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 -- 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] [oslo] not running for PTL for liberty cycle
On Fri, Apr 03 2015, Doug Hellmann wrote: Serving as PTL for the last three releases has been a rewarding experience, and I think we’ve made some great strides together as a team. Now it’s time for me to step down and let someone else take the lead position. I am still committed to the mission, and I will be contributing to Oslo, but I do also want to work on some other projects that I won’t have time for if I stay in the PTL role. We have several good candidates for PTL on the team, and I expect us to have no trouble finding someone willing to step up and run. Thanks for all the work you did so far, that was really great. :) -- Julien Danjou /* Free Software hacker http://julien.danjou.info */ signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] not running for PTL for liberty cycle
On 04/03/2015 02:50 PM, Doug Hellmann wrote: Team, I have decided not to run for PTL for Oslo for the next cycle. Serving as PTL for the last three releases has been a rewarding experience, and I think we’ve made some great strides together as a team. Now it’s time for me to step down and let someone else take the lead position. I am still committed to the mission, and I will be contributing to Oslo, but I do also want to work on some other projects that I won’t have time for if I stay in the PTL role. We have several good candidates for PTL on the team, and I expect us to have no trouble finding someone willing to step up and run. Thanks, Doug Doug, You've been simply awesome. Thanks for all the work! Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] Stepping down as PTL
On Thu, Apr 02 2015, Eoghan Glynn wrote: Just a quick note to say that I won't be running again for ceilometer PTL over the liberty cycle. I've taken on a new role internally that won't realistically allow me the time that the PTL role deserves. But y'all haven't seen the last of me, I'll be sticking around as a contributor, bandwidth allowing. I just wanted to take to opportunity to warmly thank everyone in the ceilometer community for their efforts over the past two cycles, and before. Thanks for your amazing work Eoghan! -- Julien Danjou -- Free Software hacker -- http://julien.danjou.info signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo][kolla] Investigating containerizing TripleO
On 4/1/15, 10:52 AM, Steven Hardy sha...@redhat.com wrote: Hi all, I've had various discussions about $subject, which have been re-started lately due to some excellent work going on in the Heat community (Rabi Mishra's work integrating SoftwareDeployments with various container launching tools [1]) tl;dr It's now possible to launch containers via heat SoftwareConfig resources in much the same way as we currently apply puppet manifests. I'm also aware there has been some great work going on around the kolla community making things work well with both docker-compose and atomic. I'm interested in discussing the next steps, which would appear to involve providing an optional way to deploy services via containers using TripleO. It seems that we can potentially build on the existing abstractions which were added for puppet integration, e.g: https://github.com/openstack/tripleo-heat-templates/blob/master/overcloud- resource-registry-puppet.yaml We could have an alternative resource-registry which maps in a different set of templates (which have the same parameter interfaces) which bootstrap a container host, and deploy each service in a container. This might look something like: https://github.com/hardys/heat-templates/blob/docker-host/hot/software-con fig/example-templates/example-docker-script.yaml This is just a simple example using docker run, but similar (probably much cleaner) approaches will be possible using atomic, docker-compose and other tools. For example, here's an example of how we might bootstrap a pristine atomic image, install a privileged container hosting the agents needed to talk to heat, then use that container to launch containers with the services: https://review.openstack.org/#/c/164572/6/hot/software-config/example-temp lates/example-pristine-atomic-docker-compose.yaml Similar example for docker-compose: https://github.com/openstack/heat-templates/blob/master/hot/software-confi g/example-templates/example-docker-compose-template.yaml There does seem to be a variety of tools folks prefer, but the pattern appears to be the same in most cases: 1. Provide input parameters to the template 2. Map parameters to an environment consumable by the container-launching tool 3. Run the tool and wait for success This is 100% accurate. If we can get this to work in a generic way, people could deploy with puppet in a traditional package based way or with containers in a shiny sparkly way :) It may be possible to abstract the details of the various tools inside the heat hooks, such that you could e.g choose the tool you want via a template parameter - e.g it should be possible to build the templates in a way which is somewhat tool-agnostic, if we get the heat interfaces refined correctly. What do people think, is this direction reasonable? I'm keen to figure out how we do a simple PoC which will bottom out the details, but it'd be great to get some feedback on the general approach. Thanks! Steve Sounds fantastic! I had a look at the templates, and I like Ryan¹s atomic template - perhaps he can post a link on this thread. Although it is Atomic specific, it is a really thin model of how to deploy OpenStack in containers. Of course tripleo will want to see support for more than just Atomic, but they are still worth a look. I¹m pleased to see some movement from the TripleO community on sorting out how to get these things integrated. That said, various off-list email threads have led me to believe people want to use Kolla with maestro-ng as well as Ansible. The core team agreed long ago to developmentally support all the relevant things, and tripleo seems like one good approach, so we are here to help. Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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] PTL Candidacy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/02/2015 06:50 PM, Jeremy Stanley wrote: Please vote for Morgan. Please refrain from distributing campaign literature, placing political advertising or soliciting votes within 25 meters of the polling place. ;) Or quoting the entirety of said campaign literature and adding one line at the bottom. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJVHrS/AAoJEKMgtcocwZqLQ6YP/0Q4miGpeztdQQ48vGdSBsGp VKEZ3jVaaxp0oxj3gE9HTu4gQHbsQtF5idgElq7QJCt4RiHoaQWF7C62V8bdx04m y22THw28IuWmY2fyqx6hPx/pHzWZbF0wn3Tj8Qrg+/TT30kBdB4PnDuaceZ9yH/N A946rHZxW//tVCHTCai5/phXbVuoEIZHY8wNYO9eP/lGrMX0sTmhdIerHwW63tjc JhVFd2DshduhX4BrNpwdds2jPzWyV7RDgzvxxvOBGBkAjqeUv/95SNJqd8IZLCWh I5xZ8c3TrSUtqJwndNQ/3w1fTfXPyALQwC+wazAIfnCQ39VM6uxZ/0hhdDMEN5lk yUFEFf/i6eKpy/cmaEKZC7ZjC2KoKn+/TJiqoVxxYb7/zo6ertDKbaSx3+foGpCX tJGdngmzJZUUs+uDxsimiOQOuvwoFw1HC+GSdn1cP9CmKN6HyLObKVh/+f/lxpSK 0YyHS6fjdMzkTWcwaCtSx0v6cEA+SbvrtuK4fBVL2YUq0a9TASv+wLFVR1NSDRtv WrKZz6qZ33PX1DRKHBXaLTQ116eVCh2J1SkbL3ztU6gyJHfqCGm6RkTmYsDFijAt RK2QOrAm7E9iN05RpiHQbkNa+vT9kJT3nl0dNniBptI2msw8QI4BTQnej/wUbG8O DOIeMLrLNgDd51CCGjUN =fsNb -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] [oslo] not running for PTL for liberty cycle
+100 to that! Flavio Percoco wrote: On 03/04/15 08:50 -0400, Doug Hellmann wrote: Team, I have decided not to run for PTL for Oslo for the next cycle. Serving as PTL for the last three releases has been a rewarding experience, and I think we’ve made some great strides together as a team. Now it’s time for me to step down and let someone else take the lead position. I am still committed to the mission, and I will be contributing to Oslo, but I do also want to work on some other projects that I won’t have time for if I stay in the PTL role. We have several good candidates for PTL on the team, and I expect us to have no trouble finding someone willing to step up and run. FWIW, I believe you did an *AMAZING* job as Oslo PTL. It was an honor to have you in that position. Thanks for your hard work. Flavio __ 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
