Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting
Hi Miguel, Thank you for leading this. On Tue, Apr 7, 2015 at 8:45 AM, Miguel Ángel Ajo majop...@redhat.com wrote: On Tuesday, 7 de April de 2015 at 3:14, Kyle Mestery wrote: On Mon, Apr 6, 2015 at 6:04 PM, Salvatore Orlando sorla...@nicira.com wrote: On 7 April 2015 at 00:33, Armando M. arma...@gmail.com wrote: On 6 April 2015 at 08:56, Miguel Ángel Ajo majop...@redhat.com wrote: I’d like to co-organized a QoS weekly meeting with Sean M. Collins, In the last few years, the interest for QoS support has increased, Sean has been leading this effort [1] and we believe we should get into a consensus about how to model an extension to let vendor plugins implement QoS capabilities on network ports and tenant networks, and how to extend agents, and the reference implementation others [2] As you surely know, so far every attempt to achieve a consensus has failed in a pretty miserable way. This mostly because QoS can be interpreted in a lot of different ways, both from the conceptual and practical perspective. Yes, I’m fully aware of it, it was also a new feature, so it was out of scope for Kilo. It is important in my opinion to clearly define the goals first. For instance a simple extensions for bandwidth limiting could be a reasonable target for the Liberty release. I quite agree here, but IMHO, as you said it’s a quite open field (limiting, guaranteeing, marking, traffic shaping..), we should do our best in trying to define a model allowing us to build that up in the future without huge changes, on the API side I guess micro versioning is going to help in the API evolution. Also, at some point, we should/could need to involve the nova folks, for example, to define port flavors that can be associated to nova instance flavors, providing them 1) different types of network port speeds/guarantees/priorities, 2) being able to schedule instance/ports in coordination to be able to met specified guarantees. yes, complexity can sky rocket fast, Moving things such as ECN into future works is the right thing to do in my opinion. Attempting to define a flexible framework that can deal with advanced QoS policies specification is a laudable effort, but I am a bit skeptical about its feasibility. ++, I think focusing on perhaps bandwidth limiting may make a lot of sense Yes, I believe we should look into the future , but at the same pick our very first feature (or a very simple set of them) for L, stick to it, and try to make a design that can be extended. +1 As per discussion we’ve had during the last few months [3], I believe we should start simple, but prepare a model allowing future extendibility, to allow for example specific traffic rules (per port, per IP, etc..), congestion notification support [4], … Simple in my mind is even more extreme then what you're proposing here... I'd start with bare APIs for specifying bandwidth limiting, and then phase them out once this framework is in place. Also note that this kind of design bears some overlap with the flavor framework which is probably going to be another goal for Liberty. Indeed, and the flavor framework is something I'm hoping we can land by Liberty-1 (yes, I just said Liberty-1). Yes it’s something I looked at, I must admit I wasn’t able to see it work together (It doesn’t mean it doesn’t play well, but most probably I was silly enough not to see it :) ), I didn’t want to distract attention from the Kilo cycle focus making questions, so it should be a good thing to talk about during the first meetings. Who are the flavor fathers/mothers? ;) Morever, consider using common tools such as the specs repo to share and discuss design documents. Also a good idea. Yes, that was the plan now, we didn’t use it before to avoid creating unnecessary noise during this cycle. It’s the first time I’m trying to organize an openstack/neutron meeting, so, I don’t know what’s the best way to do it, or find the best timeslot. I guess interested people may have a saying, so I’ve looped anybody I know is interested in the CC of this mail. I think that's a good idea. Incidentally I was speaking with Sean regarding Summit session [1], and we were hoping we could get some folks together either prior or during the summit, to try and get some momentum going behind this initiative, once again. Very interesting [1]!, nice to see we start to have a bunch of people with an interest in QoS. I think is a good idea as well. I was thinking that perhaps it might be a good idea to grab a design summit session as well (surely not a fishbowl one as they're totally unfit for this purpose). However, it might be good to achieve some sort of consensus before the summit, as as we know fairly well now the summit is probably the worst place where consensus can be achieved! And finally, agreed here as well. Yes, a bit of preliminary discussion, and a
Re: [openstack-dev] [Mistral] Upgrading to YAQL 1.0
Well, we’ve been ready to switch to YAQL-1.0 for a couple of months. We researched it, figured out how our integration would change etc. It’s pretty easy to do from our side. So let’s wait for the official YAQL-1.0.X release on pypi. Renat Akhmerov @ Mirantis Inc. On 07 Apr 2015, at 00:56, Stan Lagun sla...@mirantis.com wrote: The plan was to integrate YAQL 1.0 into Murano so that we could say it is battle-proven, remove beta from version and release on PyPI. And then probably release v1.0.1 that is YAQL with documentation :) Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis mailto:sla...@mirantis.com On Mon, Apr 6, 2015 at 9:44 PM, Dmitri Zimine dzim...@stackstorm.com mailto:dzim...@stackstorm.com wrote: Renat, following up on the IRC meeting: I recalled one more item, and registered a blueprint - https://blueprints.launchpad.net/mistral/+spec/yaql-v1-0 https://blueprints.launchpad.net/mistral/+spec/yaql-v1-0I think it’s good timing to do it in Kilo if YAQL 1.0 is announced; so I propose it for Kilo-rc1; One question is when YAQL 1.0 is going to move to Pypi? we can get it from github link for some time but ideally should use pypi. Alex, Stan, what’s the plan? DZ. __ OpenStack Development Mailing 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] [Mistral] Propose Winson Chan m4dcoder for core team
+1 with my both hands. Winson has been working on Mistral for about a year, was actively participating in the very first workflow engine version (what we called PoC) and keeps bringing his experience and excellent engineering skills to the project. Thanks Winson for your passionate work! Renat Akhmerov @ Mirantis Inc. On 07 Apr 2015, at 03:04, Dmitri Zimine dzim...@stackstorm.com wrote: Hi folks, I’d like to propose Winson Chan (m4dcoder) to become Mistral core team member. Winson brings unique mix of field experience implementing Mistral workflows in user environments, and solid development skills. He has been contributing to Mistral since Mar 2014. Winson did a 23 commits - a number of them are non-trivial, like moving RPC to oslo-messaging, or introducing environments, or making full validation. He has submitted 14 blueprints and detailed design proposals, contributing to design and directions. He found, reported, and fixed bugs. He is becoming more active on the review board (would encourage to do more). I am +1 for m4dcoder as a core team member. DZ. __ OpenStack Development Mailing 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] [docs] [End User Guide] [Keystone] keyring support for python-keystoneclient and python-openstackclient
Good day to everyone! My name is Olena, I am new in OpenStack (working as a tech writer). And I'm stuck on a bug https://launchpad.net/bugs/1419990 (patch https://review.openstack.org/#/c/163503/). I have 2 questions, please: Does the page http://docs.openstack.org/user-guide/content/cli_openrc.html contain info about python-keystoneclient only, or both python-keystoneclient and python-openstackclient? And should we remove the keyring support part here (because it was removed from python-openstackclient), or do some re-wording (because it is still left in python-keystoneclient)? (Here is a patch saying that keyring is still used by keystoneclient: https://review.openstack.org/#/c/107719/ ) Your help would be really appreciated. Best regards, Olena -- Best regards, Olena Logvinova, Technical Writer | Mirantis, Kharkiv | 38, Lenin av., Kharkiv ologvin...@mirantis.com | +380950903196 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint
Kyle Mestery wrote: I know we're not even at the Liberty Design Summit in Vancouver yet, but I wanted to take this time to announce the Neutron mid-cycle coding sprint for Liberty. HP has been gracious enough to offer to host at it's Fort Collins, CO offices. The dates are set for June 24-26, this is Wednesday-Friday. I've got additional information on the etherpad [1]. Could you announce it at: https://wiki.openstack.org/wiki/Sprints Feel free to create a Liberty section and deprecate old entries :) Thanks in advance, -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] PEP8 issues in Fuel-Web repo
This is also relevant for python-fuelclient. 6 квіт. 2015 о 12:27 Nikolay Markov nmar...@mirantis.com написав(ла): Hello everyone, I know this is really low priority and so on, but here is this bug about moving to the newest version of hacking package: https://bugs.launchpad.net/fuel/+bug/1410810 https://bugs.launchpad.net/fuel/+bug/1410810 . And here is the log after all pep8 linters and checks: https://fuel-jenkins.mirantis.com/job/verify-fuel-web/7063/consoleFull https://fuel-jenkins.mirantis.com/job/verify-fuel-web/7063/consoleFull Let's keep up with the modern guidelines and fix styling in our code according to new requirements. -- Best regards, Nick Markov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Developer survey questions
To the extent that it's useful to those suggesting the questions, it feels to me like this could be an ongoing resource rather than a one-off survey.Hence, perhaps a web page that all OpenStack members should occasionally review and update for themselves; rather than a one time mailing.From: Dean TroyerSent: Tuesday, 7 April 2015 04:56To: OpenStack Development Mailing List (not for usage questions)Reply To: OpenStack Development Mailing List (not for usage questions)Subject: Re: [openstack-dev] Developer survey questionsOn Mon, Apr 6, 2015 at 9:07 PM, Robert Collins robe...@robertcollins.net wrote:If you have any questions you'd like answered, please mail them to me (direct, or in reply to this) by the end of this week.I would love to learn a bit about how DevStack is used outside the gate:* Do you use DevStack as part of your everyday workflow?* If so, on what distribution(s)?* Do you run a non-default configuration WRT system services? ie, qpid or zmq, or psql* Do you run a gate-like environment using devstack-gate or something like it?* Do you regularly run a forked/branched DevStack* Do you run Grenade as part of your local workflow?I think it would be interesting to also ask about some of the other tools developed in our community, like gertty. Knowing the usefulness and adoption of these tools can help justify (or not) ongoing work in this area.dt-- Dean Troyerdtro...@gmail.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] not running for PTL for liberty cycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. Oslo project did an enormous progress because of your leadership. Thanks for taking the role really seriously for 3 cycles and empowering the team to get where we are now. And good luck with your other planned projects. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVI6BCAAoJEC5aWaUY1u57GsMH/jw8g5doXnVR6NRF4MZxHd8M xbCyV6NGhB54QtVqEkjPOGZYL0JwTT+I38+F6KAxDVcxQxA8FNORyRChJ/8PBpdb RpCdNgqmEAxemd7EtF4EV2qPfMQeFBRg9k61Em/mkFiLwx9Y5+ExUD4DU+8j2A/k Dgnf46CAFpaOnL+zdd+Tvss2WZVVVQuy4oYuEXXekb3JtYaoRr/KL5eaWklUmzJM 0F7b5j9+WcLBEEpJhi0I2sdFOK2Q1WnOcPHxxP5NJFGQdap2cIUXXXv4q5uEqkmb TEemQpyticqsH/5oiQyNbjOHxxdRn+zBcU+mSo0iY5oG3mkwIC0lWDd2UjkNHEA= =GXLo -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Heat] Overcloud software updates and ResourceGroups
On Thu, Apr 02, 2015 at 06:31:39PM -0400, Zane Bitter 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.
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 wonder if this is an opportunity to look at how we converge
AutoScalingGroup and ResourceGroup in Heat?
It seems like the main barrier to transparent (non destructive)
substitution of
AutoScalingGroup for ResourceGroup is the resource naming (e.g it's a short
UUID vs an index derived name) - could we add a property to
AutoScalingGroup which allowed optionally to use index based naming, such
that switching from ResourceGroup to ASG in a stack-update wouldn't replace
all the group members?
Another possible fudge if moving to ASG is impractical could be to use the
index in the script applying the update, such that an offset is introduced
between any updates which may cause service interruption (I know it's a
kludge, but e.g sleeping for a time derived from the group index before
doing the update would be an ugly-but-simple interim workaround for the
all updated at once problem you describe).
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
[openstack-dev] [Zaqar] PTL Candidacy
Greetings, You read it right, you've not burned out yet - I probably will. Here's a crazy idea, what if I run for 2 PTL positions on the projects I've been putting my focus on lately? Hopefully, by sending this out now, I'll be able to answer all your questions in time before the candidacy period closes. Before you jump out of your chair, pull your hair off and start asking: Is that even possible? Let me tell you that, as far as I can tell by reading our governance repo[0], it seems to be entirely legal. If you think it is not, please do let me know. Now, to my candidacy. During the Juno development cycle, I had the pleasure to be Zaqar's PTL. During this cycle, we managed to kick of complete - at least in an experimental version - some exciting features and we've also kicked off others - you can read more about that here[1]. We did that with a small team of old and new contributors, if it doesn't seem much to you, I'd love to invite you to our team and help us out. :D That said, I think our most important goal during Juno was incorporating the feedback we got from the community, after our last incubation attempt, in a way that doesn't compromise the project's goals but still brings in way more flexibility to the project. This will allow for the community (Zaqar's and OpenStack's) to finally adopt the project wherever it might be needed. Based on the above results and the fact that I believe the community hasn't seen enough (anything) of Zaqar yet, I'd like to throw my hat out there to be Zaqar's PTL for another cycle. Here are some things that I'd like us to do during this cycle: 1. Spread the word and improve our interaction with the overall community. We've spent lot of time heads down coding new features and working out the best way to deliver this project. I believe it's time to throw it out there and let it crash (if you know what I mean). 2. Restore/Improve our community activities by improving our communications through the openstack mailing list, restoring our weekly meetings and contributing back to other projects. 3. Keep improving our deployment story/tools. We've a draft of a puppet manifest that we need to complete, we've devstack support but we ought to bring it into our code base and extend it with other features that have been developed. 4. Keep our amazing mentoring story alive by helping new mentees to integrate with OpenStack, open source and obviously, Zaqar. Something this team should be proud of is that it's mentored new contributors since it was created. The above and more, I'd be honored to do together with the rest of the team. Now, to the obvious natural question: How will I be the PTL of 2 projects and get to the end of the cycle? Well, this definitely will require some changes from my side and my current focus that you'll see happen if I have the honor to be elected for both projects. Will I be burned out at the end of the cycle? Probably, but that's a price I'm willing to pay for these 2 projects and more importantly for OpenStack because I truly believe these projects play (or will play in the case of Zaqar) and important role in our ecosystem. In addition to the above, I must say that, thankfully enough, Zaqar is still not such a time consuming project from a PTL perspective and it's entirely feasible to be the PTL of these 2 projects and still do a good job - last famous words. In all seriousness, I'd be honored to serve for both projects and I hope you'll join me in this experiment. [0] https://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst [1] http://lists.openstack.org/pipermail/openstack-dev/2015-April/060446.html Cheers, Flavio -- @flaper87 Flavio Percoco pgp0rS0RRS7AX.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] Skipping Cross-Project meeting today?
Hi! The agenda for the cross-project meeting is currently empty: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting Unless someone has something to discuss (and adds it to the agenda docket), I propose we skip this one and focus on fixing release -critical bugs to issue a RC1 in the coming days :) Cheers, -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] Upgrading to YAQL 1.0
Hi Renat Dmitry Today we released YAQL 1.0.0b2 and release is available on PyPI, I think it's better to start migration to YAQL 1.0.0 right now, we don't expect any major changes, only small bug-fixes that should not affect your integration. And we will release 1.0.0 before end of Kilo cycle. On Tue, Apr 7, 2015 at 11:50 AM, Renat Akhmerov rakhme...@mirantis.com wrote: Well, we’ve been ready to switch to YAQL-1.0 for a couple of months. We researched it, figured out how our integration would change etc. It’s pretty easy to do from our side. So let’s wait for the official YAQL-1.0.X release on pypi. Renat Akhmerov @ Mirantis Inc. On 07 Apr 2015, at 00:56, Stan Lagun sla...@mirantis.com wrote: The plan was to integrate YAQL 1.0 into Murano so that we could say it is battle-proven, remove beta from version and release on PyPI. And then probably release v1.0.1 that is YAQL with documentation :) Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis On Mon, Apr 6, 2015 at 9:44 PM, Dmitri Zimine dzim...@stackstorm.com wrote: Renat, following up on the IRC meeting: I recalled one more item, and registered a blueprint - https://blueprints.launchpad.net/mistral/+spec/yaql-v1-0I think it’s good timing to do it in Kilo if YAQL 1.0 is announced; so I propose it for Kilo-rc1; One question is when YAQL 1.0 is going to move to Pypi? we can get it from github link for some time but ideally should use pypi. Alex, Stan, what’s the plan? DZ. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com __ OpenStack Development Mailing 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] How are vcpu's, ram mapped with an instance
Hi Folks, When we boot an instance and assign a flavor to it, how are the vcpu's, ram given to the instance. Actually the question is this while creating an instance we must be assigning it some Vcpu's according to the flavor we gave to the instance. So where are these Vcpu's placed and how are they mapped with an instance. Suppose I want to add some more Vcpu's to my VM at runtime without changing my flavor to a bigger one, can I do it ? -- Thanks and Regards Abhishek Talwar Employee ID : 770072 Assistant System Engineer Tata Consultancy Services,Gurgaon India Contact Details : +918377882003 =-=-= 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] [Mistral] Propose Winson Chan m4dcoder for core team
It would be good to see Winson as the core contributor in Mistral. +1 for Winson! On Tue, Apr 7, 2015 at 11:53 AM, Renat Akhmerov rakhme...@mirantis.com wrote: +1 with my both hands. Winson has been working on Mistral for about a year, was actively participating in the very first workflow engine version (what we called PoC) and keeps bringing his experience and excellent engineering skills to the project. Thanks Winson for your passionate work! Renat Akhmerov @ Mirantis Inc. On 07 Apr 2015, at 03:04, Dmitri Zimine dzim...@stackstorm.com wrote: Hi folks, I’d like to propose Winson Chan (m4dcoder) to become Mistral core team member. Winson brings unique mix of field experience implementing Mistral workflows in user environments, and solid development skills. He has been contributing to Mistral since Mar 2014. Winson did a 23 commits - a number of them are non-trivial, like moving RPC to oslo-messaging, or introducing environments, or making full validation. He has submitted 14 blueprints and detailed design proposals, contributing to design and directions. He found, reported, and fixed bugs. He is becoming more active on the review board (would encourage to do more). I am +1 for m4dcoder as a core team member. DZ. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Regards, Nikolay __ OpenStack Development Mailing 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] [Mistral] Propose Winson Chan m4dcoder for core team
Although I have jumpped into Mistral just for a short time, but really appreciate Winson's vision about my patches, and his work is of great value to Mistral. I'm not in the core team of Mistral, but really hope to see Winson as a core member to bring more to Mistral. On Tue, Apr 7, 2015 at 5:08 PM, Nikolay Makhotkin nmakhot...@mirantis.com wrote: It would be good to see Winson as the core contributor in Mistral. +1 for Winson! On Tue, Apr 7, 2015 at 11:53 AM, Renat Akhmerov rakhme...@mirantis.com wrote: +1 with my both hands. Winson has been working on Mistral for about a year, was actively participating in the very first workflow engine version (what we called PoC) and keeps bringing his experience and excellent engineering skills to the project. Thanks Winson for your passionate work! Renat Akhmerov @ Mirantis Inc. On 07 Apr 2015, at 03:04, Dmitri Zimine dzim...@stackstorm.com wrote: Hi folks, I’d like to propose Winson Chan (m4dcoder) to become Mistral core team member. Winson brings unique mix of field experience implementing Mistral workflows in user environments, and solid development skills. He has been contributing to Mistral since Mar 2014. Winson did a 23 commits - a number of them are non-trivial, like moving RPC to oslo-messaging, or introducing environments, or making full validation. He has submitted 14 blueprints and detailed design proposals, contributing to design and directions. He found, reported, and fixed bugs. He is becoming more active on the review board (would encourage to do more). I am +1 for m4dcoder as a core team member. DZ. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Regards, Nikolay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards! --- Lingxian Kong __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] [RFC/FFE] Finishing state machine work for Kilo
On 04/06/2015 06:53 AM, Ramakrishnan G wrote: +1 from me. Since we don't have ENROLL state as per the state machine, I think it should be MANAGEABLE when we enroll a node. At least, it can also prevent nodes getting into a ready state even before an operator getting hands on it. One comment on #2. Before we make a new client release with v1.6, shouldn't the behaviour of the 0.x.x python-ironicclient be that, newly enroll nodes have provision_state as NOSTATE again instead of AVAILABLE ? We no longer have NOSTATE. What people see as NOSTATE is actually AVAILABLE being mapped to None if version 1.1. So the only way to avoid it is to default to 1.0, which will make it harder and less intuitive to access new features. On Fri, Apr 3, 2015 at 1:59 PM, Dmitry Tantsur dtant...@redhat.com mailto:dtant...@redhat.com wrote: 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-request@lists.__openstack.org?subject:__unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting
Hi Miguel, I am interested to join this meeting. I assume that CC of this mail are from different time zones.Please provide time slot with common time zone. With Best Regards Raghunath Dudyala Tata Consultancy Services Limited Mailto: raghunat...@tcs.com Website: http://www.tcs.com Experience certainty. IT Services Business Solutions Consulting -Miguel Ángel Ajo majop...@redhat.com wrote: - To: openstack-dev@lists.openstack.org From: Miguel Ángel Ajo majop...@redhat.com Date: 04/06/2015 09:26PM Cc: Kyle Mestery mest...@mestery.com, Sean M. Collins s...@coreitpro.com, irenab@gmail.com irenab@gmail.com, Suresh Balineni sbalin...@juniper.net, Raghunath D raghunat...@tcs.com, Tal Anker anker...@mellanox.com, livnat Peer lp...@redhat.com, Nir Yechiel nyech...@redhat.com, Vikram Choudhary vikram.choudh...@huawei.com, Kalyankumar Asangi kaly...@huawei.com, Dhruv Dhody dhruv.dh...@huawei.com, Dongfeng (C) albert.dongf...@huawei.com Subject: [neutron] [QoS] QoS weekly meeting I#8217;d like to co-organized a QoS weekly meeting with Sean M. Collins, In the last few years, the interest for QoS support has increased, Sean has been leading this effort [1] and we believe we should get into a consensus about how to model an extension to let vendor plugins implement QoS capabilities on network ports and tenant networks, and how to extend agents, and the reference implementation others [2] As per discussion we#8217;ve had during the last few months [3], I believe we should start simple, but prepare a model allowing future extendibility, to allow for example specific traffic rules (per port, per IP, etc..), congestion notification support [4], #8230; It#8217;s the first time I#8217;m trying to organize an openstack/neutron meeting, so, I don#8217;t know what#8217;s the best way to do it, or find the best timeslot. I guess interested people may have a saying, so I#8217;ve looped anybody I know is interested in the CC of this mail. Miguel Ángel Ajo [1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api [2] https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing [3] https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231 [4] https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification =-=-= 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] [Ironic] [RFC/FFE] Finishing state machine work for Kilo
On 04/06/2015 05:15 PM, Devananda van der Veen wrote: Hi! The situation you describe is the same that concerned me with regards to stable/juno compatibility. As soon as the client library started passing a version header by default, it exposed Kilo changes to all users. Anyone testing from trunk would have experienced that when 99ab landed. I just tagged release 0.5.0 of python-ironicclient which includes that change. It therefor passes X-OpenStack-Ironic-API-Version == 1.6 (this is your #2 below). 3rd party apps that pin to 0.5 release of python-ironicclient will continue to get juno-esque states. I'll announce this in a separate thread shortly. As far as whether to default newly created nodes to AVAILABLE, MANAGEABLE, or ENROLLED - yea, we didn't finish the state machine work this cycle - I'd rather not introduce a change to the default state now, then change it again in a few months, leading to further confusion. Yeah, right. As far as your #3, you raise a good point. Passing the version header by default is a potentially incompatible change with prior versions of the client. While the CLI and library API didn't change in an incompatible way, they expose the client to new server behavior... perhaps this should be our 1.0 release of python-ironicclient? Or perhaps, since it's still in the 0.x range, we should wait until we know the state machine work is done and *then* tag a 1.0 release of the client? ++ for waiting. If we tag it 1.0 right now, we'll have to make 2.0 in L. And yeah, each time we pass new version of header, we'll have to consider whether to bump major version, though I hope we won't introduce major changes too often :) But we do have to release 1.0.0 next cycle, it looks a bit weird that our feature complete client has 0.x version. Re: documenting this, besides release notes, emails, and changelogs - what would you like to see? I'm happy to put the release notes for the client into our developer docs, along with a page on upgrading from juno to kilo that we need to write. Stating the situation in the upgrade docs is the must IMO. While client is in 0.x range and we're free to break it occasionally, people still don't expect us to :) I think we also need to put information about the header and how it affects people in ironicclient docs introduction. -Deva On Fri, Apr 3, 2015 at 1:31 AM Dmitry Tantsur dtant...@redhat.com mailto:dtant...@redhat.com wrote: 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-request@lists.__openstack.org?subject:__unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://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] [all] Issues with pip 6.1
Hi,
I tried to install a fresh DevStack but it doesn't work because of the new
release of pip: pip 6.1 (probably released today,
https://pip.pypa.io/en/stable/news.html still says 6.1.0 (unreleased)...).
(1) update.py of openstack/requirements uses req.InstallRequirement.url
attribute, but this attribute is gone (replaced with
req.InstallRequirement.link.url)
= see https://bugs.launchpad.net/tempest/+bug/1440984
(2) it's not more possible to install argparse on Python 2.7, pip install
argparse simply write Skipping requirement: argparse because argparse is a
stdlib package. It makes sense, but different OpenStack components *require*
argparse. I mean, pkg_resources raises an ImportError if argparse is not
installed with pip. Example:
2015-04-07 10:08:34.084 | + /usr/bin/keystone-manage db_sync
2015-04-07 10:08:34.239 | Traceback (most recent call last):
2015-04-07 10:08:34.239 | File /usr/bin/keystone-manage, line 4, in module
2015-04-07 10:08:34.239 |
__import__('pkg_resources').require('keystone==2015.1.dev143')
2015-04-07 10:08:34.239 | File
/usr/lib/python2.7/site-packages/pkg_resources/__init__.py, line 3057, in
module
2015-04-07 10:08:34.239 | working_set = WorkingSet._build_master()
2015-04-07 10:08:34.240 | File
/usr/lib/python2.7/site-packages/pkg_resources/__init__.py, line 639, in
_build_master
2015-04-07 10:08:34.240 | ws.require(__requires__)
2015-04-07 10:08:34.240 | File
/usr/lib/python2.7/site-packages/pkg_resources/__init__.py, line 940, in
require
2015-04-07 10:08:34.240 | needed =
self.resolve(parse_requirements(requirements))
2015-04-07 10:08:34.240 | File
/usr/lib/python2.7/site-packages/pkg_resources/__init__.py, line 827, in
resolve
2015-04-07 10:08:34.240 | raise DistributionNotFound(req, requirers)
2015-04-07 10:08:34.241 | pkg_resources.DistributionNotFound: The 'argparse'
distribution was not found and is required by oslo.config,
python-keystoneclient, pysaml2
2015-04-07 10:08:34.246 | + exit_trap
Workaround: install pip 6.0.8, run pip install argparse
= I just opened https://bugs.launchpad.net/keystone/+bug/1441083
Victor
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [docs][rally] Rally template tasks in a nutshell
Hi stackers, as you might remember, we have recently added a nice feature to Rally which is the support of *task templates*. Rally uses the template syntax based on *Jinja2*, and thus makes it simple to parameterize your benchmark task files. Our step-by-step tutorial has just been updated with a new lesson devoted to task templates in Rally: http://rally.readthedocs.org/en/latest/tutorial/step_8_task_templates.html You are welcome to read it through (it is fairly short) and ask any questions. Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov __ OpenStack Development Mailing 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] [Mistral] Upgrading to YAQL 1.0
Ok, sounds good! So if there aren’t any objections we can start doing it asap. Renat Akhmerov @ Mirantis Inc. On 07 Apr 2015, at 16:00, Serg Melikyan smelik...@mirantis.com wrote: Hi Renat Dmitry Today we released YAQL 1.0.0b2 and release is available on PyPI, I think it's better to start migration to YAQL 1.0.0 right now, we don't expect any major changes, only small bug-fixes that should not affect your integration. And we will release 1.0.0 before end of Kilo cycle. On Tue, Apr 7, 2015 at 11:50 AM, Renat Akhmerov rakhme...@mirantis.com wrote: Well, we’ve been ready to switch to YAQL-1.0 for a couple of months. We researched it, figured out how our integration would change etc. It’s pretty easy to do from our side. So let’s wait for the official YAQL-1.0.X release on pypi. Renat Akhmerov @ Mirantis Inc. On 07 Apr 2015, at 00:56, Stan Lagun sla...@mirantis.com wrote: The plan was to integrate YAQL 1.0 into Murano so that we could say it is battle-proven, remove beta from version and release on PyPI. And then probably release v1.0.1 that is YAQL with documentation :) Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis On Mon, Apr 6, 2015 at 9:44 PM, Dmitri Zimine dzim...@stackstorm.com wrote: Renat, following up on the IRC meeting: I recalled one more item, and registered a blueprint - https://blueprints.launchpad.net/mistral/+spec/yaql-v1-0I think it’s good timing to do it in Kilo if YAQL 1.0 is announced; so I propose it for Kilo-rc1; One question is when YAQL 1.0 is going to move to Pypi? we can get it from github link for some time but ideally should use pypi. Alex, Stan, what’s the plan? DZ. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com __ OpenStack Development Mailing 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] PTL Candidacy
+1 I am very happy to work with you:) At 2015-04-07 10:50:23, Steve Baker sba...@redhat.com wrote: I'd like to announce my candidacy for the Heat PTL in Liberty. As I was the PTL during Icehouse, this will be Heat's first rerun PTL under our convention for rotating leaders. Even if elected I would hope that we continue to find Heat PTL new-blood for future cycles. Towards the end of the Kilo cycle we started to get some momentum on landing the changes required for the Convergence effort. The aim will be to get much of the first-phase features landing early in Liberty, and spend the rest of the cycle focusing on convergence features which provide the most user benefit. There are important maintenance tasks in the Liberty cycle which will need continued effort, including functional/integration testing, content for the template-writer's guide, and general usability improvements. It seems that our merge throughput would be higher if our existing review attention were more coordinated. Nova has had some success with priorities, and Swift works well with a PTL curated etherpad of suggested reviews. I'd like to discuss the options with other heat cores, and am currently suggesting something like the Swift approach. As the Big Tent process continues to mature I'd like to ensure that Heat is well positioned to qualify for the appropriate tags as they are defined. Also it would be worth looking into whether there should be heat-related tags available for projects with sufficiently mature resource implementations. I'll be continuing Heat's tradition of the leadership emerging from a shared consensus, leaving the PTL as a point of coordination within the project, and a point of communication to the greater ecosystem. I look forward to the opportunity to do this! 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] [Neutron]: partially update over REST APIs
Neutron PUT operations currently fulfil PATCH semantics in most cases. If you omit an attribute in a PUT request its value will stay unchanged. This behaviour, even if not strictly correct, will not change until a strategy for evolving the API is implemented. Salvatore On 7 April 2015 at 02:06, Yi Yang yyos1...@gmail.com wrote: Does neutron support partially update over REST APIs (PUT method)? In other words, if an property is NOT included in the update, will be property be removed, or just kept as its existing value? Yi __ OpenStack Development Mailing 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] [neutron][lbaas] Horizon support for neutron-lbaas v2
Hi guys, LBaaS v2 has no horizon support as for now and I want to know if this work is planned to be done and , if yes, in what time frame. Is there a plan to develop it for Kilo or for L release? Thanks, Evg __ OpenStack Development Mailing 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] [nova] FFE for libvirt: proper monitoring of live migration progress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +344 new lines of code for an exception patch? No way. Let's take time to consider the patch outside the very next release. On 04/04/2015 01:31 AM, Billy Olsen wrote: 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVI7gkAAoJEC5aWaUY1u577ewH/3d9jmpL0bmdpIkQ47xCrfLA +ePevz8hzvEFBNpoFV9HLlRWStcT26/1gFmNBLYOKwcNcOPJw/znSe2QmXlUG1mI KgWhQrXvsgTqkKVAMpl/uhQoEZbh72sNUkjhe86BIsw8/sr2otQ4Lcd/p8HTYC1D zQNr8/8SQf5/HGMPIW1I+RH7plQwubXZpUw8kQcoxNnkF/kWT4pQgHlwtb9LToeP liwvvNaFl4aoRhxhUyRCMS2QaT62ZcZHzUGIhPxUE/j9UeOc4NzBHw4YGLrs2qFE clMVPZLt+Vn9uVII2nHZ4NGn6iUV2LLceVFv6inCrL4XVjrZTTEdsJDOWl8G5Cw= =lpRA -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
Thanks a lot for what you have done ! --- Mehdi Abaakouk mail: sil...@sileht.net irc: sileht Le 2015-04-03 14:50, Doug Hellmann a écrit : 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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Issues with pip 6.1
(2) it's not more possible to install argparse on Python 2.7 (...) Donald Stufft released pip 6.1.1, he reverted the change which prevented to install argparse. Thanks for the quick fix! (1) update.py of openstack/requirements uses req.InstallRequirement.url attribute, but this attribute is gone (replaced with req.InstallRequirement.link.url) = see https://bugs.launchpad.net/tempest/+bug/1440984 pip 6.1.1 reintroduced the url attribute but there is a bug in the property :-/ According to pip developers, the problem is that OpenStack should not use Python pip API because the Python API is private and not stable. Only the CLI has a stable API. 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] [Zaqar] PTL Candidacy
Obviously, where I said Juno, I meant Kilo :) On 07/04/15 11:35 +0200, Flavio Percoco wrote: Greetings, You read it right, you've not burned out yet - I probably will. Here's a crazy idea, what if I run for 2 PTL positions on the projects I've been putting my focus on lately? Hopefully, by sending this out now, I'll be able to answer all your questions in time before the candidacy period closes. Before you jump out of your chair, pull your hair off and start asking: Is that even possible? Let me tell you that, as far as I can tell by reading our governance repo[0], it seems to be entirely legal. If you think it is not, please do let me know. Now, to my candidacy. During the Juno development cycle, I had the pleasure to be Zaqar's PTL. During this cycle, we managed to kick of complete - at least in an experimental version - some exciting features and we've also kicked off others - you can read more about that here[1]. We did that with a small team of old and new contributors, if it doesn't seem much to you, I'd love to invite you to our team and help us out. :D That said, I think our most important goal during Juno was incorporating the feedback we got from the community, after our last incubation attempt, in a way that doesn't compromise the project's goals but still brings in way more flexibility to the project. This will allow for the community (Zaqar's and OpenStack's) to finally adopt the project wherever it might be needed. Based on the above results and the fact that I believe the community hasn't seen enough (anything) of Zaqar yet, I'd like to throw my hat out there to be Zaqar's PTL for another cycle. Here are some things that I'd like us to do during this cycle: 1. Spread the word and improve our interaction with the overall community. We've spent lot of time heads down coding new features and working out the best way to deliver this project. I believe it's time to throw it out there and let it crash (if you know what I mean). 2. Restore/Improve our community activities by improving our communications through the openstack mailing list, restoring our weekly meetings and contributing back to other projects. 3. Keep improving our deployment story/tools. We've a draft of a puppet manifest that we need to complete, we've devstack support but we ought to bring it into our code base and extend it with other features that have been developed. 4. Keep our amazing mentoring story alive by helping new mentees to integrate with OpenStack, open source and obviously, Zaqar. Something this team should be proud of is that it's mentored new contributors since it was created. The above and more, I'd be honored to do together with the rest of the team. Now, to the obvious natural question: How will I be the PTL of 2 projects and get to the end of the cycle? Well, this definitely will require some changes from my side and my current focus that you'll see happen if I have the honor to be elected for both projects. Will I be burned out at the end of the cycle? Probably, but that's a price I'm willing to pay for these 2 projects and more importantly for OpenStack because I truly believe these projects play (or will play in the case of Zaqar) and important role in our ecosystem. In addition to the above, I must say that, thankfully enough, Zaqar is still not such a time consuming project from a PTL perspective and it's entirely feasible to be the PTL of these 2 projects and still do a good job - last famous words. In all seriousness, I'd be honored to serve for both projects and I hope you'll join me in this experiment. [0] https://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst [1] http://lists.openstack.org/pipermail/openstack-dev/2015-April/060446.html Cheers, Flavio -- @flaper87 Flavio Percoco __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco pgpHNwAgeQosF.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] Multi Region Designate
Hey Anik, So, unlike Nova or other services which really are region aware, Designate, being designed to push data into the global DNS namespace, doesn't have the same concept of regions. Typically, you will either have regions which are close enough to run a Galera/Percona cluster across them without adding too much latency, or you will run asynchronous replication from one region to another using an Active/Standby failover for the core DB. The DNS team @ HP has discussed possible improvements to this many times over the last year or so, but haven't come up with any great solutions to providing what amounts to a global service is a per-region way. We're certainly open to suggestions! :) Thanks, Kiall On 23/03/15 04:41, Anik wrote: Hi, Are there any plans to have multi region DNS service through designate ? For example If a tenant has projects in multiple regions and wants to use a single (flat) external domain name space for floating IPs, what is the proposed solution for such a use case using Designate ? Regards, Anik __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Issues with pip 6.1
On 2015-04-07 07:39:27 -0400 (-0400), Victor Stinner wrote: [...] = see https://bugs.launchpad.net/tempest/+bug/1440984 pip 6.1.1 reintroduced the url attribute but there is a bug in the property :-/ According to pip developers, the problem is that OpenStack should not use Python pip API because the Python API is private and not stable. Only the CLI has a stable API. I merged Steve Martinelli's workaround for this to all requirements branches a little while ago (11:42 UTC), and Sean Dague has a patch series proposed now to do the right thing and not import from pip in that script: https://review.openstack.org/#/q/I10ada68,n,z -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Issues with pip 6.1
On 04/07/2015 07:39 AM, Victor Stinner wrote: (2) it's not more possible to install argparse on Python 2.7 (...) Donald Stufft released pip 6.1.1, he reverted the change which prevented to install argparse. Thanks for the quick fix! (1) update.py of openstack/requirements uses req.InstallRequirement.url attribute, but this attribute is gone (replaced with req.InstallRequirement.link.url) = see https://bugs.launchpad.net/tempest/+bug/1440984 pip 6.1.1 reintroduced the url attribute but there is a bug in the property :-/ According to pip developers, the problem is that OpenStack should not use Python pip API because the Python API is private and not stable. Only the CLI has a stable API. Victor There are work arounds already landed in upstream requirements. Getting rid of pip usage in requirements is done here - https://review.openstack.org/#/q/I10ada6860768017d4eb3c729f2870f2c7f4a46d7,n,z -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] [qa] [devstack] Confusion about member roles in tempest/devstack
On 6 April 2015 at 21:27, David Kranz dkr...@redhat.com wrote: On 04/06/2015 03:14 PM, Matthew Treinish wrote: On Mon, Apr 06, 2015 at 02:25:14PM -0400, David Kranz wrote: There have been a number of changes in tempest recently that seem to coordinate with devstack that are a bit unclear. Well, the issue was that before tempest was making all sorts of incorrect implicit assumptions about the underlying configuration. As part of the test accounts part 2 bp [1] we needed to correct these and make things more explicit which resulted in a number of changes around the configuration in tempest. FWIW, I push to have detailed commit messages to try and make it clear from the git log and explain the rationale behind changes like this. The following values are defined in tempest config as defaults: [auth] # Roles to assign to all users created by tempest (list value) #tempest_roles = So this option is used to set roles on every user created by tenant isolation. Outside of tenant isolation this option does nothing. [object-storage] # Role to add to users created for swift tests to enable creating # containers (string value) #operator_role = Member [orchestration] # Role required for users to be able to manage stacks (string value) #stack_owner_role = heat_stack_owner These are the values created in tempest.conf by devstack: [auth] tempest_roles = Member [orchestration] stack_owner_role = _member_ So a couple of questions. Why do we have Member and _member_, and what is the difference supposed to be? IIRC _member_ is the default role with keystone v3 which is used to show membership in a project. I'm sure Jamie or Morgan will correct me if I'm wrong on this. Experimentally, it seems that the tempest roles cannot be empty, so why is that the default? So, I'm surprised by this, the tests which require the role Member to be set on the created users should be specifically requesting this now. (as part of the test accounts bp we had to make these expectations explicit) It should only be required for the swift tests that do container manipulation.[2] I'm curious to see what you're hitting here. The one thing is from the git log there may be an interaction here depending on the keystone api version you're using. [3] My guess is that it's needed for using keystone v2 in a v3 env, or vice versa, but I'm sure Andrea will chime in if this is wrong. Seems right to me. I should have said it is the identity v3 tests that fail if you leave the default for tempest_roles. It does seem that Member is related to swift tests and it would be less confusing if this were called SwiftOperator instead of Member. The only hardcoded reference to Member in tempest now is in javelin and that is going to be removed https://review.openstack.org/#/c/169108/ Andrea, can you explain why the role that is required in the tempest_roles is Member? If this is really the way it needs to be we should have this as the default in tempest.conf rather than having devstack always set it, no? -David Using identity v2, a user is given a role on the tenant automatically as part of the create user api call. When using identity v3, the user gets no role on the project by default, so a role must be added. Member is the role available for that in devstack - I'm not convinced it should be a default in tempest though. We tried moving away from devstack specific configuration defaults in tempest. andrea The heat_stack_owner role used to be created in juno devstack but no longer. Is there a reason to leave this as the default? IIRC, the use of explicit role was removed in kilo (and maybe backported into juno?) and was replaced with the use of delegations. It removed the need for an explicit role to manipulate heat stacks. The config option is necessary because of branchless tempest considerations and that you might need a specific role to perform stack operations. [4][5] The use of _member_ on master is to indicate that the no special role is needed to perform stack operations. When icehouse support goes eol we probably can remove this option from tempest. -Matt Treinish [1] http://specs.openstack.org/openstack/qa-specs/specs/test-accounts-continued.html [2] http://git.openstack.org/cgit/openstack/tempest/commit/?id=8f26829e939a695732cd5a242dddf63a9a84ecb8 [3] http://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=72f026b60d350ede39e22e08b8f7f286fd0d2633 [4] http://git.openstack.org/cgit/openstack/tempest/commit/?id=db9721dfecd99421f89ca9e263a97271e5f79ca0 [5] http://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=886cbb2a86e475a7982df1d98ea8452d0f9873fd __ OpenStack Development Mailing 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] Feature Freeze Exceptions
Hi folks, Only two days left until RC-1, but few features that were marked as FFE are still not finished: 1. Migrate to YAQL 1.0 [1] 2. Murano Versioning [2] Both of these features are moved to Liberty. References: [1] https://blueprints.launchpad.net/murano/+spec/migrate-to-yaql-vnext [2] https://blueprints.launchpad.net/murano/+spec/murano-versioning On Fri, Mar 20, 2015 at 11:37 PM, Serg Melikyan smelik...@mirantis.com wrote: Hi, folks! Today we released third milestone of Kilo release - 2015.1.0b3 [1], in this milestone we completed 11 blueprints and fixed 13 bugs. We finally completed a number of big features that we were working whole cycle: Integration with Congress, Environment Templates and so on. Release of kilo-3 means that our Feature Freeze kicks in, and we still have some features that are not completed yet. Following features are marked as Feature Freeze exceptions and will be completed during RC cycle: 1. Support for configuration languages (puppet, chef) [2] 2. Migrate to YAQL 1.0 [3] 3. Murano Versioning [4] We also need to finish working on our specifications, cause many specifications are still on review, even as features are already completed. In this cycle we introduced murano-specs [5] repository in experimental mode, but starting from the next cycle we are completely migrating to murano-specs model. P.S. Feature Freeze also means that we are shifting focus from feature development to testing Murano as much as possible. References: [1] https://launchpad.net/murano/+milestone/kilo-3 [2] https://blueprints.launchpad.net/murano/+spec/conf-language-support [3] https://blueprints.launchpad.net/murano/+spec/migrate-to-yaql-vnext [4] https://blueprints.launchpad.net/murano/+spec/murano-versioning [5] http://git.openstack.org/cgit/stackforge/murano-specs/ -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] How to deal with microversions in 3rdparty tools
Hi again, hope you're not tired of this topic :D I'm seeking for advice on what to do with microversions in discoverd. Basically I have the following options: 1. Do nothing. Get whatever behavior I can get from installed Ironic and Ironic client. Though unlikely, may get broken by future changes. 2. Demand version = 1.6. Looks like it keeps compatibility with old clients and servers, not sure what downsides are here. What are we going to recommend now as upstream? 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
Re: [openstack-dev] [Mistral] Propose Winson Chan m4dcoder for core team
Hello all, As a QA Engineer of Mistral, I also appreciate Winson's contribution to the project, his ideas and I will be glad to see him as a core engineer of Mistral project. On Tue, Apr 7, 2015 at 12:56 PM, Lingxian Kong anlin.k...@gmail.com wrote: Although I have jumpped into Mistral just for a short time, but really appreciate Winson's vision about my patches, and his work is of great value to Mistral. I'm not in the core team of Mistral, but really hope to see Winson as a core member to bring more to Mistral. On Tue, Apr 7, 2015 at 5:08 PM, Nikolay Makhotkin nmakhot...@mirantis.com wrote: It would be good to see Winson as the core contributor in Mistral. +1 for Winson! On Tue, Apr 7, 2015 at 11:53 AM, Renat Akhmerov rakhme...@mirantis.com wrote: +1 with my both hands. Winson has been working on Mistral for about a year, was actively participating in the very first workflow engine version (what we called PoC) and keeps bringing his experience and excellent engineering skills to the project. Thanks Winson for your passionate work! Renat Akhmerov @ Mirantis Inc. On 07 Apr 2015, at 03:04, Dmitri Zimine dzim...@stackstorm.com wrote: Hi folks, I’d like to propose Winson Chan (m4dcoder) to become Mistral core team member. Winson brings unique mix of field experience implementing Mistral workflows in user environments, and solid development skills. He has been contributing to Mistral since Mar 2014. Winson did a 23 commits - a number of them are non-trivial, like moving RPC to oslo-messaging, or introducing environments, or making full validation. He has submitted 14 blueprints and detailed design proposals, contributing to design and directions. He found, reported, and fixed bugs. He is becoming more active on the review board (would encourage to do more). I am +1 for m4dcoder as a core team member. DZ. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Regards, Nikolay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards! --- Lingxian Kong __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] [Cinder] FFE for Clear migration_status from a destination volume if migration fails
Mitsuhiro, I had already put a +2 on this, so I am agreeable to an FFE. Mike or John, what are your thoughts? Jay On 04/06/2015 06:27 PM, Mitsuhiro Tanino wrote: Hello, I would like to get a FFE for patch https://review.openstack.org/#/c/161328/. This patch fixes the volume migration problem which is not executed proper cleanup steps if the volume migration is failed. This change only affects cleanup steps and does not change normal volume migration steps. Regards, Mitsuhiro Tanino mitsuhiro.tan...@hds.com HITACHI DATA SYSTEMS __ OpenStack Development Mailing 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] [docs][rally] Rally template tasks in a nutshell
Mikhail, Nice work! Best regards, Boris Pavlovic On Tue, Apr 7, 2015 at 4:08 PM, Aleksandr Maretskiy amarets...@mirantis.com wrote: Great improvement! Thanks! On Tue, Apr 7, 2015 at 1:17 PM, Mikhail Dubov mdu...@mirantis.com wrote: Hi stackers, as you might remember, we have recently added a nice feature to Rally which is the support of *task templates*. Rally uses the template syntax based on *Jinja2*, and thus makes it simple to parameterize your benchmark task files. Our step-by-step tutorial has just been updated with a new lesson devoted to task templates in Rally: http://rally.readthedocs.org/en/latest/tutorial/step_8_task_templates.html You are welcome to read it through (it is fairly short) and ask any questions. Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov __ OpenStack Development Mailing 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] [horizon] - Access to project info in horizon/base.py
Hi all, I would like to know if it's possible to get project info inside this function https://github.com/openstack/horizon/blob/stable/juno/horizon/base.py#L839 I don't know if this function is executed before or after login action, so I don't know if is possible to get the scoped token and, then, the project information. Some idea? Cheers, Marcos. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] how to send messages (and events) to our users
Notifications were added for this very purpose. At Rax, we have a downstream consumer (yagi) that routes notifications to an appropriate ATOM/pubsub feed (based on tenant-id). Notifications are only as heavy as you want to make them. The only required fields are event_type and timestamp. ? From: Angus Salkeld asalk...@mirantis.com Sent: Monday, April 6, 2015 11:55 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [all] how to send messages (and events) to our users Hi all For quite some time we (Heat team) have wanted to be able to send messages to our users (by user I do not mean the Operator, but the User that is interacting with the client). What do I mean by user messages, and how do they differ from our current log messages and notifications? - Our current logs are for the operator and have information that the user should not have (ip addresses, hostnames, configuration options, other tenant info etc..) - Our notifications (that Ceilometer uses) *could* be used, but I am not sure if it quite fits. (they seem a bit heavy weight for a log message and aimed at higher level events) These messages could be (based on Heat's use case): - Specific user oriented log messages (distinct from our normal operator logs) - Deprecation messages (if they are using old resource properties/template features) - Progress and resource state changes (an application doesn't want to poll an api for a state change) - Automated actions (autoscaling events, time based actions) - Potentially integrated server logs (from in guest agents) I wanted to raise this to [all] as it would be great to have a general solution that all projects can make use of. What do we have now: - The user can not get any kind of log message from services. The closest thing ATM is the notifications in Ceilometer, but I have the feeling that these have a different aim. - nova console log - Heat has a DB event table for users (we have long wanted to get rid of this) What do other clouds provide: - https://devcenter.heroku.com/articles/logging - https://cloud.google.com/logging/docs/ - https://aws.amazon.com/blogs/aws/cloudwatch-log-service/ - http://aws.amazon.com/cloudtrail/ (other examples...) What are some options we could investigate: 1. remote syslog The user provides a rsyslog server IP/port and we send their messages to that. [pros] simple, and the user could also send their server's log messages to the same rsyslog - great visibility into what is going on. There are great tools like loggly/logstash/papertrailapp that source logs from remote syslog It leaves the user in control of what tools they get to use. [cons] Would we become a spam agent (just sending traffic to an IP/Port) - I guess that's how remote syslog works. I am not sure if this is an issue or not? This might be a lesser solution for the use case of an application doesn't want to poll an api for a state change I am not sure how we would integrate this with horizon. 2. Zaqar We send the messages to a queue in Zaqar. [pros] multi tenant OpenStack project for messaging! [cons] I don't think Zaqar is installed in most installations (tho' please correct me here if this is wrong). I know Mirantis does not currently support Zaqar, so that would be a problem for me. There is not the level of external tooling like in option 1 (logstash and friends) 3. Other options: Please chip in with suggestions/links! https://blueprints.launchpad.net/heat/+spec/user-visible-logs Regards Angus __ OpenStack Development Mailing 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] How are vcpu's, ram mapped with an instance
Hi Abhishek, You can change it directly using KVM/Qemu command line. However, nova probably won't be notified and the information on the database will be outdated. Em ter, 7 de abr de 2015 às 06:04, Abhishek Talwar/HYD/TCS abhishek.tal...@tcs.com escreveu: Hi Folks, When we boot an instance and assign a flavor to it, how are the vcpu's, ram given to the instance. Actually the question is this while creating an instance we must be assigning it some Vcpu's according to the flavor we gave to the instance. So where are these Vcpu's placed and how are they mapped with an instance. Suppose I want to add some more Vcpu's to my VM at runtime without changing my flavor to a bigger one, can I do it ? -- Thanks and Regards Abhishek Talwar Employee ID : 770072 Assistant System Engineer Tata Consultancy Services,Gurgaon India Contact Details : +918377882003 =-=-= 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] [neutron] [QoS] QoS weekly meeting
On Apr 6, 2015, at 11:56 , Miguel Ángel Ajo majop...@redhat.commailto:majop...@redhat.com wrote: I’d like to co-organized a QoS weekly meeting with Sean M. Collins, In the last few years, the interest for QoS support has increased, Sean has been leading this effort [1] and we believe we should get into a consensus about how to model an extension to let vendor plugins implement QoS capabilities on network ports and tenant networks, and how to extend agents, and the reference implementation others [2] I’m very interested in seeing this feature mature. Sean was writing this code initialy while working with our team here at Comcast and we’re still carrying the patches he wrote through to new versions of Neutron. I’d very much like to discuss ways to bering them back into mailine. As per discussion we’ve had during the last few months [3], I believe we should start simple, but prepare a model allowing future extendibility, to allow for example specific traffic rules (per port, per IP, etc..), congestion notification support [4], … I agree with starting simple. We’ve implemented basic DSCP marking only at this point to allow hardware switches to to queue and filter based on the marks. It would be great to bring the queueing down into the vSwitch and then extend this to things like minimum guaranteed bandwidth. I have a fair few applications that would benefit from these kinds of features. It’s the first time I’m trying to organize an openstack/neutron meeting, so, I don’t know what’s the best way to do it, or find the best timeslot. I guess interested people may have a saying, so I’ve looped anybody I know is interested in the CC of this mail. There’s no best way. Just pick an open meeting timeslot, email out the meeting details and get your notes/meeting minutes onto the wiki. Hopefully this works out and I’d be glad to help! -Anthony Miguel Ángel Ajo [1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api [2] https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing [3] https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231 [4] https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [docs][rally] Rally template tasks in a nutshell
Great improvement! Thanks! On Tue, Apr 7, 2015 at 1:17 PM, Mikhail Dubov mdu...@mirantis.com wrote: Hi stackers, as you might remember, we have recently added a nice feature to Rally which is the support of *task templates*. Rally uses the template syntax based on *Jinja2*, and thus makes it simple to parameterize your benchmark task files. Our step-by-step tutorial has just been updated with a new lesson devoted to task templates in Rally: http://rally.readthedocs.org/en/latest/tutorial/step_8_task_templates.html You are welcome to read it through (it is fairly short) and ask any questions. Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint
On 04/07/2015 12:33 AM, Ben Pfaff wrote: On Mon, Apr 06, 2015 at 03:00:17PM -0500, Kyle Mestery wrote: I know we're not even at the Liberty Design Summit in Vancouver yet, but I wanted to take this time to announce the Neutron mid-cycle coding sprint for Liberty. HP has been gracious enough to offer to host at it's Fort Collins, CO offices. The dates are set for June 24-26, this is Wednesday-Friday. I've got additional information on the etherpad [1]. We'll set the specific agenda in the coming weeks, but the idea is to focus on things like the pending neutron-lib work [2] while there, similar to what we did with the advanced services split in Utah last year. My experience running the past two mid-cycles has been that having these earlier in the cycle has been helpful for landing a lot of work near the first milestone of a release. I expect this to be the same for Liberty with the sprint in Fort Collins. Please note attendance is not required at all. We will do our best to facilitate virtual collaboration for those who cannot travel to the event. I wanted to get this out there for folks who have to book travel in advance. I don't know anything about these events. Naively: would OVN development (some of which is in Neutron, much of which is not) be an appropriate use of time at the event? I suspect so. FWIW, I'm not sure I'll be going, though. The dates aren't good for me. -- 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] [Ironic] How to deal with microversions in 3rdparty tools
I’m not sure that recommending one or the other is best. We should lay out the options (as you just did) and let folks decide what works best for them. For things like discoverd, where you have many users, perhaps you should allow the user to pass a version (for example, option 2 depends on the user running an Ironic version that has a 1.6 at all — they could be at 1.4). For things like the dashboard my team runs internally, we’ll be passing “latest” to the API (we don’t use the client). We know we can move fast, and our dashboard being broken for a short time following a deploy isn’t the end of the world. Hope that helps. :) // jim On April 7, 2015 at 6:07:57 AM, Dmitry Tantsur (dtant...@redhat.com) wrote: Hi again, hope you're not tired of this topic :D I'm seeking for advice on what to do with microversions in discoverd. Basically I have the following options: 1. Do nothing. Get whatever behavior I can get from installed Ironic and Ironic client. Though unlikely, may get broken by future changes. 2. Demand version = 1.6. Looks like it keeps compatibility with old clients and servers, not sure what downsides are here. What are we going to recommend now as upstream? 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 Development Mailing 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] [docs] [End User Guide] [Keystone] keyring support for python-keystoneclient and python-openstackclient
On Tue, Apr 7, 2015 at 3:52 AM, Olena Logvinova ologvin...@mirantis.com wrote: Good day to everyone! My name is Olena, I am new in OpenStack (working as a tech writer). And I'm stuck on a bug https://launchpad.net/bugs/1419990 (patch https://review.openstack.org/#/c/163503/). I have 2 questions, please: Does the page http://docs.openstack.org/user-guide/content/cli_openrc.html contain info about python-keystoneclient only, or both python-keystoneclient and python-openstackclient? The page contains info about all the CLIs, not just keystone and openstack. Users should be able to create an OpenStack RC file that works with the keystone command or the openstack command or nova, glance, etc. Note that the keystone command is deprecated in favor of the openstack command, so I think we should be removing any use of it from the documentation. And should we remove the keyring support part here (because it was removed from python-openstackclient), or do some re-wording (because it is still left in python-keystoneclient)? (Here is a patch saying that keyring is still used by keystoneclient: https://review.openstack.org/#/c/107719/ ) I tried the keystone command and it doesn't have an --os-use-keyring option, and neither does the openstack command. I think the Keyring support section should be removed. - Brant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting
On Apr 7, 2015, at 10:50 , Miguel Angel Ajo Pelayo majop...@redhat.commailto:majop...@redhat.com wrote: Hi Anthony, nice to hear about it! :) Is the implementation available somewhere?, Yes, it’s been posted on github[1]. IMHO, the design should be what’s best for the whole neutron project looking into future extension of the design, by this I mean that we should not influence the design by what was already designed D/S, *but*, I’m sure there are lots of logic that we could reuse from the DSCP perspective, and even if API or internal implementation differs in the end, you’re going to get equivalent logic as soon as diffserv/DSCP is implemented. Absolutely. I’m by no means insinuating that what we have is the only way, or even the ‘right’ way. We had to do it for business requirements so we just got it done and are carrying patches. I’m definitely interested in Salvatore’s suggestion for starting with how to define things in the API first. Best regards, Miguel Ángel On 7/4/2015, at 15:07, Veiga, Anthony anthony_ve...@cable.comcast.commailto:anthony_ve...@cable.comcast.com wrote: On Apr 6, 2015, at 11:56 , Miguel Ángel Ajo majop...@redhat.commailto:majop...@redhat.com wrote: I’d like to co-organized a QoS weekly meeting with Sean M. Collins, In the last few years, the interest for QoS support has increased, Sean has been leading this effort [1] and we believe we should get into a consensus about how to model an extension to let vendor plugins implement QoS capabilities on network ports and tenant networks, and how to extend agents, and the reference implementation others [2] I’m very interested in seeing this feature mature. Sean was writing this code initialy while working with our team here at Comcast and we’re still carrying the patches he wrote through to new versions of Neutron. I’d very much like to discuss ways to bering them back into mailine. As per discussion we’ve had during the last few months [3], I believe we should start simple, but prepare a model allowing future extendibility, to allow for example specific traffic rules (per port, per IP, etc..), congestion notification support [4], … I agree with starting simple. We’ve implemented basic DSCP marking only at this point to allow hardware switches to to queue and filter based on the marks. It would be great to bring the queueing down into the vSwitch and then extend this to things like minimum guaranteed bandwidth. I have a fair few applications that would benefit from these kinds of features. It’s the first time I’m trying to organize an openstack/neutron meeting, so, I don’t know what’s the best way to do it, or find the best timeslot. I guess interested people may have a saying, so I’ve looped anybody I know is interested in the CC of this mail. There’s no best way. Just pick an open meeting timeslot, email out the meeting details and get your notes/meeting minutes onto the wiki. Hopefully this works out and I’d be glad to help! -Anthony Miguel Ángel Ajo [1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api [2] https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing [3] https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231 [4] https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Miguel Angel Ajo __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron]: partially update over REST APIs
Hi Salvatore, Thanks for your quick response. In that case, how to remove a property? set it as None in the update? Yi On 4/7/15 7:28 AM, Salvatore Orlando wrote: Neutron PUT operations currently fulfil PATCH semantics in most cases. If you omit an attribute in a PUT request its value will stay unchanged. This behaviour, even if not strictly correct, will not change until a strategy for evolving the API is implemented. Salvatore On 7 April 2015 at 02:06, Yi Yang yyos1...@gmail.com mailto:yyos1...@gmail.com wrote: Does neutron support partially update over REST APIs (PUT method)? In other words, if an property is NOT included in the update, will be property be removed, or just kept as its existing value? Yi __ 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] [Ironic] How to deal with microversions in 3rdparty tools
On 04/07/2015 03:15 PM, Jim Rollenhagen wrote: I’m not sure that recommending one or the other is best. We should lay out the options (as you just did) and let folks decide what works best for them. For things like discoverd, where you have many users, perhaps you should allow the user to pass a version (for example, option 2 depends on the user running an Ironic version that has a 1.6 at all — they could be at 1.4). For things like the dashboard my team runs internally, we’ll be passing “latest” to the API (we don’t use the client). We know we can move fast, and our dashboard being broken for a short time following a deploy isn’t the end of the world. Allowing a user to set microversions looks to me kind of misuse of them. E.g. a user setting 1.8 does not mean discoverd will start supporting it actually. And I can't get any guarantees about 1.4 as well - I never tested it. So it's really about whether to hard code or not. Also Juno case is a bit exceptional: Ironic Juno will ignore a header no matter if it supports the version. So putting 1.6 might be a safe option. In the future though it leads to a nasty compromise: sacrifice either compatibility with old versions or new features. That's what bothered me a bit with the whole microversioning as we implemented it. Anyway I think we should have a document laying out stuff like that. Hope that helps. :) // jim On April 7, 2015 at 6:07:57 AM, Dmitry Tantsur (dtant...@redhat.com mailto:dtant...@redhat.com) wrote: Hi again, hope you're not tired of this topic :D I'm seeking for advice on what to do with microversions in discoverd. Basically I have the following options: 1. Do nothing. Get whatever behavior I can get from installed Ironic and Ironic client. Though unlikely, may get broken by future changes. 2. Demand version = 1.6. Looks like it keeps compatibility with old clients and servers, not sure what downsides are here. What are we going to recommend now as upstream? 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 Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] how to send messages (and events) to our users
- Specific user oriented log messages (distinct from our normal operator logs) - Deprecation messages (if they are using old resource properties/template features) - Progress and resource state changes (an application doesn't want to poll an api for a state change) - Automated actions (autoscaling events, time based actions) - Potentially integrated server logs (from in guest agents) is the idea that Heat would build events from the logs or would you want to send the log messages to another service to be process? so for example, Nova doesn't send all logs messages to the queue but they do send a set of messages relating to certain actions and errors that occur (beyond just CRUD events). as the use cases above seem to target specific actions/logs and not all logs, i would think the processing could be done on the initiators service end and not on the consumer end. to give an example of what Ceilometer is capable of; Ceilometer currently takes JSON messages from the MQ from *most* services and from there we capture the entire raw notification and index on a select set of key-value pairs. i think it's entirely possible to take in non-json log messages and build an indexer around that if needed. cheers, gord Date: Tue, 7 Apr 2015 12:55:37 +1000 From: asalk...@mirantis.com To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [all] how to send messages (and events) to our users Hi all For quite some time we (Heat team) have wanted to be able to send messages to ourusers (by user I do not mean the Operator, but the User that is interacting with the client). What do I mean by user messages, and how do they differ from our current log messagesand notifications?- Our current logs are for the operator and have information that the user should not have (ip addresses, hostnames, configuration options, other tenant info etc..)- Our notifications (that Ceilometer uses) *could* be used, but I am not sure if it quite fits. (they seem a bit heavy weight for a log message and aimed at higher level events) These messages could be (based on Heat's use case): - Specific user oriented log messages (distinct from our normal operator logs)- Deprecation messages (if they are using old resource properties/template features)- Progress and resource state changes (an application doesn't want to poll an api for a state change) - Automated actions (autoscaling events, time based actions)- Potentially integrated server logs (from in guest agents) I wanted to raise this to [all] as it would be great to have a general solution that all projects can make use of. What do we have now: - The user can not get any kind of log message from services. The closest thing ATM is the notifications in Ceilometer, but I have the feeling that these have a different aim.- nova console log- Heat has a DB event table for users (we have long wanted to get rid of this) What do other clouds provide:- https://devcenter.heroku.com/articles/logging- https://cloud.google.com/logging/docs/- https://aws.amazon.com/blogs/aws/cloudwatch-log-service/- http://aws.amazon.com/cloudtrail/(other examples...) What are some options we could investigate:1. remote syslogThe user provides a rsyslog server IP/port and we send their messages to that.[pros] simple, and the user could also send their server's log messages to the same rsyslog - great visibility into what is going on. There are great tools like loggly/logstash/papertrailapp that source logs from remote syslog It leaves the user in control of what tools they get to use. [cons] Would we become a spam agent (just sending traffic to an IP/Port) - I guess that's how remote syslog works. I am not sure if this is an issue or not? This might be a lesser solution for the use case of an application doesn't want to poll an api for a state change I am not sure how we would integrate this with horizon. 2. ZaqarWe send the messages to a queue in Zaqar.[pros] multi tenant OpenStack project for messaging! [cons] I don't think Zaqar is installed in most installations (tho' please correct me here if this is wrong). I know Mirantis does not currently support Zaqar, so that would be a problem for me. There is not the level of external tooling like in option 1 (logstash and friends) 3. Other options: Please chip in with suggestions/links! https://blueprints.launchpad.net/heat/+spec/user-visible-logs RegardsAngus __ OpenStack Development Mailing 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
Re: [openstack-dev] [nova] How are vcpu's, ram mapped with an instance
- Original Message - From: Abhishek Talwar/HYD/TCS abhishek.tal...@tcs.com To: openstack-dev@lists.openstack.org Hi Folks, When we boot an instance and assign a flavor to it, how are the vcpu's, ram given to the instance. Actually the question is this while creating an instance we must be assigning it some Vcpu's according to the flavor we gave to the instance. So where are these Vcpu's placed and how are they mapped with an instance. By default we do not assign the instances vCPUs to specific pCPU cores - instead just passing a number of vCPUs to give to the instance to qemu. As of Kilo CPU pinning functionality is available but it is somewhat indirect (see http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/virt-driver-cpu-pinning.html ). Suppose I want to add some more Vcpu's to my VM at runtime without changing my flavor to a bigger one, can I do it ? What you are effectively asking for here is hot resize. Most modern hypervisors including KVM have some concept of being able to do this but it's not currently exposed through Nova, though it has been proposed in the past. This appears to be the most recent proposal of this ilk: https://blueprints.launchpad.net/nova/+spec/instance-live-resize I would recommend reviewing and commenting on the latest specification if this is of interest to you: https://review.openstack.org/#/c/141219/ Thanks, Steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] how to send messages (and events) to our users
On 04/07/2015 10:10 AM, gordon chung wrote: - Specific user oriented log messages (distinct from our normal operator logs) - Deprecation messages (if they are using old resource properties/template features) - Progress and resource state changes (an application doesn't want to poll an api for a state change) - Automated actions (autoscaling events, time based actions) - Potentially integrated server logs (from in guest agents) Angus mentions that we want user messages but I'd argue that an events interface (not to be confused with our current stack events) would be a great fit. We could define schemas (building on API-WG's error message guide[1]) for heat events so users can programmatically interact with heat w/o polling all the time. I think moving slightly up the abstraction ladder from here's a log message to here's a structured event with extra metadata too would be great, and do a better job helping users than unstructured log messages. The difference between the AWS options is instructive here because the older service (CloudWatch) is log-line oriented*, while the newer service (CloudTrail) provides structured events. Tooling in general seems to be moving towards richer event data as well. The logging tools (Loggly/Logstash/PaperTrail/zillions of others) are intended to take your unstructured logs and turn them into events, so why not have Heat output structured events that we can present to the user with Ceilometer rather than sending log lines (through syslog or otherwise) and using tooling to reassemble them into events later. TL;DR: I think what we really want is a place to send and react to *events*. Logs are a way to do that, of course, but the Ceilometer way sounds pretty attractive. * CloudWatch has you send unstructured log messages, then build filters to parse them into quantifiable events, then set alarms on those metrics. is the idea that Heat would build events from the logs or would you want to send the log messages to another service to be process? so for example, Nova doesn't send all logs messages to the queue but they do send a set of messages relating to certain actions and errors that occur (beyond just CRUD events). as the use cases above seem to target specific actions/logs and not all logs, i would think the processing could be done on the initiators service end and not on the consumer end. to give an example of what Ceilometer is capable of; Ceilometer currently takes JSON messages from the MQ from *most* services and from there we capture the entire raw notification and index on a select set of key-value pairs. i think it's entirely possible to take in non-json log messages and build an indexer around that if needed. I don't think it would be too hard for us to package up events like stack state transitions, failures (with as much debug info as is reasonable), autoscaling actions, etc. (please pardon any gross terminology-mangling, I'm not very familiar with Ceilometer) We already use notifications to send what I'd term sparse events that only include the affected stack ID, meaning there's not much to slice on in Ceilometer. This could be extended to richer JSON events that include the stack, resources affected in the update, stats like num-deleted-resources or num-replaced-resources, autoscaling actions, and info about stack errors. Is there a way for users as-is to view those raw notifications, not just the indexed k/v pairs? Thanks, Ryan [1]: https://review.openstack.org/#/c/167793/ -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint
On Tue, Apr 7, 2015 at 8:15 AM, Russell Bryant rbry...@redhat.com wrote: On 04/07/2015 12:33 AM, Ben Pfaff wrote: On Mon, Apr 06, 2015 at 03:00:17PM -0500, Kyle Mestery wrote: I know we're not even at the Liberty Design Summit in Vancouver yet, but I wanted to take this time to announce the Neutron mid-cycle coding sprint for Liberty. HP has been gracious enough to offer to host at it's Fort Collins, CO offices. The dates are set for June 24-26, this is Wednesday-Friday. I've got additional information on the etherpad [1]. We'll set the specific agenda in the coming weeks, but the idea is to focus on things like the pending neutron-lib work [2] while there, similar to what we did with the advanced services split in Utah last year. My experience running the past two mid-cycles has been that having these earlier in the cycle has been helpful for landing a lot of work near the first milestone of a release. I expect this to be the same for Liberty with the sprint in Fort Collins. Please note attendance is not required at all. We will do our best to facilitate virtual collaboration for those who cannot travel to the event. I wanted to get this out there for folks who have to book travel in advance. I don't know anything about these events. Naively: would OVN development (some of which is in Neutron, much of which is not) be an appropriate use of time at the event? Yes, I think putting OVN hacking on the agenda makes a lot of sense! I'll add it to the etherpad now. I suspect so. FWIW, I'm not sure I'll be going, though. The dates aren't good for me. Bummer! But, as I said, we'll try our best to include remote people into the coding sprint, so hopefully you can participate from afar. :) -- 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] [neutron] [QoS] QoS weekly meeting
Hi Raghunath, feel free to look at: https://wiki.openstack.org/wiki/Meetings https://wiki.openstack.org/wiki/Meetings and suggest other timeslots with a free meeting room, this is a very wide community, and it’s impossible to get a timeslot in everybody working hours. Please note that option b is out of my working hours already, but I picked it up there because it’s right after another meeting I have and it’s easier to organize at home with kids/wife/etc… Best regards, Miguel Ángel. On 7/4/2015, at 13:14, Raghunath D raghunat...@tcs.com wrote: Hi Miguel, I am interested to join this meeting. I assume that CC of this mail are from different time zones.Please provide time slot with common time zone. With Best Regards Raghunath Dudyala Tata Consultancy Services Limited Mailto: raghunat...@tcs.com Website: http://www.tcs.com http://www.tcs.com/ Experience certainty. IT Services Business Solutions Consulting -Miguel Ángel Ajo majop...@redhat.com wrote: - To: openstack-dev@lists.openstack.org From: Miguel Ángel Ajo majop...@redhat.com Date: 04/06/2015 09:26PM Cc: Kyle Mestery mest...@mestery.com, Sean M. Collins s...@coreitpro.com, irenab@gmail.com irenab@gmail.com, Suresh Balineni sbalin...@juniper.net, Raghunath D raghunat...@tcs.com, Tal Anker anker...@mellanox.com, livnat Peer lp...@redhat.com, Nir Yechiel nyech...@redhat.com, Vikram Choudhary vikram.choudh...@huawei.com, Kalyankumar Asangi kaly...@huawei.com, Dhruv Dhody dhruv.dh...@huawei.com, Dongfeng (C) albert.dongf...@huawei.com Subject: [neutron] [QoS] QoS weekly meeting I’d like to co-organized a QoS weekly meeting with Sean M. Collins, In the last few years, the interest for QoS support has increased, Sean has been leading this effort [1] and we believe we should get into a consensus about how to model an extension to let vendor plugins implement QoS capabilities on network ports and tenant networks, and how to extend agents, and the reference implementation others [2] As per discussion we’ve had during the last few months [3], I believe we should start simple, but prepare a model allowing future extendibility, to allow for example specific traffic rules (per port, per IP, etc..), congestion notification support [4], … It’s the first time I’m trying to organize an openstack/neutron meeting, so, I don’t know what’s the best way to do it, or find the best timeslot. I guess interested people may have a saying, so I’ve looped anybody I know is interested in the CC of this mail. Miguel Ángel Ajo [1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api [2] https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing [3] https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231 https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231 [4] https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification =-=-= 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 Miguel Angel Ajo __ OpenStack Development Mailing 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] [stringfreeze] request for SFE
Nova cores, I would like to request a SFE for the below fix: https://review.openstack.org/#/c/170190/ https://bugs.launchpad.net/nova/+bug/1438226 This change adds a useful error message to help users debug incompatibilities with some versions of a dependency (libvirt). Without this error message the change is of little use. Regards, Stephen Finucane PS: I can redirect this to the i18n mailing list if necessary. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] Kilo RC1 available
Hello everyone, Heat is the first project to produce a release candidate for the Kilo release! The RC1 tarball, as well as a list of last-minute features and fixed bugs since kilo-3 are available at: https://launchpad.net/heat/kilo/kilo-rc1 Unless release-critical issues are found that warrant a release candidate respin, this RC1 will be formally released as the 2015.1.0 final version on April 30. You are therefore strongly encouraged to test and validate this tarball ! Alternatively, you can directly test the proposed/kilo branch at: https://github.com/openstack/heat/tree/proposed/kilo If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/heat/+filebug and tag it *kilo-rc-potential* to bring it to the release crew's attention. Note that the master branch of Heat is now open for Liberty development, and feature freeze restrictions no longer apply there ! Regards, -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][ec2-api] Need advice about running Tempest against stackforge/ec2-api
Hi Sean On Mon, Apr 6, 2015 at 7:34 PM, Sean Dague s...@dague.net wrote: On 04/06/2015 12:13 PM, Andrey M. Pavlov wrote: Hi, We've got a couple of problems running original Tempest EC2 API test against new standalone stackforge/ec2-api project and I wanted to ask for some advice about how to deal with it. Tempest now is running against our ec2-api after this review was closed - https://review.openstack.org/#/c/170258/ And now we face two problems (that can also be found in tempest logs of this review - https://review.openstack.org/#/c/170668/) For now I switched tempest gating job to non-voting until these problems are resolved in the following review - https://review.openstack.org/#/c/170646/ Problems are: 1) tempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip this test tries to allocate address and disassociate it without association. Amazon allows to do it and does not throw error. But EC2 implementation in Nova throws error. We have the same test in our own test suite against stackforge/ec2-api (but it's not merged yet) and I checked it against Amazon. I suggest to remove this test from tempest as incompatible with Amazon. Also it can be skipped but for me it has no sense. This seems fine as a removal. 2) tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_compute_with_volumes This test registers three images by their manifests, run instance with image/kernel/ramdisk parameters, and ssh into this instance to check something. This is not the only test that runs instance with such parameters but this is the only one that ssh-s into such an instance. This instance runs but test can't ssh into it and it fails. Because this instance doesn't have ramdisk and kernel. It runs supplied with image property only. The VM comes up semi-functional and instance can't boot up as a result. Problem is in the ec2-api/nova communication. Nova public API doesn't support kernel and ramdisk parameters during instance creation. Next I'll file a bug to ec2-api with this description. This seems problematic, because I think what you are saying is that the stackforge EC2 API can't start a working guest. This is the only one of the ec2 tests that actually validates the guest is running correctly IIRC. Is there an equivalent test that exists that you think would be better? I'm also not sure I understand where the breakdown is here in missing functionality. I suggest to fix the test to fit both Nova EC2 and ec2api restrictions. Ec2api ignores ari/aki parameters for RunInstances operation, but supports registration of an ami image linked to ari and aki ones. Nova EC2 ignores the links in image registrations, but supports ari/aki parameters for RunInstances operation. So we could set these parameters for both operations to pass this test agains both Nova EC2 and ec2api. I've propesed a change for this: https://review.openstack.org/#/c/171222/ In the long run we should discuss adding this feature to public API but for now we'd like to put Tempest in our project back to voting state. We've got several options about what to do for this and we need some help to pick one (or several): 1) skip this test in tempest and switch tempest back to voting state in our project. The problem is that this test is still also employed against nova's EC2 so it'll get skipped there as well. 2) Leave it as non-voting until extension is added to nova. Great solution but it'll take way too long I understand. 3) add special condition to skipping the test so that it's skipped only when employed against stackforge/ec2-api, while still working against nova if it's possible at all and not too much hassle. Kind regards, Andrey. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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 Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting
Hi Anthony, nice to hear about it! :) Is the implementation available somewhere?, IMHO, the design should be what’s best for the whole neutron project looking into future extension of the design, by this I mean that we should not influence the design by what was already designed D/S, *but*, I’m sure there are lots of logic that we could reuse from the DSCP perspective, and even if API or internal implementation differs in the end, you’re going to get equivalent logic as soon as diffserv/DSCP is implemented. Best regards, Miguel Ángel On 7/4/2015, at 15:07, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: On Apr 6, 2015, at 11:56 , Miguel Ángel Ajo majop...@redhat.com mailto:majop...@redhat.com wrote: I’d like to co-organized a QoS weekly meeting with Sean M. Collins, In the last few years, the interest for QoS support has increased, Sean has been leading this effort [1] and we believe we should get into a consensus about how to model an extension to let vendor plugins implement QoS capabilities on network ports and tenant networks, and how to extend agents, and the reference implementation others [2] I’m very interested in seeing this feature mature. Sean was writing this code initialy while working with our team here at Comcast and we’re still carrying the patches he wrote through to new versions of Neutron. I’d very much like to discuss ways to bering them back into mailine. As per discussion we’ve had during the last few months [3], I believe we should start simple, but prepare a model allowing future extendibility, to allow for example specific traffic rules (per port, per IP, etc..), congestion notification support [4], … I agree with starting simple. We’ve implemented basic DSCP marking only at this point to allow hardware switches to to queue and filter based on the marks. It would be great to bring the queueing down into the vSwitch and then extend this to things like minimum guaranteed bandwidth. I have a fair few applications that would benefit from these kinds of features. It’s the first time I’m trying to organize an openstack/neutron meeting, so, I don’t know what’s the best way to do it, or find the best timeslot. I guess interested people may have a saying, so I’ve looped anybody I know is interested in the CC of this mail. There’s no best way. Just pick an open meeting timeslot, email out the meeting details and get your notes/meeting minutes onto the wiki. Hopefully this works out and I’d be glad to help! -Anthony Miguel Ángel Ajo [1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api [2] https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing [3] https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231 https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231 [4] https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Miguel Angel Ajo __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2
?Hey Evgeny, I believe Vivek is working on Horizon lbaasv2 support. We werent given a timeline or anything but sounds like its being actively worked on. I would reach out to him to get better timelines if concerned. Phillip V. Toohill III Software Developer [http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png] phone: 210-312-4366 mobile: 210-440-8374 From: Evgeny Fedoruk evge...@radware.com Sent: Tuesday, April 7, 2015 5:50 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hi guys, LBaaS v2 has no horizon support as for now and I want to know if this work is planned to be done and , if yes, in what time frame. Is there a plan to develop it for Kilo or for L release? Thanks, Evg __ OpenStack Development Mailing 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] [Zaqar] PTL Candidacy
On 04/07/2015 04:43 AM, Flavio Percoco wrote: Obviously, where I said Juno, I meant Kilo :) You sure you're not burned out? :P -jay On 07/04/15 11:35 +0200, Flavio Percoco wrote: Greetings, You read it right, you've not burned out yet - I probably will. Here's a crazy idea, what if I run for 2 PTL positions on the projects I've been putting my focus on lately? Hopefully, by sending this out now, I'll be able to answer all your questions in time before the candidacy period closes. Before you jump out of your chair, pull your hair off and start asking: Is that even possible? Let me tell you that, as far as I can tell by reading our governance repo[0], it seems to be entirely legal. If you think it is not, please do let me know. Now, to my candidacy. During the Juno development cycle, I had the pleasure to be Zaqar's PTL. During this cycle, we managed to kick of complete - at least in an experimental version - some exciting features and we've also kicked off others - you can read more about that here[1]. We did that with a small team of old and new contributors, if it doesn't seem much to you, I'd love to invite you to our team and help us out. :D That said, I think our most important goal during Juno was incorporating the feedback we got from the community, after our last incubation attempt, in a way that doesn't compromise the project's goals but still brings in way more flexibility to the project. This will allow for the community (Zaqar's and OpenStack's) to finally adopt the project wherever it might be needed. Based on the above results and the fact that I believe the community hasn't seen enough (anything) of Zaqar yet, I'd like to throw my hat out there to be Zaqar's PTL for another cycle. Here are some things that I'd like us to do during this cycle: 1. Spread the word and improve our interaction with the overall community. We've spent lot of time heads down coding new features and working out the best way to deliver this project. I believe it's time to throw it out there and let it crash (if you know what I mean). 2. Restore/Improve our community activities by improving our communications through the openstack mailing list, restoring our weekly meetings and contributing back to other projects. 3. Keep improving our deployment story/tools. We've a draft of a puppet manifest that we need to complete, we've devstack support but we ought to bring it into our code base and extend it with other features that have been developed. 4. Keep our amazing mentoring story alive by helping new mentees to integrate with OpenStack, open source and obviously, Zaqar. Something this team should be proud of is that it's mentored new contributors since it was created. The above and more, I'd be honored to do together with the rest of the team. Now, to the obvious natural question: How will I be the PTL of 2 projects and get to the end of the cycle? Well, this definitely will require some changes from my side and my current focus that you'll see happen if I have the honor to be elected for both projects. Will I be burned out at the end of the cycle? Probably, but that's a price I'm willing to pay for these 2 projects and more importantly for OpenStack because I truly believe these projects play (or will play in the case of Zaqar) and important role in our ecosystem. In addition to the above, I must say that, thankfully enough, Zaqar is still not such a time consuming project from a PTL perspective and it's entirely feasible to be the PTL of these 2 projects and still do a good job - last famous words. In all seriousness, I'd be honored to serve for both projects and I hope you'll join me in this experiment. [0] https://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst [1] http://lists.openstack.org/pipermail/openstack-dev/2015-April/060446.html Cheers, Flavio -- @flaper87 Flavio Percoco __ OpenStack Development Mailing 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] [Congress] PTL candidacy
confirmed On Mon, Apr 6, 2015 at 1:42 PM, Tim Hinrichs thinri...@vmware.com wrote: Hi all, I'm writing to announce my candidacy for PTL of Congress for the Liberty cycle. We've made a lot of progress in Kilo, and I'm excited by what we'll achieve in Liberty! To give us some perspective, I compiled a (partial) list of improvements we made in Kilo: * Officially became part of OpenStack (moved from stackforge to openstack) * Matured the Congress community (commits/LOC from outside VMware: Juno:8%, Kilo:26%) * Integrated with our first external project: Murano * Improved scale-up by orders of magnitude (see http://ruleyourcloud.com/2015/03/12/scaling-up-congress.html) * Added the first version of reactive enforcement (correcting policy violations after they happen) * Created a Horizon GUI for writing policy * Built a DSL for integrating external cloud services and enabled on-demand (de)installation of services We achieved just about everything we set out to do in Kilo, thanks to the hard work of many outstanding folks. For the Liberty cycle, I'm planning on similar success in the following areas. * Production deployments * Scale-out: enabling high-availability and increased throughput * Delegation: enabling Congress to interoperate with other policy engines to share the burden of policy enforcement * Community: increasing non-VMware contributions, in terms of commits/LOC and especially reviews While Congress is an early-stage project, we're on a great track, and I'll make sure we stay on it. As always I'm happy to chat about future directions, past progress, and anything in between. Thanks! Tim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Elizabeth Krumbach Joseph || Lyz || pleia2 __ OpenStack Development Mailing 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] Host maintenance notification
On 4/6/2015 2:07 PM, Chris Friesen wrote: On 04/06/2015 12:52 PM, Matthew Treinish wrote: On Mon, Apr 06, 2015 at 01:17:20PM -0500, Matt Riedemann wrote: On 4/6/2015 9:46 AM, Chris Friesen wrote: On 04/06/2015 07:56 AM, Ed Leafe wrote: On Apr 6, 2015, at 1:21 AM, Chris Friesen chris.frie...@windriver.com wrote: Please feel free to add a blueprint in Launchpad. I don't see this as needing a full spec, really. It shouldn't be more than a few lines of code to send a new notification message. Wouldn't a new notification message count as an API change? Or are we saying that it's such a small API change that any discussion can happen in the blueprint? I don't think that the notification system is the same as the API. It is something that you can subscribe to or not, and is distinct from the API. It's certainly not the same as the REST API. I think an argument could be made that the notification system is part of the API, where API is defined more generally as something that expresses a software component in terms of its operations, inputs, outputs, and underlying types. If we don't exercise any control over the contents of the notifications messages, that would make it difficult for consumers of the notifications to do anything interesting with them. At a minimum it might make sense to do something like REST API microversions, with a version number and a place to look up what changed with each version. The events and their payloads are listed in the wiki here [1]. In the past people have added new notifications with just bug reports, I'm not sure a new spec is required for a host going into maintenance mode (as long as it's new and not changing something). Yeah, in it's current state without real versioning on notifications I think just adding it with a bug is fine. If nova actually had a versioning mechanism and made stability guarantees on notifications it would be a different story. I'm fine either way...just wanted to be sure the decision was made consciously. Chris __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Nice timing on the discussion here, I'd been meaning to upstream a devref [1] that we had internally since grizzly (so it's outdated a bit) that moves the event notifications out of the wiki and into the nova docs. Comments welcome on that. I just got it posted today though so I know it needs quite a bit of updating. [1] https://review.openstack.org/#/c/171291/ -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Manila] Question on documentation reviews
Hi guys, I have been reviewing https://review.openstack.org/#/c/171166/, but I am concerned that I provided more of a hindrance than assistance. Instead I would like to propose the method used by Swift for document reviews, where reviewers provide a patch to the author as in https://review.openstack.org/#/c/169990 . What do you think? - Luis __ OpenStack Development Mailing 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] Common Libraries PTL Candidacy
confirmed On Sun, Apr 5, 2015 at 4:21 PM, Davanum Srinivas dava...@gmail.com wrote: Hi Everyone, After shadowing Doug for a while, It's going to be a really hard job filling Doug's shoes. I am very thankful and very glad we had him so long to guide us. I'd like to continue his good work going forward. We've achieved a lot last couple of cycles, and the proof is the almost empty oslo-incubator and the numerous libraries that we have shipped. There is a lot of work yet to be done in adoption of our oslo libraries in Liberty and beyond. We now have a good handle on the release process, working with our CI, stable branches etc. We should figure out how to help other projects pick up lessons we learned as well. I'd also like to concentrate on getting more participation and expertise in some of our really critical projects like oslo.messaging, oslo.db etc. We have some very good solutions like Taskflow which could use some help with adoption in existing projects like Nova. I'd like to figure out how to do that as well. If you would like to have me as your PTL, i'd need your help and patience to make things happen :) Thanks, 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 -- Elizabeth Krumbach Joseph || Lyz || pleia2 __ OpenStack Development Mailing 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] PTL Candidacy
confirmed On 04/06/2015 10:50 PM, Steve Baker wrote: I'd like to announce my candidacy for the Heat PTL in Liberty. As I was the PTL during Icehouse, this will be Heat's first rerun PTL under our convention for rotating leaders. Even if elected I would hope that we continue to find Heat PTL new-blood for future cycles. Towards the end of the Kilo cycle we started to get some momentum on landing the changes required for the Convergence effort. The aim will be to get much of the first-phase features landing early in Liberty, and spend the rest of the cycle focusing on convergence features which provide the most user benefit. There are important maintenance tasks in the Liberty cycle which will need continued effort, including functional/integration testing, content for the template-writer's guide, and general usability improvements. It seems that our merge throughput would be higher if our existing review attention were more coordinated. Nova has had some success with priorities, and Swift works well with a PTL curated etherpad of suggested reviews. I'd like to discuss the options with other heat cores, and am currently suggesting something like the Swift approach. As the Big Tent process continues to mature I'd like to ensure that Heat is well positioned to qualify for the appropriate tags as they are defined. Also it would be worth looking into whether there should be heat-related tags available for projects with sufficiently mature resource implementations. I'll be continuing Heat's tradition of the leadership emerging from a shared consensus, leaving the PTL as a point of coordination within the project, and a point of communication to the greater ecosystem. I look forward to the opportunity to do this! 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 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] [neutron] [QoS] QoS weekly meeting
On Apr 7, 2015, at 11:05 , Veiga, Anthony anthony_ve...@cable.comcast.commailto:anthony_ve...@cable.comcast.com wrote: On Apr 7, 2015, at 10:50 , Miguel Angel Ajo Pelayo majop...@redhat.commailto:majop...@redhat.com wrote: Hi Anthony, nice to hear about it! :) Is the implementation available somewhere?, Yes, it’s been posted on github[1]. The URL would have helped. [1] https://github.com/netoisstools/neutron/ IMHO, the design should be what’s best for the whole neutron project looking into future extension of the design, by this I mean that we should not influence the design by what was already designed D/S, *but*, I’m sure there are lots of logic that we could reuse from the DSCP perspective, and even if API or internal implementation differs in the end, you’re going to get equivalent logic as soon as diffserv/DSCP is implemented. Absolutely. I’m by no means insinuating that what we have is the only way, or even the ‘right’ way. We had to do it for business requirements so we just got it done and are carrying patches. I’m definitely interested in Salvatore’s suggestion for starting with how to define things in the API first. Best regards, Miguel Ángel On 7/4/2015, at 15:07, Veiga, Anthony anthony_ve...@cable.comcast.commailto:anthony_ve...@cable.comcast.com wrote: On Apr 6, 2015, at 11:56 , Miguel Ángel Ajo majop...@redhat.commailto:majop...@redhat.com wrote: I’d like to co-organized a QoS weekly meeting with Sean M. Collins, In the last few years, the interest for QoS support has increased, Sean has been leading this effort [1] and we believe we should get into a consensus about how to model an extension to let vendor plugins implement QoS capabilities on network ports and tenant networks, and how to extend agents, and the reference implementation others [2] I’m very interested in seeing this feature mature. Sean was writing this code initialy while working with our team here at Comcast and we’re still carrying the patches he wrote through to new versions of Neutron. I’d very much like to discuss ways to bering them back into mailine. As per discussion we’ve had during the last few months [3], I believe we should start simple, but prepare a model allowing future extendibility, to allow for example specific traffic rules (per port, per IP, etc..), congestion notification support [4], … I agree with starting simple. We’ve implemented basic DSCP marking only at this point to allow hardware switches to to queue and filter based on the marks. It would be great to bring the queueing down into the vSwitch and then extend this to things like minimum guaranteed bandwidth. I have a fair few applications that would benefit from these kinds of features. It’s the first time I’m trying to organize an openstack/neutron meeting, so, I don’t know what’s the best way to do it, or find the best timeslot. I guess interested people may have a saying, so I’ve looped anybody I know is interested in the CC of this mail. There’s no best way. Just pick an open meeting timeslot, email out the meeting details and get your notes/meeting minutes onto the wiki. Hopefully this works out and I’d be glad to help! -Anthony Miguel Ángel Ajo [1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api [2] https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing [3] https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231 [4] https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Miguel Angel Ajo __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __
Re: [openstack-dev] [Documentation] PTL Candidacy
Confirmed. On Sun, Apr 5, 2015 at 2:42 PM, Lana Brindley openst...@lanabrindley.com wrote: Hi everyone, I am announcing my candidacy for Documentation PTL. I have been contributing to the OpenStack documentation project since 2013, and have been a core contributor since early 2014. During that time I have been supporting and promoting the OpenStack documentation community in the southern hemisphere, through the implementation and running of regular APAC documentation meetings. These are designed to alternate with the US-timed meetings, and provide a forum for people in the Asia-Pacific region to be able to collaborate during a suitable time slot. I have also been actively coordinating Australia-based meet ups and documentation swarms. Some of you might have met me at the Paris Summit, where Anne and I gave a talk about working in an enterprise environment with an upstream[1]. I am employed by Rackspace, and I work from my home in Brisbane, Australia. My job title is officially Senior Manager, Information Development, but what that really means is that I look after a team of fantastic writers in Australia and the United States, all of whom are OpenStack ATCs. I have been managing documentation teams in some capacity for nearly five years, and I've been a technical writer for a decade, but (like most writers) I've been writing all of my life. Over the past year or so I have been working closely with Anne, seeing the amazing things she has done (and continues to do) with this group. If elected as PTL, I intend to continue that close relationship, and build on what she has already achieved. We need to continue the RST conversion, and move closer to an Every Page is Page One-style delivery mechanism. I also want to keep a focus on information architecture as a whole, and making sure that we're delivering documentation that our readers can really use. I would also like to work towards a more effective collaboration with our corporate contributors: giving them greater access to documentation that they can use as a base for their own products, and enabling them to more easily give back to our upstream community. I'd love to have your support for the PTL role, I'm looking forward to being able to better serve this community, and continue to see it grow and flourish. Thanks, Lana 1: https://www.youtube.com/watch?v=9hWdD2t43JY Lana Brindley Technical Writer Rackspace Cloud Builders Australia __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Elizabeth Krumbach Joseph || Lyz || pleia2 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] PTL Candidacy
Confirmed. On Sun, Apr 5, 2015 at 11:56 AM, Serg Melikyan smelik...@mirantis.com wrote: Hi folks, I'd like to announce my candidacy as PTL for Murano [1]. I was handling PTL responsibilities in this release cycle so far, after Ruslan Kamaldinov (who was handling them in Juno cycle) hand over them to me on OpenStack Summit in Paris. I am working on Murano since it's kick-off two years ago [2][3]. As a PTL of Murano I'll continue my work on making Murano better with each day and become project of choice for building own Application Catalogs Marketplaces for private public clouds on OpenStack. I will focus on building great environment for contributors and work on relationships built around the project itself not only around the features needed by contributors. [1] http://wiki.openstack.org/wiki/Murano [2] http://stackalytics.com/report/contribution/murano/90 [3] http://stackalytics.com/?release=kilometric=commitsproject_type=stackforgemodule=murano-group P.S. I understand that it is strange to see same application to same position just few weeks after being officially elected, but since Murano is now part of the Big Tent and in order to comply with the existing processes we are running Murano PTL Election once again for Liberty. http://lists.openstack.org/pipermail/openstack-dev/2015-April/060472.html -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Elizabeth Krumbach Joseph || Lyz || pleia2 __ OpenStack Development Mailing 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] [Zaqar] PTL Candidacy
confirmed On 04/07/2015 05:35 AM, Flavio Percoco wrote: Greetings, You read it right, you've not burned out yet - I probably will. Here's a crazy idea, what if I run for 2 PTL positions on the projects I've been putting my focus on lately? Hopefully, by sending this out now, I'll be able to answer all your questions in time before the candidacy period closes. Before you jump out of your chair, pull your hair off and start asking: Is that even possible? Let me tell you that, as far as I can tell by reading our governance repo[0], it seems to be entirely legal. If you think it is not, please do let me know. Now, to my candidacy. During the Juno development cycle, I had the pleasure to be Zaqar's PTL. During this cycle, we managed to kick of complete - at least in an experimental version - some exciting features and we've also kicked off others - you can read more about that here[1]. We did that with a small team of old and new contributors, if it doesn't seem much to you, I'd love to invite you to our team and help us out. :D That said, I think our most important goal during Juno was incorporating the feedback we got from the community, after our last incubation attempt, in a way that doesn't compromise the project's goals but still brings in way more flexibility to the project. This will allow for the community (Zaqar's and OpenStack's) to finally adopt the project wherever it might be needed. Based on the above results and the fact that I believe the community hasn't seen enough (anything) of Zaqar yet, I'd like to throw my hat out there to be Zaqar's PTL for another cycle. Here are some things that I'd like us to do during this cycle: 1. Spread the word and improve our interaction with the overall community. We've spent lot of time heads down coding new features and working out the best way to deliver this project. I believe it's time to throw it out there and let it crash (if you know what I mean). 2. Restore/Improve our community activities by improving our communications through the openstack mailing list, restoring our weekly meetings and contributing back to other projects. 3. Keep improving our deployment story/tools. We've a draft of a puppet manifest that we need to complete, we've devstack support but we ought to bring it into our code base and extend it with other features that have been developed. 4. Keep our amazing mentoring story alive by helping new mentees to integrate with OpenStack, open source and obviously, Zaqar. Something this team should be proud of is that it's mentored new contributors since it was created. The above and more, I'd be honored to do together with the rest of the team. Now, to the obvious natural question: How will I be the PTL of 2 projects and get to the end of the cycle? Well, this definitely will require some changes from my side and my current focus that you'll see happen if I have the honor to be elected for both projects. Will I be burned out at the end of the cycle? Probably, but that's a price I'm willing to pay for these 2 projects and more importantly for OpenStack because I truly believe these projects play (or will play in the case of Zaqar) and important role in our ecosystem. In addition to the above, I must say that, thankfully enough, Zaqar is still not such a time consuming project from a PTL perspective and it's entirely feasible to be the PTL of these 2 projects and still do a good job - last famous words. In all seriousness, I'd be honored to serve for both projects and I hope you'll join me in this experiment. [0] https://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst [1] http://lists.openstack.org/pipermail/openstack-dev/2015-April/060446.html Cheers, Flavio -- @flaper87 Flavio Percoco __ OpenStack Development Mailing 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] [TripleO] PTL Candidacy
confirmed On 04/06/2015 11:42 PM, James Slagle wrote: Hi, I'm running for TripleO PTL for the Liberty cycle. I've been an active TripleO developer and contributor for going on 2 years now. I'm really excited about all the great progress TripleO made during Kilo. The puppet integration is almost fully complete and has enabled several aspects that I'd like to see TripleO continue to improve on during Liberty: * Better defined interfaces in tripleo-heat-templates -- The puppet work has moved us to having a cleaner separation in the templates between the actual deployment and configuration of the Overcloud. I'd like to see us build on this work, particularly in a way that will enable integration with Kolla so we can have a Heat deployed containerized Overcloud. * Package based updates -- I really feel a traditional distribution based package based story is the quickest way to providing an update solution for TripleO. Containerization, once integrated, could provide a second update solution that would provide many of the same benefits as an image based update model. * CI coverage -- tripleo-ci continues to prove it's value by finding real regressions in OpenStack that otherwise would have been missed. I'd like to continue to press on our CI and use it to report on other projects (such as the puppet modules) where that desire exists. There are a few other items that I feel are important for us to focus on during Liberty: I feel we can do a better job releasing our software projects in a way that makes it easier to consume TripleO. Particularly in such a way that it's more obvious how to use it together to deploy OpenStack. I think a part of that would be the re-introduction of using stable branches and to improve our documentation on deploying via TripleO. I'd also like to see us make it easier for users to get started with TripleO. The only so called entry point or way to get started with TripleO currently is devtest. While devtest works for developers and at driving our CI, I don't consider it something to be used for deploying an actual production cloud. I think we need to work to fill this gap. Making things easier to get started would also help us bring in new developers. In the same vein, we grow our developer community by integrating with things like Puppet and Kolla. I think we have a lot of great opportunity here to show how TripleO can integrate with new and existing deployment solutions. Finally, moving forward, I'd like to see our project encourage more leadership growth. I don't feel like the majority of a project's leadership needs to come from just 1 (or a few) individual or role. If elected as PTL, I'd look forward to fostering this type of growth in our community. Thanks for your consideration! 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] [neutron][lbaas] Horizon support for neutron-lbaas v2
Hi Evgeny, We have just started working on Horizon lbaasv2 support. I have to sync up with my team on the time-line but it is not targeted for Kilo release. Since it is a major effort, we will need more hands. Let me know if anyone is interested to contribute. On a related note, Do we have a sample code which uses neutronclient lbaas v2 methods? That will greatly speedup our horizon integration. Thanks, Vivek From: Phillip Toohill phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, April 7, 2015 at 7:50 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hey Evgeny, I believe Vivek is working on Horizon lbaasv2 support. We werent given a timeline or anything but sounds like its being actively worked on. I would reach out to him to get better timelines if concerned. Phillip V. Toohill III Software Developer [http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png] phone: 210-312-4366 mobile: 210-440-8374 From: Evgeny Fedoruk evge...@radware.commailto:evge...@radware.com Sent: Tuesday, April 7, 2015 5:50 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hi guys, LBaaS v2 has no horizon support as for now and I want to know if this work is planned to be done and , if yes, in what time frame. Is there a plan to develop it for Kilo or for L release? Thanks, Evg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting
Hi Miguel, Both time slots work for me. Thanks for rekindling this effort. Thanks, Sandhya From: Miguel Ángel Ajo majop...@redhat.commailto:majop...@redhat.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, April 7, 2015 1:45 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting On Tuesday, 7 de April de 2015 at 3:14, Kyle Mestery wrote: On Mon, Apr 6, 2015 at 6:04 PM, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: On 7 April 2015 at 00:33, Armando M. arma...@gmail.commailto:arma...@gmail.com wrote: On 6 April 2015 at 08:56, Miguel Ángel Ajo majop...@redhat.commailto:majop...@redhat.com wrote: I’d like to co-organized a QoS weekly meeting with Sean M. Collins, In the last few years, the interest for QoS support has increased, Sean has been leading this effort [1] and we believe we should get into a consensus about how to model an extension to let vendor plugins implement QoS capabilities on network ports and tenant networks, and how to extend agents, and the reference implementation others [2] As you surely know, so far every attempt to achieve a consensus has failed in a pretty miserable way. This mostly because QoS can be interpreted in a lot of different ways, both from the conceptual and practical perspective. Yes, I’m fully aware of it, it was also a new feature, so it was out of scope for Kilo. It is important in my opinion to clearly define the goals first. For instance a simple extensions for bandwidth limiting could be a reasonable target for the Liberty release. I quite agree here, but IMHO, as you said it’s a quite open field (limiting, guaranteeing, marking, traffic shaping..), we should do our best in trying to define a model allowing us to build that up in the future without huge changes, on the API side I guess micro versioning is going to help in the API evolution. Also, at some point, we should/could need to involve the nova folks, for example, to define port flavors that can be associated to nova instance flavors, providing them 1) different types of network port speeds/guarantees/priorities, 2) being able to schedule instance/ports in coordination to be able to met specified guarantees. yes, complexity can sky rocket fast, Moving things such as ECN into future works is the right thing to do in my opinion. Attempting to define a flexible framework that can deal with advanced QoS policies specification is a laudable effort, but I am a bit skeptical about its feasibility. ++, I think focusing on perhaps bandwidth limiting may make a lot of sense Yes, I believe we should look into the future , but at the same pick our very first feature (or a very simple set of them) for L, stick to it, and try to make a design that can be extended. As per discussion we’ve had during the last few months [3], I believe we should start simple, but prepare a model allowing future extendibility, to allow for example specific traffic rules (per port, per IP, etc..), congestion notification support [4], … Simple in my mind is even more extreme then what you're proposing here... I'd start with bare APIs for specifying bandwidth limiting, and then phase them out once this framework is in place. Also note that this kind of design bears some overlap with the flavor framework which is probably going to be another goal for Liberty. Indeed, and the flavor framework is something I'm hoping we can land by Liberty-1 (yes, I just said Liberty-1). Yes it’s something I looked at, I must admit I wasn’t able to see it work together (It doesn’t mean it doesn’t play well, but most probably I was silly enough not to see it :) ), I didn’t want to distract attention from the Kilo cycle focus making questions, so it should be a good thing to talk about during the first meetings. Who are the flavor fathers/mothers? ;) Morever, consider using common tools such as the specs repo to share and discuss design documents. Also a good idea. Yes, that was the plan now, we didn’t use it before to avoid creating unnecessary noise during this cycle. It’s the first time I’m trying to organize an openstack/neutron meeting, so, I don’t know what’s the best way to do it, or find the best timeslot. I guess interested people may have a saying, so I’ve looped anybody I know is interested in the CC of this mail. I think that's a good idea. Incidentally I was speaking with Sean regarding Summit session [1], and we were hoping we could get some folks together either prior or during the summit, to try and get some momentum going behind this initiative, once again. Very interesting [1]!, nice to see we start to have a bunch of people with an interest in QoS. I think is a good idea as well. I
[openstack-dev] [nova] [stringfreeze] request for SFE for live-migration on system z (review 166130)
I'd like to request a string freeze exception for this review: https://review.openstack.org/#/c/166130/ Justification: This fix would enable the live-migration on the system z platform. This platform (arch=s390x) doesn't currently support the CPU comparison but is working on patch sets in qemu to enable this [1]. With the patch set above a customer would at least have the possibility to use the live- migration feature with Kilo on system z. [1] http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg04296.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
Re: [openstack-dev] [Ironic] PTL Candidacy
confirmed On 04/07/2015 06:58 AM, Devananda van der Veen wrote: Hi all, I'd like to announce my candidacy as PTL for Ironic for the Liberty cycle. I've been involved in OpenStack since the Essex cycle, and have served as PTL for Ironic since I started the project at the Havana summit. As the project has matured, my day-to-day activity within the project has changed from writing code to mentoring to enabling subteams. Recently, I have begun to spend more time on projects within my employer; while I expect that to continue, the two roles complement each other and, as such, I would like to continue to serve as PTL for another cycle. I'd like to thank everyone who continues to lend their knowledge, hard work, and humor to making this project successful and this community enjoyable to work with. Looking back at the Juno release, we saw integration with Nova and many new hardware drivers in Ironic. During Kilo, we have had minimal changes to the nova.virt.ironic driver, and only two new hardware drivers. On the other hand, we've had many changes within Ironic and implemented several features which align with the goals which I set out at the beginning of the cycle. In the day-to-day pace of staring at review boards and patches that haven't merged yet, we often get frustrated because it feels like things don't move fast enough. When I look back at the last six months, the picture looks different. I think we have accomplished a lot, and I believe that is a result of empowering sub-teams and building stable APIs between services and libraries. I'd like to highlight a few of the biggest accomplishments. As a result of discussions at the Paris design summit, we spent a hefty chunk of the cycle designing and implementing a finite state machine [1] to formally model the transitions between node states. We then implemented support for two of the new state transitions (introspection and cleaning). This exposed a flaw in the pre-Kilo node states which we've addressed, but that change caused us to rev the API in an incompatible way. To maintain compatibility with Juno-era clients, we borrowed from Nova's lead with API microversions and implemented support [2] for those as well. Even so, this change led to more friction than any other change in Ironic during this cycle, and is a good reminder that building a stable API is possibly the most important thing we do. We gave drivers the ability to maintain internal state in the database and to register their own periodic tasks, and we added iRMC (Fujitsu) and AMT (Intel) drivers. We also continue to hold to our guarantee of backwards-compatibility at the driver API layer, which has led to more than one out-of-tree driver cropping up. It has also led to some driver developers publishing new libraries for their hardware, and plugging those in to Ironic with relatively little effort. [3] For the record, I think that's fantastic, and we should continue enabling that. The proliantutils [4] project is just one example of this; several others are being developed elsewhere and released to pypi by their vendors. The ironic-python-agent [5] project has been around for just over a year now, and I'm very pleased both with the project and the team integration. The ironic-discoverd project [6] is just over six months old; devstack support is in the works and so I hope that by the end of the Liberty cycle, it will be integrated and tested alongside with Ironic. Even more recently, the bifrost project [7] was created to demonstrate the functionality of a stand-alone Ironic service and simplify small-scale hardware deployment. As it turns out, this is a convenient way to do functional testing of Ironic without a full OpenStack deployment, so we'll be exploring that in Liberty. I'm sure I've left some things out - this really isn't the place for full release notes anyway :) In Liberty, I'd like us to complete the state machine, split the boot and deploy interfaces, and complete the client side of client-server version negotiation. That's enough changes in the core of the project for one cycle. I'd like to see more consistency in feature coverage across hardware drivers, as well as better tracking and communication about each drivers' capabilities. We need to keep abreast of changes in the horizontal efforts across OpenStack -- oslo, qa, and docs. In particular, we will need to look at the move to in-tree functional testing and determine how we want to structure that for ourselves. We also have no presence in the OpenStack Manual, though our developer docs have sprouted several pages geared towards operators [8]. Whether our operator-centric docs stay in the code tree or are moved elsewhere, we should continue to develop them. As the contributor base grows, we may need to re-evaluate the team structure, but right now I think things are going well in this area. I plan to continue guiding us in a
[openstack-dev] OpenStack in the classroom
CS and EE schools today use open source software as the basis for a lot of coursework and as the practical example for several concepts. Most often the exemplar system is Linux. Yet if students are even taught about the cloud, they often learn about that other cloud company from Seattle. I think OpenStack is the ideal exemplar system for a whole lot of CS/EE courses. No matter what area of computer science you are interested in, there's an OpenStack project (or in some cases several) that you can study. I think the fact that you can have the entire cloud on your laptop, source code and all, is incredibly powerful in the classroom. Not only can you see how the system works, but you can also tweak it or fix it if you find something to be wrong. Some students also learn about software development methodologies by contributing to a fictional open source project. Why do that when they can instead be contributing code to a real open source project? I think there's a huge opportunity for us to take OpenStack in the Classroom (a longer post about my experience doing this last week is at http://www.tesora.com/openstack-in-the-classroom/). My thanks to dims and Kamesh Pemmaraju for helping me with this at short notice. Let us make (and I'm looking to the Foundation to support this as a formal initiative) it a priority to have every university offer courses on computer science and cloud computing with OpenStack as the exemplar system. Personally, I'm going to work with educational institutions in Massachusetts and near Toronto (where Tesora has offices, and where I tend to spend most of my time) to try and make available a course on cloud computing with OpenStack as the exemplar system. I'm going to make the materials, and offer to teach the course, and I will contribute the materials to the Foundation. So this is an open offer to any university in MA and near Toronto; if you want someone to develop and deliver a course on cloud computing, please let me know! I think we can all come together and take OpenStack to the Classrooms so that every graduating student interested in cloud computing has a working knowledge of OpenStack. Thanks, -amrith Amrith Kumar, Founder CTO [tesora-small] Mobile: 978-563-9590 Direct: 978-707-8010 x1002 Twitter: @amrithkumarhttp://www.twitter.com/amrithkumar Skype: amrith.skype Check out our bloghttp://www.tesora.com/blog Twitterhttps://twitter.com/tesoracorp Facebookhttps://www.facebook.com/tesoracorp LinkedInhttp://www.linkedin.com/company/parelastic 125 CambridgePark Drive, Suite 400, https://www.google.com/maps?q=125+Cambridge+Park+Drive,+Cambridge,+MAhl=ensll=42.036922,-71.683501sspn=3.422779,6.696167oq=125+cahnear=125+Cambridge+Park+Dr,+Cambridge,+Middlesex,+Massachusetts+02140t=mz=17 Cambridge, MA 02140https://www.google.com/maps?q=125+Cambridge+Park+Drive,+Cambridge,+MAhl=ensll=42.036922,-71.683501sspn=3.422779,6.696167oq=125+cahnear=125+Cambridge+Park+Dr,+Cambridge,+Middlesex,+Massachusetts+02140t=mz=17 4 Robert Speck Parkway, Suite 1500,https://www.google.com/maps?q=4+Robert+Speck+Parkway,+Suite+1500,+Mississauga,+ON,+Canada.+L4Z+1S1hl=ensll=42.395158,-71.145805sspn=0.006648,0.013078hnear=4+Robert+Speck+Pkwy+%231500,+Mississauga,+Peel+Regional+Municipality,+Ontario+L4Z+1S1,+Canadat=mz=17 Mississauga, ON, Canada. L4Z 1S1https://www.google.com/maps?q=4+Robert+Speck+Parkway,+Suite+1500,+Mississauga,+ON,+Canada.+L4Z+1S1hl=ensll=42.395158,-71.145805sspn=0.006648,0.013078hnear=4+Robert+Speck+Pkwy+%231500,+Mississauga,+Peel+Regional+Municipality,+Ontario+L4Z+1S1,+Canadat=mz=17 __ OpenStack Development Mailing 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] [stringfreeze] request for SFE
Finucane, Stephen wrote: Nova cores, I would like to request a SFE for the below fix: https://review.openstack.org/#/c/170190/ https://bugs.launchpad.net/nova/+bug/1438226 This change adds a useful error message to help users debug incompatibilities with some versions of a dependency (libvirt). Without this error message the change is of little use. Regards, Stephen Finucane PS: I can redirect this to the i18n mailing list if necessary. Looks like a valid trade-off to me. -- 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] I/O (PCIe) based NUMA scheduling
I understand that this feature automatically schedules the guest to be on a NUMA node to which the PCI device is associated. For a guest that spans multiple NUMA nodes, is the NUMA node information associated to PCI devices passed to the guest? Say a guest is configured to use 2 PCI devices(associated to numa nodes 0 and 1 on the host). The guest is also configured to have 2 numa nodes. I tried this with the latest version of openstack (master) and the numa_node information associated with the device shows up as -1 in the vm. cat /sys/class/net/eth1/device/numa_node -1 For such cases, knowing the numa node information in the VM would help applications choose the device based on the associated numa node.Is there any blueprint that addresses this issue? __ OpenStack Development Mailing 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] Utilizing the KMIP plugin
Hello Christopher, Just checking, but is that barbican-api.conf file located in your local system's /etc/barbican folder? If not that is the preferred place for local development. Modifying the copy that is in your local git repository will have no effect. Also, please double check that your local git repository's setup.cfg has a line like this in there (at/around #35): kmip_plugin = barbican.plugin.kmip_secret_store:KMIPSecretStore Thanks, John From: Christopher N Solis cnso...@us.ibm.commailto:cnso...@us.ibm.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, April 6, 2015 at 10:25 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [barbican] Utilizing the KMIP plugin Hello! Sorry to Kaitlin Farr for not responding directly to your e-mail. My openstack settings were misconfigured and I was not receiving e-mail from the dev mailing list. Thanks for looking into the issue. I double checked the permissions at the bottom of the kmip_plugin part in the barbican-api.conf file and they are set to 400. I would also like to note that I do not think the code ever actually entered the __init__ function of KMIPSecretStore. I put a breakpoint in the __init__ function but the debugger never gets open. The error occurs and returns without ever seeming to enter the init function. Here are the parts of the barbican-api.conf file that concern the kmip_plugin: . [secretstore] namespace = barbican.secretstore.plugin enabled_secretstore_plugins = kmip_plugin . [kmip_plugin] username = '**' password = '**' host = port = keyfile = '/etc/barbican/rootCA.key' certfile = '/etc/barbican/rootCA.pem' ca_certs = '/etc/barbican/rootCA.pem' ... Thank You!! Regards, Christopher Solis __ OpenStack Development Mailing 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] PTL Candidacy
confirmed On Mon, Apr 6, 2015 at 1:30 PM, Ben Swartzlander b...@swartzlander.org wrote: Hello all, I'm announcing my candidacy for Manila PTL for the Liberty release. I've been leading the Manila project since its inception back in 2013, and I'm excited and humbled by how much the community around the project has grown, especially during the last 6 months. If you go back and read my ML post from my last nomination, I set out a number of goals [1]. I think we have achieved as a team everything on that list. In particular I am most excited by the growth of the community, which has exceeded my hopes. Manila quality has come a long way, with greatly increased test coverage, and a significant number of bugs found a fixed. The primary technical goal for Kilo, which was to make Manila usable in a wider variety of deployment scenarios was met with our new driver_handle_share_servers config flag and multiple network plugin options. The thing that caught me most by surprise was how popular the mid-cycle meetup was. I made the mistake of assuming that it would be a small group and that there wouldn't be interest in a physical meetup. The meetup was well attended and a lot of great ideas came out of it. I want to make sure we plan ahead for the Liberty meetup so people who are able to travel have time to make plans, and I'd like to make the agenda more formal next time around so people joining remotely can schedule their time more effectively. I have a long list of technical content that I would like to see go into Liberty. The mid-cycle meetup added a bunch of new ideas, and there's still a big gap between what Manila can support and what Cinder (the project we forked from) now supports. I would like to catch up to Cinder, feature-wise, and also implement all of the shared-file-system-specific features we've been talking about but haven't gotten around to implementing yet (mount automation is a big one). There is way more work than we can get done during a single release, but with a bigger team I'm hopeful that we can deliver more features in Liberty than ever before. To this end I've been trying to grow the core team, with 2 recent additions, and I hope to grow it more. To address the concern that too many core team members are from a small number of companies, I'd like to propose a rule that changes require +2s from at least 2 companies, which should alleviate concerns about single companies shoving through unpopular changes, and I can also guarantee that the next core team nominations from me will be for people from companies not yet represented. I wish I could include my proposed list of Liberty features here, but unfortunately it's too long and not baked enough because we haven't quite finished Kilo enough to move on to Liberty planning (for me at least). I want to continue the themes we started in Kilo of quality, simplicity, and integrating with the rest of OpenStack. Look forward to my list of proposed features in the coming weeks and let's make Liberty the best release of Manila ever! [1] - http://lists.openstack.org/pipermail/openstack-dev/2014-September/047045.html -Ben Swartzlander __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Elizabeth Krumbach Joseph || Lyz || pleia2 __ OpenStack Development Mailing 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] PTL Candidacy
confirmed On Mon, Apr 6, 2015 at 9:57 AM, Dean Troyer dtro...@gmail.com wrote: I would like to announce my candidacy for OpenStackClient PTL. I started this project nearly three years ago in order to give CLI users a uniform experience in interacting with OpenStack clouds. OSC was recently the first project added as part of the new governance model. While response to OSC has always been good the active developer group has generally been small and development slower than we would have liked. I am now in a position to change that and step up the pace of development and broaden the contributor base. The future of OSC holds some interesting problems to solve, including adopting a single low-level API to provide the backend REST handlers and addressing the issue of installation and a multitude of dependencies. We have the introduction of a cloud/client configuration ability coming soon and client-side caching of tokens and other cloud data following after. There is also some refinement to make running in interactive mode more suitable as a Bash coprocess. And as always, keeping up with the project commands is still a top priority I believe there are certain areas where a strong guiding hand provides a better end result than only building on consensus, and user interface design consistency is one of those areas. So much so that I like to say the 'C' in OSC stands for 'consistency'. The rest of the backronym is left as an exercise to the reader. I would be honored to have your support. Thanks dt -- Dean Troyer dtro...@gmail.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Elizabeth Krumbach Joseph || Lyz || pleia2 __ OpenStack Development Mailing 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] BUG:Adding more tenants access to flavor with limited access causes already existing instance size in that tenant to Not available and this error pops up Error: Unable to retrieve
-- Forwarded message -- From: mad Engineer themadengin...@gmail.com Date: Tue, Apr 7, 2015 at 8:50 PM Subject: BUG:Adding more tenants access to flavor with limited access causes already existing instance size in that tenant to Not available and this error pops up Error: Unable to retrieve instance size information. To: openst...@lists.openstack.org openst...@lists.openstack.org Running Icehouse in Ubuntu 14.04 and Centos 6.6 (Both have this issue). Created a flavor Flavor 1 with only tenant A having access to it and there are 20 instances created from that flavor. Now I have added 2 more tenants to access Flavor 1 All the running instances in tenant A shows Error: Unable to retrieve instance size information. i can create new instances from that flavor A from tenant A but existing instances shows size as Not available Related to Bug: https://bugs.launchpad.net/nova/+bug/1366861 Can any one suggest workaround for this. Thanks __ OpenStack Development Mailing 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] Fixing the Nova Core Reviewer Frustration [was Re: [Nova] PTL Candidacy]
On Tue, 2015-04-07 at 11:27 +1000, Michael Still wrote: Additionally, we have consistently asked for non-cores to help cover the review load. It doesn't have to be a core that notices a problem with a patch -- anyone can do that. There are many people who do help out with non-core reviews, and I am thankful for all of them. However, I keep meeting people who complain about review delays, but who don't have a history of reviewing themselves. That's confusing and frustrating to me. I can understand why you're frustrated, but not why you're surprised: the process needs to be different. Right now the statement is that for a patch series to be accepted it has to have a positive review from a core plus one other, however the one other can be a colleague, so it's easy. The problem, as far as submitters see it, is getting that Core Reviewer. That's why so much frenzy (which contributes to your frustration) goes into it. And why all the complaining which annoys you. To fix the frustration, you need to fix the process: Make the cores more of a second level approver rather than a front line reviewer and I predict the frenzy to get a core will go down and so will core frustration. Why not require a +1 from one (or even more than one) independent (for some useful value of independent) reviewer before the cores will even look at it? That way the cores know someone already thought the patch was good, so they're no longer being pestered to review any old thing and the first job of a submitter becomes to find an independent reviewer rather than go bother a core. James __ OpenStack Development Mailing 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] Fixing the Nova Core Reviewer Frustration
On Tue, 2015-04-07 at 13:35 -0400, Anita Kuno wrote: On 04/07/2015 01:02 PM, James Bottomley wrote: On Tue, 2015-04-07 at 11:27 +1000, Michael Still wrote: Additionally, we have consistently asked for non-cores to help cover the review load. It doesn't have to be a core that notices a problem with a patch -- anyone can do that. There are many people who do help out with non-core reviews, and I am thankful for all of them. However, I keep meeting people who complain about review delays, but who don't have a history of reviewing themselves. That's confusing and frustrating to me. I can understand why you're frustrated, but not why you're surprised: the process needs to be different. Right now the statement is that for a patch series to be accepted it has to have a positive review from a core plus one other, however the one other can be a colleague, so it's easy. The problem, as far as submitters see it, is getting that Core Reviewer. That's why so much frenzy (which contributes to your frustration) goes into it. And why all the complaining which annoys you. To fix the frustration, you need to fix the process: Make the cores more of a second level approver rather than a front line reviewer and I predict the frenzy to get a core will go down and so will core frustration. Why not require a +1 from one (or even more than one) independent (for some useful value of independent) reviewer before the cores will even look at it? That way the cores know someone already thought the patch was good, so they're no longer being pestered to review any old thing and the first job of a submitter becomes to find an independent reviewer rather than go bother a core. James __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hi James: Since this is now an open thread and no longer has anything to do with Nova PTL candidacy or anyone else's PTL candidacy, I'm going to jump in here with a recommendation. Since you are familiar with Gerrit yourself and have a merged patch, perhaps you can spend some time between now and summit and review as many Nova (or the project of your choice) patches as you can to learn what life is like from the reviewers point of view. Thanks for the suggestion. However, I didn't make my initial recommendation based on not having some insight into what's going on. I'm SCSI Subsystem maintainer of Linux, meaning I act like an OpenStack core for all the patches that go into this subsystem. We recently hit a crisis point in Linux last year where I simply couldn't review all the patches and someone else took over to help out. He instituted a process whereby no patch got consideration until it had at least one other review and even though he's stepped back again, I find that adhering to this process brings my workload back to being manageable because I can just tell anyone bothering me about a patch to go away and find a reviewer. Once it has a reviewer (provided I trust them), I merely need to glance over it to verify no problems before including it in the git tree. I'm basing my recommendation directly on how this process has helped me continue to do my job in Linux. Now, I think it's fair game to argue about whether this would, or would not be applicable to OpenStack and whether the benefits we saw in Linux would be fully realized in a different environment. I do, though, think it's slightly unwise to dismiss out of hand experience gained in other projects, unless you truly believe OpenStack has nothing to learn from anyone else? James If you find it supportive to do so please help yourself to this blog post I wrote about reviewing an OpenStack patch: http://anteaya.info/blog/2013/03/21/reviewing-an-openstack-patch/ Thanks James, Anita. https://review.openstack.org/#/q/reviewer:%22James+Bottomley+%253Cjejbcan1%2540hansenpartnership.com%253E%22,n,z __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Zaqar] PTL Candidacy
Hi all, Flavio, thanks for submitting your candidacy for Zaqar. As one of the developers working on the Zaqar project, I wanted to say that your guidance will be truly appreciated for the next cycle. The status for the project is really good, and there is a lot to do, great ideas for new features, and many people that wants to help. We also have many Outreachy applicants interested in join Zaqar in the next cycle, so having your lead is very important for us. It's needless to say that you can count on the Zaqar team to make this happen and avoid burnout (if possible). All the best, Victoria 2015-04-07 13:02 GMT-03:00 Tristan Cacqueray tristan.cacque...@enovance.com : confirmed On 04/07/2015 05:35 AM, Flavio Percoco wrote: Greetings, You read it right, you've not burned out yet - I probably will. Here's a crazy idea, what if I run for 2 PTL positions on the projects I've been putting my focus on lately? Hopefully, by sending this out now, I'll be able to answer all your questions in time before the candidacy period closes. Before you jump out of your chair, pull your hair off and start asking: Is that even possible? Let me tell you that, as far as I can tell by reading our governance repo[0], it seems to be entirely legal. If you think it is not, please do let me know. Now, to my candidacy. During the Juno development cycle, I had the pleasure to be Zaqar's PTL. During this cycle, we managed to kick of complete - at least in an experimental version - some exciting features and we've also kicked off others - you can read more about that here[1]. We did that with a small team of old and new contributors, if it doesn't seem much to you, I'd love to invite you to our team and help us out. :D That said, I think our most important goal during Juno was incorporating the feedback we got from the community, after our last incubation attempt, in a way that doesn't compromise the project's goals but still brings in way more flexibility to the project. This will allow for the community (Zaqar's and OpenStack's) to finally adopt the project wherever it might be needed. Based on the above results and the fact that I believe the community hasn't seen enough (anything) of Zaqar yet, I'd like to throw my hat out there to be Zaqar's PTL for another cycle. Here are some things that I'd like us to do during this cycle: 1. Spread the word and improve our interaction with the overall community. We've spent lot of time heads down coding new features and working out the best way to deliver this project. I believe it's time to throw it out there and let it crash (if you know what I mean). 2. Restore/Improve our community activities by improving our communications through the openstack mailing list, restoring our weekly meetings and contributing back to other projects. 3. Keep improving our deployment story/tools. We've a draft of a puppet manifest that we need to complete, we've devstack support but we ought to bring it into our code base and extend it with other features that have been developed. 4. Keep our amazing mentoring story alive by helping new mentees to integrate with OpenStack, open source and obviously, Zaqar. Something this team should be proud of is that it's mentored new contributors since it was created. The above and more, I'd be honored to do together with the rest of the team. Now, to the obvious natural question: How will I be the PTL of 2 projects and get to the end of the cycle? Well, this definitely will require some changes from my side and my current focus that you'll see happen if I have the honor to be elected for both projects. Will I be burned out at the end of the cycle? Probably, but that's a price I'm willing to pay for these 2 projects and more importantly for OpenStack because I truly believe these projects play (or will play in the case of Zaqar) and important role in our ecosystem. In addition to the above, I must say that, thankfully enough, Zaqar is still not such a time consuming project from a PTL perspective and it's entirely feasible to be the PTL of these 2 projects and still do a good job - last famous words. In all seriousness, I'd be honored to serve for both projects and I hope you'll join me in this experiment. [0] https://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst [1] http://lists.openstack.org/pipermail/openstack-dev/2015-April/060446.html Cheers, Flavio -- @flaper87 Flavio Percoco __ OpenStack Development Mailing 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
[openstack-dev] [puppet] Meeting notes for April 7 and PTL update
Hi all, The minutes from today's meeting are here: http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-04-07-15.00.html One outcome of this meeting is that we plan to close the PTL nomination process on April 9, 2015 at 05:59 UTC. If you would like to nominate yourself for PTL of the puppet-openstack projects, please do so before then. Colleen (crinkle) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] how to send messages (and events) to our users
This could be extended to richer JSON events that include the stack, resources affected in the update, stats like num-deleted-resources or num-replaced-resources, autoscaling actions, and info about stack errors. Is there a way for users as-is to view those raw notifications, not just the indexed k/v pairs? from Ceilometer POV, currently, raw notifications are optionally stored (for auditing, postmortem analysis, etc...) but they are not queryable from the api (we don't support it as the performance will [arguably] suffer depending on the backend). the basic structure of an Event in Ceilometer is: id, timestamp, event_type, a list of traits (queryable k/v pairs pulled from notification), and raw (full json notifications) in Liberty, we intend on support action/alerting on events so maybe it's something we should collaborate on to ensure the right functionality is provided. 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/02/2015 02:26 PM, Joe Gordon wrote: So, let me take a step back here. I would like to see at least 2 to 3x more people in a given project to feel empowered and have badges, and make it possible for part time upstream developers to hold some of said badges. It sounds like you more or less agree with that goal. So how do you propose we get there? Because having 15 core reviewers for all of nova is just not cutting it. My $.02 on this: http://blog.leafe.com/the-core-deficiency/ - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJVJCG3AAoJEKMgtcocwZqLPfEQAJT2Xp1qDpPrhaL5ZM1QvyHP 1iGwTnt10ATH9vFWRmAAYucR3QGF8E0RQyFi2V5W/poRJpiuY+UiTaoqzOq3bXjQ 0IjSFo6AKN8z5igMog0Hp82dvuJe8C1VfxO2GP76MJjqdHT7CvXEmAdHzknRVmcB soWAMJ2W/V8Fn0niXzfHf/jN+LksxmNPzFm5YIaZbexsKw0zhYz3Y32LbX1Shffm 4FO/uTmLZqw5uvMlHZYb9RC5Hhe6AJ+53UxY4CUXnAAt2cWZYFTJuogw6hx3LBXQ Tc7NUUHrI1xLEyx5ZnLFesnuBnkbc4ER08OPgOIqcecy4UqGnVQfNmYvFNePjpq3 GD/T7bP3HYjZ3E4BsfrfIQDO2IjpC3yfSTWmTF9FJiVwhy8EFQd/w3kRztGpafPO 7y2K7irdk5AB0nsL0tM1nvTTBk0lYqXsgyvSWopaZCk/0LwxeUETOmKXeFPA6hgS r+/U2jJDCr2WjRbwbvPhuFWKVwf391LUnz3qrVhlUq3xQEY0N/+IBGb+7n0sc6hu V76S6jHmxkF7XWPXGP2E8BClvpCEjMToLEULLDYr5Xilvx2iqLyugEmDE9o3uBLi GSQcxsw70nhDheRldNEeJDxEv1ABvn7Kxn5UFX8RYNLVAdMaSBLlinHqBtOJ5T2E O5SroR+ltyB2f1n0UEGJ =ELkQ -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] Fixing the Nova Core Reviewer Frustration [was Re: [Nova] PTL Candidacy]
-Original Message- From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] Sent: 07 April 2015 19:03 To: Michael Still Cc: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] Fixing the Nova Core Reviewer Frustration [was Re: [Nova] PTL Candidacy] On Tue, 2015-04-07 at 11:27 +1000, Michael Still wrote: Additionally, we have consistently asked for non-cores to help cover the review load. It doesn't have to be a core that notices a problem with a patch -- anyone can do that. There are many people who do help out with non-core reviews, and I am thankful for all of them. However, I keep meeting people who complain about review delays, but who don't have a history of reviewing themselves. That's confusing and frustrating to me. I can understand why you're frustrated, but not why you're surprised: the process needs to be different. Right now the statement is that for a patch series to be accepted it has to have a positive review from a core plus one other, however the one other can be a colleague, so it's easy. The problem, as far as submitters see it, is getting that Core Reviewer. That's why so much frenzy (which contributes to your frustration) goes into it. And why all the complaining which annoys you. To fix the frustration, you need to fix the process: Make the cores more of a second level approver rather than a front line reviewer and I predict the frenzy to get a core will go down and so will core frustration. Why not require a +1 from one (or even more than one) independent (for some useful value of independent) reviewer before the cores will even look at it? That way the cores know someone already thought the patch was good, so they're no longer being pestered to review any old thing and the first job of a submitter becomes to find an independent reviewer rather than go bother a core. If I take a case that we were very interest in (https://review.openstack.org/#/c/129420/) for nested project quota, we seemed to need two +2s from core reviewers on the spec. There were many +1s but these did not seem to result in an increase in attention to get the +2s. Initial submission of the spec was in October but we did not get approval till the end of January. Unfortunately, we were unable to get the code into the right shape after the spec approval to make it into Kilo. One of the issues for the academic/research sector is that there is a significant resource available from project resources but these are time limited. Thus, if a blueprint and code commit cannot be completed within the window for the project, the project ends and resources to complete are no longer available. Naturally, rejections on quality grounds such as code issues or lack of test cases is completely reasonable but the latency time can extend the time to delivery significantly. Luckily, in this case, the people concerned are happy to continue to completion (and the foundation is sponsoring the travel for the summit too) but this would not always be the case. Tim James _ _ OpenStack Development Mailing 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 : Unable to authenticate with keystone V3 for Barbican curl command
Hi All ,
Could anyone please help me on this integration issue.
I am unable to authenticate with keystone V3 for Barbican curl command
.I have followed the procedure given in the following link :
https://github.com/cloudkeep/barbican/wiki/Integration-with-Keystone-V3-API
I was unable to authenticate with the keystone V3 even though the right
token was provided in the curl command
Please find the command to get the token and the curl command to post the
secret .
[root@keystone-versiontest ~]# openstack --insecure token issue *(Command
to get token from keystone v3)*
++--+
| Field | Value|
++--+
| expires| 2015-04-07T18:26:13.835641Z |
|* id | f28b93f27cce4bc09f9ac50d84bde736 |*
| project_id | 9d37f9ecc481422aa8ab53674cb82410 |
| user_id| e7d02ed8e7e64b01a1d66bb86ffa90d8 |
++--+
[root@keystone-versiontest ~]# curl -X POST -H
'content-type:application/json' -H 'X-Project-Id:12345' \
-H X-Auth-Token:*f28b93f27cce4bc09f9ac50d84bde736* -d '{payload:
my-secret-here, payload_content_type: text/plain}'
http://localhost:9311/v1/secrets
*Authentication required*[root@keystone-versiontest ~]#
The contents of the admin.opensrc file is as given below :
[root@keystone-versiontest ~]# cat admin.openrc
export OS_USERNAME=admin
export OS_TENANT_NAME=admin
export OS_PASSWORD=admin
export OS_AUTH_URL=https://169.54.204.69:35357/v3
export OS_REGION_NAME=RegionOne
export OS_IDENTITY_API_VERSION=3
export OS_USER_DOMAIN_ID=default
export OS_PROJECT_DOMAIN_ID=default
And also I have attached the barbican-api-paste.ini and
barbican-admin-paste.ini files.
I would like to know why the curl command for posting the secret is not
geting authenticated with Keystone V3
Any help would highly be appreciated.
--
*Thanks and Regards,*
*Asha Seshagiri*
barbican-api-paste.ini
Description: Binary data
barbican-admin-paste.ini
Description: Binary data
__
OpenStack Development Mailing 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.utils] allow strutils.mask_password to mask keys dynamically
On 03/20/2015 11:43 AM, Doug Hellmann wrote: Excerpts from Matthew Van Dijk's message of 2015-03-20 15:06:08 +: I’ve come across a use case for allowing dynamic keys to be made secret. The hardcoded list is good for common keys, but there will be cases where masking a custom value is useful without having to add it to the hardcoded list. Can you be more specific about what that case is? My concern with making some keys optional is that we'll have different security behavior in different apps, because some will mask values that are not masked in other places. Part of the point of centralizing behaviors like this is to keep them consistent across all of the projects. I think I may have been the first to suggest this way back when, and at the time my thought was that it's weird for consumers of a library to have to push a change into the library itself for things that might be pretty specific to their application. That said, the oslo libs are not entirely normal in this respect. They're also an opinionated set of modules that make it easy to do things The OpenStack Way, so in that respect I agree that it's probably good to keep the list of masked keys the same across applications. So I think at this point I'm backing off my stance that this is something we _should_ do for sure, and will take the view that it's something we _could_ do if a compelling argument is made. /2 cents I propose we add an optional parameter that is a list of secret_keys whose values will be masked. There is concern that this will lead to differing levels of security. But I disagree as either the message will be masked before passing on or mask_password will be called. In this case the developer should be aware of the incoming data and manually mask it. Keeping with a hardcoded list discourages use of the function. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] how to send messages (and events) to our users
Tooling in general seems to be moving towards richer event data as well.
The logging tools (Loggly/Logstash/PaperTrail/zillions of others) are
intended to take your unstructured logs and turn them into events, so
why not have Heat output structured events that we can present to the
user with Ceilometer rather than sending log lines (through syslog or
otherwise) and using tooling to reassemble them into events later.
The trend in the monitoring space seems to be:
1. Alarms are issued from Metrics as Events.
(events can issue alarms too, but conventional alarming is metric based)
2. Multiple events are analyzed to produce Metrics (stream processing)
3. Go to Step 1
TL;DR: I think what we really want is a place to send and react to
*events*. Logs are a way to do that, of course, but the Ceilometer way
sounds pretty attractive.
The difference is structured vs. unstructured data. Elasticsearch-based
solutions tend to ignore structure by looking at keywords. Some solutions,
like TopLog, infer a structure by gleaning regexs from logs.
Events start as structured data. More so, we're looking at establishing
AVRO-based schema definitions on top of these events (slow progress).
If anything we should consider changing the logging library to use structured
messages. Specifically:
log(The %(foo)s did %(thing)s % {'foo':'x', 'thing':'action'})
it would be
log({'message':The %(foo)s did %(thing)s, 'foo':'x', 'thing':'action'})
Which can still be formatted for conventional logs, but also sent as a
notification or as a higher-level structure to things like ES, TopLog, etc.
The driver can decide.
* CloudWatch has you send unstructured log messages, then build filters
to parse them into quantifiable events, then set alarms on those metrics.
Having to build filters is a relatively error-prone approach compared to the
methods described above.
[snip]
The Fujitsu team have already added logging support to Monasca (with an
elasticsearch backend) and HP is currently adding StackTach.v3 support for
notification-event conversion as well as our Winchester event stream
processing engine. Also, this is based on Kafka vs. RabbitMQ, which has better
scaling characteristics for this kind of data.
This could be extended to richer JSON events that include the stack,
resources affected in the update, stats like num-deleted-resources or
num-replaced-resources, autoscaling actions, and info about stack errors.
Some of these sound more like a metrics than notifications. We should be
careful not to misuse the two.
Is there a way for users as-is to view those raw notifications, not just
the indexed k/v pairs?
In StackTach.v3 we ship the raw notifications to HDFS for archiving, but
expose the reduced event via the API. The message-id links the two.
Lots more here: http://www.stacktach.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Barbican : Unable to reterieve asymmetric order request for rsa algorithm type
Hello Asha,
The root error here is that the stock plugin does not support generating 256
bit length asymmetric keys, rather only 1024, 2048 or 4096. Ideally you would
have received a validation error when you POST-ed the order, but we have not
yet integrated plugins with our validation process.
FYI, this link [1] shows the method that guides which algorithm parameters are
supported by the default plugin.
Thanks for you patience,
John
[1]
https://github.com/openstack/barbican/blob/master/barbican/plugin/crypto/simple_crypto.py#L194
From: Asha Seshagiri asha.seshag...@gmail.commailto:asha.seshag...@gmail.com
Date: Tuesday, April 7, 2015 at 12:23 PM
To: openstack-dev
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org,
Paul Kehrer paul.keh...@rackspace.commailto:paul.keh...@rackspace.com, Adam
Harwell adam.harw...@rackspace.commailto:adam.harw...@rackspace.com
Cc: John Wood john.w...@rackspace.commailto:john.w...@rackspace.com,
Reller, Nathan S.
nathan.rel...@jhuapl.edumailto:nathan.rel...@jhuapl.edu, Douglas Mendizabal
douglas.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com,
a...@redhat.commailto:a...@redhat.com
a...@redhat.commailto:a...@redhat.com, Alexis Lee
alex...@hp.commailto:alex...@hp.com
Subject: Re: Barbican : Unable to reterieve asymmetric order request for rsa
algorithm type
Hi All ,
I would like someone to provide the pointer so that I would look into this
issue and confirm whether asymmetric order retrieval would be supported in
Barbican.
Any help would be appreciated!
Thanks in advance,
Asha Seshagiri
On Fri, Apr 3, 2015 at 11:06 AM, Asha Seshagiri
asha.seshag...@gmail.commailto:asha.seshag...@gmail.com wrote:
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.commailto: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
--
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] Barbican : Unable to authenticate with keystone V3 for Barbican curl command
Hello Asha,
We are in the process of migrating our documentation to Sphinx, so I'd suggest
following this link for Keystone configuration options [1].
I'd also note that a CR is pending with a bit more details to setup via a
Docker Keystone here [2].
Thanks,
John
[1] http://docs.openstack.org/developer/barbican/setup/keystone.html
[2] https://review.openstack.org/#/c/169114/
From: Asha Seshagiri asha.seshag...@gmail.commailto:asha.seshag...@gmail.com
Date: Tuesday, April 7, 2015 at 1:34 PM
To: openstack-dev
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: John Wood john.w...@rackspace.commailto:john.w...@rackspace.com,
Reller, Nathan S.
nathan.rel...@jhuapl.edumailto:nathan.rel...@jhuapl.edu, Douglas Mendizabal
douglas.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com,
a...@redhat.commailto:a...@redhat.com
a...@redhat.commailto:a...@redhat.com, Paul Kehrer
paul.keh...@rackspace.commailto:paul.keh...@rackspace.com, Adam Harwell
adam.harw...@rackspace.commailto:adam.harw...@rackspace.com, Alexis Lee
alex...@hp.commailto:alex...@hp.com
Subject: Barbican : Unable to authenticate with keystone V3 for Barbican curl
command
Hi All ,
Could anyone please help me on this integration issue.
I am unable to authenticate with keystone V3 for Barbican curl command .I
have followed the procedure given in the following link :
https://github.com/cloudkeep/barbican/wiki/Integration-with-Keystone-V3-API
I was unable to authenticate with the keystone V3 even though the right token
was provided in the curl command
Please find the command to get the token and the curl command to post the
secret .
[root@keystone-versiontest ~]# openstack --insecure token issue (Command to get
token from keystone v3)
++--+
| Field | Value|
++--+
| expires| 2015-04-07T18:26:13.835641Z |
| id | f28b93f27cce4bc09f9ac50d84bde736 |
| project_id | 9d37f9ecc481422aa8ab53674cb82410 |
| user_id| e7d02ed8e7e64b01a1d66bb86ffa90d8 |
++--+
[root@keystone-versiontest ~]# curl -X POST -H 'content-type:application/json'
-H 'X-Project-Id:12345' \
-H X-Auth-Token:f28b93f27cce4bc09f9ac50d84bde736 -d '{payload:
my-secret-here, payload_content_type: text/plain}'
http://localhost:9311/v1/secrets
Authentication required[root@keystone-versiontest ~]#
The contents of the admin.opensrc file is as given below :
[root@keystone-versiontest ~]# cat admin.openrc
export OS_USERNAME=admin
export OS_TENANT_NAME=admin
export OS_PASSWORD=admin
export OS_AUTH_URL=https://169.54.204.69:35357/v3
export OS_REGION_NAME=RegionOne
export OS_IDENTITY_API_VERSION=3
export OS_USER_DOMAIN_ID=default
export OS_PROJECT_DOMAIN_ID=default
And also I have attached the barbican-api-paste.ini and
barbican-admin-paste.ini files.
I would like to know why the curl command for posting the secret is not geting
authenticated with Keystone V3
Any help would highly be appreciated.
--
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] [Ironic] How to deal with microversions in 3rdparty tools
On 04/07/2015 07:25 AM, Dmitry Tantsur wrote: On 04/07/2015 03:15 PM, Jim Rollenhagen wrote: I’m not sure that recommending one or the other is best. We should lay out the options (as you just did) and let folks decide what works best for them. For things like discoverd, where you have many users, perhaps you should allow the user to pass a version (for example, option 2 depends on the user running an Ironic version that has a 1.6 at all — they could be at 1.4). For things like the dashboard my team runs internally, we’ll be passing “latest” to the API (we don’t use the client). We know we can move fast, and our dashboard being broken for a short time following a deploy isn’t the end of the world. Allowing a user to set microversions looks to me kind of misuse of them. E.g. a user setting 1.8 does not mean discoverd will start supporting it actually. And I can't get any guarantees about 1.4 as well - I never tested it. So it's really about whether to hard code or not. I'm not familiar with discoverd, but if you consume the nova API messages then I don't think you can allow arbitrary microversions since new ones can break backwards compatibility. Could you cap what the user is allowed to specify as the highest supported microversion that was supported by discoverd at the time of the discoverd release? Chris __ OpenStack Development Mailing 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] Fixing the Nova Core Reviewer Frustration
On 04/07/2015 01:02 PM, James Bottomley wrote: On Tue, 2015-04-07 at 11:27 +1000, Michael Still wrote: Additionally, we have consistently asked for non-cores to help cover the review load. It doesn't have to be a core that notices a problem with a patch -- anyone can do that. There are many people who do help out with non-core reviews, and I am thankful for all of them. However, I keep meeting people who complain about review delays, but who don't have a history of reviewing themselves. That's confusing and frustrating to me. I can understand why you're frustrated, but not why you're surprised: the process needs to be different. Right now the statement is that for a patch series to be accepted it has to have a positive review from a core plus one other, however the one other can be a colleague, so it's easy. The problem, as far as submitters see it, is getting that Core Reviewer. That's why so much frenzy (which contributes to your frustration) goes into it. And why all the complaining which annoys you. To fix the frustration, you need to fix the process: Make the cores more of a second level approver rather than a front line reviewer and I predict the frenzy to get a core will go down and so will core frustration. Why not require a +1 from one (or even more than one) independent (for some useful value of independent) reviewer before the cores will even look at it? That way the cores know someone already thought the patch was good, so they're no longer being pestered to review any old thing and the first job of a submitter becomes to find an independent reviewer rather than go bother a core. James __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hi James: Since this is now an open thread and no longer has anything to do with Nova PTL candidacy or anyone else's PTL candidacy, I'm going to jump in here with a recommendation. Since you are familiar with Gerrit yourself and have a merged patch, perhaps you can spend some time between now and summit and review as many Nova (or the project of your choice) patches as you can to learn what life is like from the reviewers point of view. If you find it supportive to do so please help yourself to this blog post I wrote about reviewing an OpenStack patch: http://anteaya.info/blog/2013/03/21/reviewing-an-openstack-patch/ Thanks James, Anita. https://review.openstack.org/#/q/reviewer:%22James+Bottomley+%253Cjejbcan1%2540hansenpartnership.com%253E%22,n,z __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Barbican : Unable to reterieve asymmetric order request for rsa algorithm type
Hi All ,
I would like someone to provide the pointer so that I would look into this
issue and confirm whether asymmetric order retrieval would be supported in
Barbican.
Any help would be appreciated!
Thanks in advance,
Asha Seshagiri
On Fri, Apr 3, 2015 at 11:06 AM, Asha Seshagiri asha.seshag...@gmail.com
wrote:
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*
--
*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] Fixing the Nova Core Reviewer Frustration [was Re: [Nova] PTL Candidacy]
On Tue, Apr 7, 2015 at 10:02 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Tue, 2015-04-07 at 11:27 +1000, Michael Still wrote: Additionally, we have consistently asked for non-cores to help cover the review load. It doesn't have to be a core that notices a problem with a patch -- anyone can do that. There are many people who do help out with non-core reviews, and I am thankful for all of them. However, I keep meeting people who complain about review delays, but who don't have a history of reviewing themselves. That's confusing and frustrating to me. I can understand why you're frustrated, but not why you're surprised: the process needs to be different. Right now the statement is that for a patch series to be accepted it has to have a positive review from a core plus one other, however the one other can be a colleague, so it's easy. The problem, as far as submitters see it, is getting that Core Reviewer. That's why so much frenzy (which contributes to your frustration) goes into it. And why all the complaining which annoys you. To fix the frustration, you need to fix the process: Make the cores more of a second level approver rather than a front line reviewer and I predict the frenzy to get a core will go down and so will core frustration. Why not require a +1 from one (or even more than one) independent (for some useful value of independent) reviewer before the cores will even look at it? That way the cores know someone already thought the patch was good, so they're no longer being pestered to review any old thing and the first job of a submitter becomes to find an independent reviewer rather than go bother a core. ++, I actually already prefer to focus my reviews on patches that already have a +1. We have been using a trivial patch monkey process (see the bottom of https://etherpad.openstack.org/p/kilo-nova-priorities-tracking) that is similar to this with great results already. James __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] how to send messages (and events) to our users
On 04/07/2015 11:34 AM, Sandy Walsh wrote:
log({'message':The %(foo)s did %(thing)s, 'foo':'x', 'thing':'action'})
I pity the foo that did that thing.
-jay
__
OpenStack Development Mailing 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] Question on documentation reviews
On 04/07/2015 12:58 PM, Luis Pabon wrote: Hi guys, I have been reviewing https://review.openstack.org/#/c/171166/, but I am concerned that I provided more of a hindrance than assistance. Instead I would like to propose the method used by Swift for document reviews, where reviewers provide a patch to the author as in https://review.openstack.org/#/c/169990 . What do you think? Makes sense to me. We should definitely discuss this at the weekly meeting, but it seems like for certain types of edits it would be dramatically more efficient. I can think of 3 possible issues: 1) If we allow this, then authors will have to be careful about pulling the lateset patchset from gerrit before they make their changes, to avoid accidentally clobbering changes from other authors. 2) Reviewers would need to talk to the original author before pushing another patchset in case the original author was working on a second draft or responding to comments from other reviews -- the reviewer wouldn't want to clobber the original's author's unsubmitted work. 3) Presumably for small edits, the existing scheme is still more efficient, so reviewers will have to make a judgement call whether to leave comments or push a patch. We'd need guidelines to cover the above 3 situations. -Ben - Luis __ OpenStack Development Mailing 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] Fixing the Nova Core Reviewer Frustration [was Re: [Nova] PTL Candidacy]
On Tue, 2015-04-07 at 18:12 +, Tim Bell wrote: -Original Message- From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] Sent: 07 April 2015 19:03 To: Michael Still Cc: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] Fixing the Nova Core Reviewer Frustration [was Re: [Nova] PTL Candidacy] On Tue, 2015-04-07 at 11:27 +1000, Michael Still wrote: Additionally, we have consistently asked for non-cores to help cover the review load. It doesn't have to be a core that notices a problem with a patch -- anyone can do that. There are many people who do help out with non-core reviews, and I am thankful for all of them. However, I keep meeting people who complain about review delays, but who don't have a history of reviewing themselves. That's confusing and frustrating to me. I can understand why you're frustrated, but not why you're surprised: the process needs to be different. Right now the statement is that for a patch series to be accepted it has to have a positive review from a core plus one other, however the one other can be a colleague, so it's easy. The problem, as far as submitters see it, is getting that Core Reviewer. That's why so much frenzy (which contributes to your frustration) goes into it. And why all the complaining which annoys you. To fix the frustration, you need to fix the process: Make the cores more of a second level approver rather than a front line reviewer and I predict the frenzy to get a core will go down and so will core frustration. Why not require a +1 from one (or even more than one) independent (for some useful value of independent) reviewer before the cores will even look at it? That way the cores know someone already thought the patch was good, so they're no longer being pestered to review any old thing and the first job of a submitter becomes to find an independent reviewer rather than go bother a core. If I take a case that we were very interest in (https://review.openstack.org/#/c/129420/) for nested project quota, we seemed to need two +2s from core reviewers on the spec. There were many +1s but these did not seem to result in an increase in attention to get the +2s. Initial submission of the spec was in October but we did not get approval till the end of January. Unfortunately, we were unable to get the code into the right shape after the spec approval to make it into Kilo. One of the issues for the academic/research sector is that there is a significant resource available from project resources but these are time limited. Thus, if a blueprint and code commit cannot be completed within the window for the project, the project ends and resources to complete are no longer available. Naturally, rejections on quality grounds such as code issues or lack of test cases is completely reasonable but the latency time can extend the time to delivery significantly. Luckily, in this case, the people concerned are happy to continue to completion (and the foundation is sponsoring the travel for the summit too) but this would not always be the case. So I think you're telling me that my proposed process would elongate the submission window and this would cause more stuff to drop because of the fixed timeframes people have to get stuff in? I think I have to admit to that, but would like to propose some refinements based on the analysis below. There were 35 patch sets in this review spanning a time period from 18 October to 21 Jan, when it was included. Up to patch set 17, the non-core reviews were mostly -1. From 17-27 there was some back and forth satisfying various reviewer comments and updating the blueprint. And from 28-34 the comments were getting more positive. 35 was the true OK point (except that gerrit kicked it out for a merge problem) and 36 was the accepted code. Under the process I proposed, the cores wouldn't have got involved until somewhere around patch set 18-20; I don't think this would cause anything to lengthen (patch set 20 was Dec 13). However, looking at the history, the refinements I would suggest are no -1s to pass to the cores, so they wouldn't actually get involved until patch set 26. If I look at the history, I also see some reviewers dropping out once their concerns and review comments have been addressed (after giving a +1), so the other thing I'd suggest is that instead of erasing the review history on each patch submission, it carries over (at least the -1 and +1) so you don't have to wait a while for a consensus to form (reviewers would, of course, be able to alter their votes at any time). The pressure is thus on the submitter to make the changes to switch every original -1 to a +1. James __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [nova] [stringfreeze] request for SFE
I am ok with this change too, which now has two +2's. If someone doesn't object in the next few hours I will merge the change. Michael On Wed, Apr 8, 2015 at 1:46 AM, Thierry Carrez thie...@openstack.org wrote: Finucane, Stephen wrote: Nova cores, I would like to request a SFE for the below fix: https://review.openstack.org/#/c/170190/ https://bugs.launchpad.net/nova/+bug/1438226 This change adds a useful error message to help users debug incompatibilities with some versions of a dependency (libvirt). Without this error message the change is of little use. Regards, Stephen Finucane PS: I can redirect this to the i18n mailing list if necessary. Looks like a valid trade-off to me. -- 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 -- Rackspace Australia __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
