Re: [Openstack] Propose to make Monsyne Dragon a nova core developer
+1! -- *From:* openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net[openstack-bounces+sandy.walsh= rackspace@lists.launchpad.net] on behalf of Matt Dietz [ matt.di...@rackspace.com] *Sent:* Monday, February 06, 2012 6:48 PM *To:* openstack@lists.launchpad.net *Subject:* [Openstack] Propose to make Monsyne Dragon a nova core developer Hey guys, Dragon has really stepped up lately on reviewing patches into Nova, and has a ton of knowledge around Nova proper, so I propose he be added to Nova core. I think he'd be a great addition to the team. Matt ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal to add Kevin Mitchell to nova-core
+1! Vek has absolutely stepped up and started doing quite few reviews, so I'd like to nominate him to be added to nova-core. Waldon ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal to add Johannes Erdfelt to nova-core
+1! I'd like to nominate Johannes for nova-core, as he has definitely been doing a good number of reviews lately. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposed amendment to HACKING
I prefer how the separate lines look, but it results in having leading/trailing whitespaces in the docstring. This may not be an issue, but it's something I've had to work around in the past. On Fri, Oct 21, 2011 at 12:37 PM, Jay Pipes jaypi...@gmail.com wrote: ++ I also believe the requirements to: a) Have a single-line 80 characters brief description AND a long description b) Start the description on the same line as the beginning are silly. I think this: This is a description, long or short, of what the thing does. It doesn't have to have any particular length or lack of length :param some_param: Description of param Is more readable than: This is a description, artificially limited to 80 characters for som This is a longer description that doesn't really need to be here. :param some_param: Description of param -jay On Fri, Oct 21, 2011 at 1:29 PM, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: Our HACKING includes this requirement for multiline docstrings: [...] After you have finished your descriptions add an extra newline and close the quotations. I propose that we remove this line and requirement from HACKING. We don't have to adjust all the docstrings to remove an extraneous space, but we should not require that it be here. Below is my defense: This requirement has never made sense to me, and there does seem to be some disagreement within nova about following this. So, for more insight, I went and read PEP 257, and discovered this rationale: The BDFL [3] recommends inserting a blank line between the last paragraph in a multi-line docstring and its closing quotes, placing the closing quotes on a line by themselves. This way, Emacs' fill-paragraph command can be used on it. (The indicated footnote is just an explanation of the term BDFL.) So, the first point I want to make is that this was a recommendation of PEP 257, rather than a requirement. The second point is that it was due to a limitation of the fill-paragraph command of a single editor. And the third point is that the editor in question, which happens to be my editor of choice, no longer has this limitation, at least in recent versions--fill-paragraph on docstrings terminated by triple-quotes ignores the triple-quotes. Therefore, I believe the recommendation no longer has any substance behind it, and so it should no longer be required of HACKING-conforming code for nova. -- Kevin L. Mitchell kevin.mitch...@rackspace.com This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API v1.0 Removal from Nova
++ On Tue, Oct 11, 2011 at 3:59 PM, Brian Waldon brian.wal...@rackspace.comwrote: I would like to propose we remove our implementation of OSAPI v1.0 from Nova for the following reasons: 1) Our implementation is incomplete, and there are no (visible) plans to complete it. Shared IP Groups and Backup Schedules have been unimplemented since I started on the project. 2) The v1.1 spec is not backwards-compatible with v1.0. I would like minor versions to be backwards compatible as we move forward, so I see v1.0 as something we need to just get rid of. 3) As we are trying to complete the v1.1 implementation, we are running into problems created by having to support v1.0 (specifically image and server uuids). 4) Our implementation of v1.0 and v1.1 within the same modules have caused us to compromise code quality. Working on the controllers (specifically servers) is a royal pain. I've already done the work of removing v1.0 from the code, and here's the review of my branch: https://review.openstack.org/840. I think it makes a lot of sense for the community to focus on making our v1.1 implementation solid, rather than constantly worrying about how we are affecting v1.0. If this is something we don't want to do, I would love to hear why :) Waldon ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Improving meetbot reports (was Re: Community metrics, developers' engagement)
This would make for a perfect pyhole plugin. https://github.com/jk0/pyhole /shameless plug On Sep 27, 2011, at 7:56 PM, John Dickinson m...@not.mn wrote: Taking a recent example, I think there is a big difference between http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-09-06-20.03.html and http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-09-06-20.03.log.html. The first is too short, and the second is too long. The best thing I can come up with to describe what would be better (a midpoint) is a journalistic report of what happened at the meeting. Something with more info than what meetbot provides (3 votes, 2 decisions, jbryce talked 54 times, etc) but more clear than the IRC logs (holy great wall of text, Batman!). Meetbot's summaries are precise, but they have a non-human flavor to them, and they are only as good at the moderator for the meeting. The goal (as I understand it) of having all the meetings in the open is to make the decision-making process transparent and accessible. The current setup meets the letter of the law, but perhaps not the spirit. --John On Sep 27, 2011, at 7:08 PM, Stefano Maffulli wrote: On Mon, 2011-09-26 at 12:51 -0500, John Dickinson wrote: I too would like to see official community and PPB meeting summaries. Ideally, I think it'd be nice for the summaries to be written by someone not involved in the discussion[1], but that wouldn't be required. Something between what the meetbot produces and the raw IRC logs would be nice. I'm very undecided about this as I don't know how this can be achieved. Nice summaries from IRC discussions are not only very hard to produce but also may introduce mistakes in the reports. If meetbot reports are not sufficiently intelligible we should think about ways to improve them. Or adopt Apache's policy of if the discussion was not on the mailing list it didn't happen. Lets start by clearly identifying the problem: What are the major pain points of meetbot reports? /stef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal to add Chris Behrens to nova-core
+1 for sure On Thu, Sep 15, 2011 at 4:13 PM, Brian Waldon brian.wal...@rackspace.comwrote: Chris (comstud) has been a great help with reviews lately and has quite a bit of knowledge of the system overall. I think he would add a great amount to the team, so I'm proposing we add him to nova-core. Brian Waldon ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] A possible alternative to Gerrit ...
On Wed, Sep 7, 2011 at 6:54 AM, Soren Hansen so...@linux2go.dk wrote: The critical point has never been whether we could reliably detect people's votes (even though I really dislike parsing free-form text to extract critical information like this). Even though Launchpad offers voting information in a structured manner, we *intentionally* don't auto-approve things there as soon as they have +2. Sometimes there are simply reasons why things shouldn't get merged even though they have two approves. If there's already one +1, but someone specific (someone with domain specific knowledge, a release team member, etc) needs to sign off on it as well, I still want to be able to say that I've reviewed it and approve of it, without causing it to get merged. We also want to be able to review features and vote on them even during freeze times without causing them to get merged. Couldn't we just add an extra keyword like '!approved' that Hubcap would only acknowledge from Core members? Unless that keyword is present, no matter how many '!lgtm's are there, Hubcap will not attempt a merge. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] A possible alternative to Gerrit ...
On Wed, Sep 7, 2011 at 10:59 AM, Jay Pipes jaypi...@gmail.com wrote: On Wed, Sep 7, 2011 at 11:42 AM, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: On Wed, 2011-09-07 at 11:24 -0400, Jay Pipes wrote: In addition, this doesn't prevent anyone on the core team from doing a straight close and merge of the pull request into trunk, potentially breaking trunk. So far as I know, there's no requirement that someone have merge authority on a project in order to comment on pull requests. Do cores have direct access to the openstack repos right now, and if they do, what's to stop them from merging pull requests into trunk? No. Gerrit and Jenkins own the canonical repos, and that's the whole point. I think cores are smart enough to follow the procedures laid down, and if they can't, well, they need to not be cores. I repeat my previous statement about humans being poor gatekeepers compared to automated enforceable policies. -jay Could make the default branch on github 'develop' so all Pull Requests would default to there, and let Hubcap/RoundAbout be the gatekeeper of master? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] A possible alternative to Gerrit ...
I don't intend to fan the fumes here, but I think the point we are trying to make is that the decision to use Gerrit was made before most of the community was even aware of it -- much less having a chance to come up with a solution like Sandy did (which, IMHO, is far more practical than the Gerrit workflow). How much more resistance will it take before we can consider an alternative? Would a poll be out of the question? On Sep 3, 2011, at 3:50 PM, Thierry Carrez thie...@openstack.org wrote: Jay Payne wrote: Can we dial down the drama a bit?It's things like this that will discourage people from submitting new ideas. Calling just the introduction of a new idea a revolt is a diservice to the community. Well, maybe revolt is not the best term, but this is about resisting the transition to Gerrit -- one can only regret that this new idea wasn't introduced in the previous months, while the Gerrit solution was still under development and while we hadn't start transitioning core projects to that new system. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Why are we using github again?
++ Either we should use github or we shouldn't (until it meets our requirements). On Aug 26, 2011, at 12:29 PM, Johannes Erdfelt johan...@erdfelt.com wrote: I'm struggling to find a reason why the Openstack project is using github. The use of Gerrit and other tools has reduced github to being just a pretty way to view a git repository. We can't use the github workflow of forking the repository, since that confuses the tools for Gerrit. There's workarounds, but they are awkward. We can't use pull requests since we have Gerrit for that purpose. We can't use bug tracking since we have Launchpad for that purpose. So what value is github bringing to the development process? I'll tell you that it's confusing to say we're using github, except for all of the features it provides beyond a web interface to view the repository. It seems like Openstack could host it's own git repository and avoid a lot of confusion to the people expecting github style workflow. JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Melange Integration
Good afternoon, We've just submitted a merge proposal to begin the process of getting Melange into Nova: https://code.launchpad.net/~raxnetworking/nova/melange/+merge/71917 This is a very large chunk of code that will no doubt generate many great ideas and discussions. We're not set in any particular way to do this, so we would love to hear any feedback the community has to offer. The only requirement is it has to be a standalone service. Many thanks, -jk0 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Adding new dependencies to OS projects
Hello, It was decided in our weekly OpenStack meeting that from this point forward, us developers should make a quick announcement on this ML whenever adding new dependencies to any OS project -- preferably *before* your branch merges in trunk. This should make all our jobs a little easier. :) Thanks! -jk0 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Jenkins Job Configuration
Works great! On Thu, Jul 14, 2011 at 12:35 PM, Monty Taylor mord...@inaugust.com wrote: This has now been installed and activated. Anonymous users should be able to read the config of any job now. I've got admin access, so it's kinda of hard to test - would someone mind verifying that they can, in fact, see the job configs? Thanks! Monty On 07/14/2011 11:50 AM, Alexander Sakhnov wrote: Hi, there is a plugin for Jenkins that extends standart permission matrix. http://wiki.hudson-ci.org/**display/HUDSON/Extended+Read+** Permission+Pluginhttp://wiki.hudson-ci.org/display/HUDSON/Extended+Read+Permission+Plugin Maybe this would help. On Thu, Jul 14, 2011 at 7:27 PM, adrian_f_sm...@dell.com mailto:Adrian_F_Smith@dell.**com adrian_f_sm...@dell.com wrote: That something will likely be a drop of a bunch of xml files That would be perfect. Thanks Monty. Adrian -Original Message- From: openstack-bounces+adrian_f_**smith=dell.com http://dell.com@lists.**launchpad.net http://lists.launchpad.net http://lists.launchpad.net [mailto:openstack-bounces+**adrian_f_smithopenstack-bounces%2Badrian_f_smith mailto:openstack-bounces%**2Badrian_f_smithopenstack-bounces%252Badrian_f_smith =dell.com http://dell.com@lists.**launchpad.net http://lists.launchpad.net http://lists.launchpad.net] On Behalf Of Monty Taylor Sent: Thursday, July 14, 2011 4:01 PM To: openstack@lists.launchpad.net mailto:openstack@lists.** launchpad.net openstack@lists.launchpad.net Subject: Re: [Openstack] Jenkins Job Configuration Hi! We're working on a decent solution for this. Jenkins itself does not have a setting which allows you to see the job config without also giving you access to edit it. (fail) However, it's been on my todo list to a) just publish these somewhere or b) even better, an easy way for you to spin up an identical jenkins (albeit one which does not publish tarballs) I'm going to move a) up on my list and see if I can't get you something today. That something will likely be a drop of a bunch of xml files but it's at least something. :) Monty On 07/14/2011 09:30 AM, adrian_f_sm...@dell.com wrote: Would it be possible to see the individual configuration files for the jobs running on http://jenkins.openstack.org? __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.**launchpad.netopenstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.**launchpad.netopenstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.**launchpad.netopenstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp -- Best regards, Alexander Sakhnov __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal for Brian Lamar to join Nova-Core
+1 On Tue, May 31, 2011 at 3:16 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: While I was checking branch merges, I noticed that Brian Lamar (blamar), is not listed as a nova-core developer. This is most definitely a travesty, as he has been one of the most prolific coders/reviewers over the past few months. So I'm proposing that he is added as a nova-core member. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] python-novaclient vs. python-openstack.compute
In the mean time, I'm working on addressing one of Sandy's issues by making the client less chatty. On Wed, May 18, 2011 at 10:35 AM, Sandy Walsh sandy.wa...@rackspace.comwrote: Cool ... thanks Gabe. I agree (and to Ed's point) that having to depend on an external source for close to rock-face development is too risky and that there are other ways to keep honest. Once we nail this down, perhaps having a side discussion about what a new client library might look like might be useful regardless. -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net[openstack-bounces+sandy.walsh= rackspace@lists.launchpad.net] on behalf of Gabe Westmaas [ gabe.westm...@rackspace.com] Sent: Wednesday, May 18, 2011 11:53 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] python-novaclient vs. python-openstack.compute Hey Sandy, We hadn't shifted our focus over to the client yet - our assumption had been that the best course would be to version the existing library and move forward. However, that was definitely an assumption and if people have experience that says maybe we should explore a new client tied more closely with nova, then we should look into that. This is my way of saying I don't know, but whichever direction we go, we can help if that's where we are needed. Anyone who has looked at the client, Titan or otherwise, should educate us here. To Soren's original point, we've already said that python-novaclient is a requirement for nova, and relying on an external party to keep that up-to-date is a little bit of a concern to me. We are going to rely on this to maintain our deployments, so it seems a little risky to rely on someone not on the project to keep it up to date. We do have other language bindings that can keep us honest as far as honoring the spec, so hopefully we still get that protection from ourselves from that quarter. Gabe On Wednesday, May 18, 2011 10:03am, Sandy Walsh sandy.wa...@rackspace.com said: Thanks Dan, I wasn't so much worried about the technical details but rather if your group plans on making a new client or contributing to python-novaclient (or something)? Cheers, -Sandy ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal for Nova Core
+1 On Tue, May 10, 2011 at 4:13 PM, Paul Voccio paul.voc...@rackspace.com wrote: All, I would like to nominate Dan Prince (https://launchpad.net/~dan-prince ) for nova-core. He has been a solid contributor in terms of code, reviews and discussions during the summit. Thanks, pvo Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Moving code hosting to GitHub
Try 'bzr branch' instead of 'pull'. On Tue, May 3, 2011 at 5:17 PM, andi abes andi.a...@gmail.com wrote: I'm not sure who wins in git vs. bzr ease of use... guess it depends on how quickly I get over this error: $ bzr pull lp:swift/1.3 bzr: ERROR: Cannot lock LockDir( http://bazaar.launchpad.net/~swift/swift/omega-1.3.0-7/.bzr/branch/lock): Transport oper ation not possible: http does not support mkdir() any idea ? On Wed, Apr 27, 2011 at 1:37 PM, Soren Hansen so...@linux2go.dk wrote: 2011/4/27 Thomas Goirand tho...@goirand.fr: On 04/27/2011 11:26 PM, Soren Hansen wrote: To get working, yes. To be an expert, no. bzr lp-login (bzr init-repo) bzr branch (bzr add) bzr commit bzr push ..are sufficient to just get started. No, I don't agree, it's not enough. See below. and that's most of the time the issues with using bzr for git users tutorials: they tend to think that you're ok with the most basics command, and that you wont ever need more. Truth is you do, and finding the relevant information for the thing you need takes time (a big cost, to use your own words...). If you find a learning quickly advanced bzr commands for git users type of tutorial, I might change my mind! :) If you can explain what sort of stuff you've had a hard time finding, I can probably whip up something that will be helpful to others. - git reset --hard sha256 bzr uncommit -r revisionspec that leaves the changes in the working directory, though. You can use bzr revert to remove the changes from the working directory. - git commit -a --amend (to correct the latest commit) bzr uncommit ; bzr commit - git format-patch sha256 bzr log -c revisionspec -p - or maybe instead: git diff -u -r sha256 -r sha256 bzr diff -r revisionspec..revisionspec - git push --force (you told me, but I forgot... is that bzr push --overwrite?) bzr push --overwrite, but please don't use it. It's the same for git, really. Once you've pushed it somewhere, don't remove stuff from it, or rebase it or whatever. If anyone has pulled from it and based work on it, it's extremely awkward if they want to sync up with you. - git cherry-pick -x bzr merge -c revisionspec, but its use is discouraged. - git -r branch (does listing branches on the remote side even make sense with bzr?) No. - git tag (to list tags, as bzr tag tagname seems working) bzr tags There must be more than I can't recall just now, in 5 minutes of deep thoughts. I still don't see how any of the above are *required* to start working, though. Also, one thing I love with git, is that I can always do man git-command if I want help with command, and there's more than 100 of them. Is this available somehow? bzr subcommand -h shows the help for the subcommand. bzr help foo is roughly the same, but it provides help for a bunch of things other than commands. bzr help commands shows you (almost) all the available commands (bzr help hidden-commands shows a few extra commands that most people will never need) bzr help topics shows a bunch of topics that has more extensive explanations. -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal for Justin Santa Barbara to join Nova-Core
+1 On Thu, Apr 7, 2011 at 2:18 PM, Jay Pipes jaypi...@gmail.com wrote: Hey all, Subject basically says it all. Justin has proven to be a regular and thorough reviewer and unless he objects, I propose he join the nova-core team as a core reviewer. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
I'd also like to see it called 'nova'. On Thu, Feb 24, 2011 at 4:41 PM, Rick Clark rick.cl...@rackspace.comwrote: I agree the 'os' designation is ambiguous and likely to cause some confusion. On 02/24/2011 04:36 PM, Eric Day wrote: ++ On Thu, Feb 24, 2011 at 02:33:42PM -0800, Devin Carlen wrote: This is a bit nitpicky but I'd rather see it called just nova, as in: nova describe images Who has strong opinions? On Feb 24, 2011, at 1:30 PM, Jay Pipes wrote: On Thu, Feb 24, 2011 at 4:06 PM, Eric Day e...@oddments.org wrote: On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote: I just don't want to end up with: os-describe-images os-describe-image-attribute os-describe-instances os-describe-groups os-describe-zones os-describe-keypairs os-describe-volumes os-describe-snapshots The above is asinine, IMO. Completely agree. :) Cool. Was starting to lose my mind thinking people *really* wanted to duplicate the eucatools mess... If you want to have an os-compute and an os-network CLI tool, cool, but I think that: os-compute describe images os-compute describe image-attribute os-compute describe instances os-compute describe groups etc... is far more workable than 15 separate CLI tools that do essentially identical things. Yup, agree. Also keep in mind that some operations may be duplicates across services, just with a different context. For example, in a deployment where you use glance backed by swift for nova, os-compute describe image id may be the same as os-image describe id or os-object describe id (swift), but the os-compute is in the context of instances so it could have more metadata. This will mirror the dependency tree we see between services (especially as they are split out). ++ We want to make sure there are tools so services can stand alone as needed (for example, os-image if you run glance standalone). Services that combine other services (like nova) should aggregate these into context-specific commands so you don't *need* to use the underlying service tools for most things. This allows you to control nova use one tool. :) No disagreement from me. -jay p.s. thx for not sending me to /dev/null ;) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Should the OpenStack API re-use the EC2 credentials?
Two people may have come into the channel and brought it to our attention today, but this was a very recent change. I can assure you there are many more OS API consumers out there already. It's likely that most just haven't pulled trunk since it landed. I think we all agree that a decision on a standard needs to be made to avoid further pain down the road, even if it's just between us devs. On Wed, Feb 23, 2011 at 8:38 PM, Justin Santa Barbara jus...@fathomdb.comwrote: When the authentication protocol changes, then OpenStack wrapper libraries will need to change - good point. So there's even less reason to treat OpenStack as if it were a stable API. However, we can't expect people using those libraries to change their credentials - there was enough kicking and screaming when two people had to do that today; when it's 200 including automated systems on big server farms, it'll be really painful. So I think we should standardize on one set of credentials across EC2 and OpenStack asap (or decide that having differing sets of credentials based on the API is in fact what we want to do) Justin On Wed, Feb 23, 2011 at 6:19 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: Hey Justin, Does it make any difference that the way the auth is (theoretically) supposed to work with the os api is that the user gets an auth token from an external auth server and then uses username / authtoken to actually contact the api? I think it is just faked out right now to use the access_key instead of doing external auth, but I think the reason it works like it does is because the plan was to switch to external auth eventually. Vish On Feb 23, 2011, at 5:56 PM, Justin Santa Barbara wrote: I previously fixed OpenStack authentication so it would use the same credentials as EC2. This bugfix was just reverted, because it caused OpenStack API users to have to enter in different credentials (sorry!), but primarily because it hadn't been discussed on the mailing list. So here goes! Here's a blueprint: https://blueprints.launchpad.net/nova/+spec/authentication-consistency Here's an overview of the problem: EC2 uses an (api_key, api_secret) pair. Post-revert, OpenStack uses the api_key(!) as the password, but a different value entirely as the username: (username, api_key). The bugfix made it so that both APIs used the EC2 credentials (api_key, api_secret) . This did mean that anyone that had saved the 'bad' OpenStack credentials was unable to continue to use those credentials. I also overlooked exporting the updated credentials in novarc (though a merge request was pending). I actually thought originally that this was a straight-up bug, rather than a design 'decision', so I should definitely have flagged it better. Again, sorry to those I impacted. As things stand now, post-revert, this is probably a security flaw, because the EC2 API does not treat the api_key as a secret. The EC2 API can (relatively) safely be run over non-SSL, because it uses signatures instead of passing the shared secret directly. This is also not very user-friendly. Post-revert, an end-user must know whether any particular cloud tool uses the EC2 API or the OpenStack API, so that they can enter in the correct pair of credentials. That doesn't seem like a good idea; I think there should be one set of credentials. There is some discussion about the idea of having the api_key be user-friendly. I don't think it buys us anything, because the api_secret is still going to be un-friendly, but I have no objection as long as it is does in a way that does not break existing users of the EC2 API. I propose that: (1) the OpenStack API and EC2 credentials should be the same as each other (whatever they are) for the sake of our collective sanity and (2) we have to change the current configuration anyway for security reasons. (3) We should not change the EC2 credentials, because we've shipped the EC2 API and our users have an expectation that we won't break them without good reason, so (4) we must change the credentials for users of the (non-shipped) OpenStack API. Estimated user impact: I believe there are two people that will be affected, and it will take them ~1 minute each, so total impact ~2 minutes. The longer we delay fixing this, the more people we break and the bigger the impact. It seems that we have no choice but to do a non-backwards-compatible authentication change, but I believe this is OK at the moment because the OpenStack API is not yet stable/released - i.e. we can still make fixes without worrying about backwards compatibility shims. We're not in The Old New Thing land yet :-) As an aside, I am very unhappy about the way this revert was pushed through by Rackspace team-members, seemingly without much consideration of alternatives. Perhaps we should consider changing from needing two core-approves, to needing one Rackspace core-approve and one
Re: [Openstack] Should the OpenStack API re-use the EC2 credentials?
No hard feelings or anything like that. :) We actually did just have a talk about the possibility of merging it in with Nova (or perhaps combining them with other toolsets). I imagine it will hit the ML soon for further discussion once we get the kinks worked out. On Wed, Feb 23, 2011 at 9:11 PM, Justin Santa Barbara jus...@fathomdb.comwrote: Hi Josh - I didn't think your Python API bindings were in particularly widespread use yet because they were so new. But I'm a big fan and love how they are moving so quickly. I think I hit some bugs in them one day and then when I pulled the next day you'd fixed them all. Perhaps there was some meiosis in my estimate of the auth-change impact ;-) ... no offence intended towards your work on the bindings. I'd love to see your project as part of nova, so that we can use it as our reference implementation of the OpenStack API and keep an official binding in lock-step with developments to the API. Any chance of that happening? Justin On Wed, Feb 23, 2011 at 6:54 PM, Josh Kearney j...@jk0.org wrote: Two people may have come into the channel and brought it to our attention today, but this was a very recent change. I can assure you there are many more OS API consumers out there already. It's likely that most just haven't pulled trunk since it landed. I think we all agree that a decision on a standard needs to be made to avoid further pain down the road, even if it's just between us devs. On Wed, Feb 23, 2011 at 8:38 PM, Justin Santa Barbara jus...@fathomdb.com wrote: When the authentication protocol changes, then OpenStack wrapper libraries will need to change - good point. So there's even less reason to treat OpenStack as if it were a stable API. However, we can't expect people using those libraries to change their credentials - there was enough kicking and screaming when two people had to do that today; when it's 200 including automated systems on big server farms, it'll be really painful. So I think we should standardize on one set of credentials across EC2 and OpenStack asap (or decide that having differing sets of credentials based on the API is in fact what we want to do) Justin On Wed, Feb 23, 2011 at 6:19 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: Hey Justin, Does it make any difference that the way the auth is (theoretically) supposed to work with the os api is that the user gets an auth token from an external auth server and then uses username / authtoken to actually contact the api? I think it is just faked out right now to use the access_key instead of doing external auth, but I think the reason it works like it does is because the plan was to switch to external auth eventually. Vish On Feb 23, 2011, at 5:56 PM, Justin Santa Barbara wrote: I previously fixed OpenStack authentication so it would use the same credentials as EC2. This bugfix was just reverted, because it caused OpenStack API users to have to enter in different credentials (sorry!), but primarily because it hadn't been discussed on the mailing list. So here goes! Here's a blueprint: https://blueprints.launchpad.net/nova/+spec/authentication-consistency Here's an overview of the problem: EC2 uses an (api_key, api_secret) pair. Post-revert, OpenStack uses the api_key(!) as the password, but a different value entirely as the username: (username, api_key). The bugfix made it so that both APIs used the EC2 credentials (api_key, api_secret) . This did mean that anyone that had saved the 'bad' OpenStack credentials was unable to continue to use those credentials. I also overlooked exporting the updated credentials in novarc (though a merge request was pending). I actually thought originally that this was a straight-up bug, rather than a design 'decision', so I should definitely have flagged it better. Again, sorry to those I impacted. As things stand now, post-revert, this is probably a security flaw, because the EC2 API does not treat the api_key as a secret. The EC2 API can (relatively) safely be run over non-SSL, because it uses signatures instead of passing the shared secret directly. This is also not very user-friendly. Post-revert, an end-user must know whether any particular cloud tool uses the EC2 API or the OpenStack API, so that they can enter in the correct pair of credentials. That doesn't seem like a good idea; I think there should be one set of credentials. There is some discussion about the idea of having the api_key be user-friendly. I don't think it buys us anything, because the api_secret is still going to be un-friendly, but I have no objection as long as it is does in a way that does not break existing users of the EC2 API. I propose that: (1) the OpenStack API and EC2 credentials should be the same as each other (whatever they are) for the sake of our collective sanity and (2) we have to change the current configuration anyway
Re: [Openstack] wiki.openstack.org broken in IE
Out of curiosity -- are we *really* concerned about IE6? On Wed, Feb 16, 2011 at 10:54 AM, Colin Nicholson colin.nichol...@iomart.com wrote: Not sure about StartingPage - it's not all that bad, and could easily just be IE6, haven't ever looked at it in IE6 before. As for the releasestatus page, I'd point my finger at the base href=. at the top. That doesn't seem to be handled properly, stopping all the css, js and image files from loading. Colin On 16/02/11 16:28, Thierry Carrez wrote: Ewan Mellor wrote: Has someone changed Javascript or stylesheets on wiki.openstack.org recently? It’s broken in IE now, in a way that it wasn’t yesterday. Note that the releasestatus page and the rest of the wiki don't have any stylesheet in common, so that would rather point to a local issue... ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
