[openstack-dev] OpenStack New Years Resolutions
OK, so if you were putting together New Year's Resolutions for OpenStack development for 2017, what would they be? -- Nick Chase Editor in Chief, OpenStack:Unlocked __ OpenStack Development Mailing 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][summit] Responding to questions on submitted summit talk?
Ben -- I'm the one who asked you, I believe; I'll get with you privately. Thanks! Nick On 7/25/2016 11:32 AM, Ben Nemec wrote: Okay, I sent the question there too. I figured I would try -dev because somebody here might know and it's of general interest to the community. I'll let everyone know if/when I get a response from the summit folks. On 07/25/2016 10:15 AM, Nikhil Komawar wrote: I think this may be the wrong place to ask such info because all the process on summit presentation is being handled by folks who are not necessarily openstack developers. Please follow: https://www.openstack.org/summit/barcelona-2016/call-for-presentations/selection-process and send email to summit [at] openstack [dot] org <mailto:sum...@openstack.org> as required. On 7/25/16 10:55 AM, Ben Nemec wrote: Hi, I got a question from one of the track chairs on my presentation, but the email came from a noreply address and I don't see anywhere on the submission page that I can respond to feedback. How are we supposed to do that? Thanks. -Ben __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Nick Chase, Head of Technical and Marketing Content, Mirantis Editor in Chief, OpenStack:Unlocked <https://www.eventbrite.com/e/openstack-silicon-valley-2016-the-unlocked-infrastructure-conference-tickets-25277154650> __ OpenStack Development Mailing 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] the trouble with names
What about using a combination of two word names, and generic names. For example, you might have cinder-blockstorage and foo-blockstorage The advantage there is that we don't need to do the thesaurus.com thing, but also, it enables to specify just blockstorage via a registry. The advantage of THAT is that if a user wants to change out the "default" blockstorage engine (for example) we could provide them with a way to do that. The non-default would have to support the same API, of course, but it definitely fits with the "pluggable" nature of OpenStack. Nick __ OpenStack Development Mailing 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] Call for papers already closed?
It's definitely broken. We're getting the same messages for people who haven't submittted ANY talks. That said, the 3 proposal limit is NOT just for speakers, but also for SUBMITTERS. So be prepared, unless they broke it trying to change that, your colleagues are going to have to submit their own when it comes back up. - Nick On 2/1/2016 2:43 AM, Christian Berendt wrote: Hello. I am a little bit confused, according to openstack.org: FEBRUARY 1 IS THE DEADLINE TO SUBMIT A TALK (11:59PM PST) I tried to edit a submitted talk and got the following message: Call for speaker closed! Also I have the following note in my interface: Warning! You reached presentations submissions limit (3). Is it not possible to submit more than 3 talks? Anyway, at the moment I only have 2 talks (1 submitted be my, 1 submitted by a other person). I am submitting the talks for all of my colleagues and we prepared more than 3 talks. Christian. __ OpenStack Development Mailing 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] Recording little everyday OpenStack successes
This is AWESOME! And I've already found useful resources on the list of successes. Beautiful job, and fantastic idea! Nick On 10/09/2015 05:42 AM, Thierry Carrez wrote: > Hello everyone, > > OpenStack has become quite big, and it's easier than ever to feel lost, > to feel like nothing is really happening. It's more difficult than ever > to feel part of a single community, and to celebrate little successes > and progress. > > In a (small) effort to help with that, I suggested making it easier to > record little moments of joy and small success bits. Those are usually > not worth the effort of a blog post or a new mailing-list thread, but > they show that our community makes progress *every day*. > > So whenever you feel like you made progress, or had a little success in > your OpenStack adventures, or have some joyful moment to share, just > throw the following message on your local IRC channel: > > #success [Your message here] > > The openstackstatus bot will take that and record it on this wiki page: > > https://wiki.openstack.org/wiki/Successes > > We'll add a few of those every week to the weekly newsletter (as part of > the developer digest that we reecently added there). > > Caveats: Obviously that only works on channels where openstackstatus is > present (the official OpenStack IRC channels), and we may remove entries > that are off-topic or spam. > > So... please use #success liberally and record lttle everyday OpenStack > successes. Share the joy and make the OpenStack community a happy place. > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-docs] Networking guide team disintegration
Sean, you're absolutely right; the Neutron team really needs to help us out. Edgar, thank you so much for taking this on. You're right, I'm not going away, I just don't have the strength for a sustained effort right now. That said, if you have any isolated incidents where I can help, please be sure to let me know! Nick On 10/3/2015 6:34 PM, Edgar Magana wrote: I volunteer to lead this effort. From the very beginning was an idea between Nick and myself and I do have the bandwidth to work on this guide. There are still a lot of work to do and I will move the meetings to IRC and also to formalize better the team by following all the Foundation policies, guidelines and rules. Nick, Thank you so much for all the work invested in this guide. We have achieved a great document and we will miss your input. I am pretty sure you are not going to disappear for sure, at least I will not let you to do that. I am also in PTO this week but I am back in business this Monday Oct 5th. Kind Regards, Edgar On Oct 3, 2015, at 2:33 PM, Sean Collins <s...@coreitpro.com> wrote: This needs to be brought to the attention of the new PTL for Neutron. The original team that released the networking guide cannot be expected to carry this work forward in perpetuity. On October 2, 2015, at 6:45 PM, Lana Brindley <openst...@lanabrindley.com> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I do strongly believe that the Networking Guide needs to be a speciality team all of its own, and not part of a larger team. It's an important part of our documentation suite. The leader of the team doesn't necessarily need to be doing the lion's share of the work (in fact, in many cases, it's better if you aren't), and you don't need to be a core contributor. You do need to be able to commit to running meetings once a week or every two weeks, and keeping an eye on reviews. Of course, I am here to support anyone who chooses to take this on, as well. Lana On 03/10/15 04:40, Nick Chase wrote: I'm actually serious on abdicating here; I'm catching up after being good and sick (and theoretically I'm still on sick leave) so it would probably be better if I stepped aside. Who wants it? Nick On 10/2/2015 12:06 PM, Anita Kuno wrote: On 10/02/2015 11:53 AM, Nick Chase wrote: Agreed. Nick Having meetings on irc in order to allow new contributors to read some archives to get up to speed is one of the reasons we encourage projects to have meetings on irc. Now we need folks willing to read archives and attend meetings, that is true, but irc logs can serve as a doorway if we do have any new contributors who are interested. Can I suggest networking guide team meetings move to irc? Thank you, I want to help this group continue and to grow. The work you do is very important. Thanks, Anita. On 10/2/2015 11:52 AM, Matt Kassawara wrote: I hope your surgery went well. However, the problems began long before 9/9. On Fri, Oct 2, 2015 at 9:45 AM, Nick Chase <nch...@mirantis.com <mailto:nch...@mirantis.com>> wrote: I had major surgery on 9/9 and have been on sick leave, I take responsibility for falling down on the job there. I hereby abdicate if someone else feels they can take it. Thanks... --- On 10/2/2015 11:19 AM, Matt Kassawara wrote: I find it extremely unfortunate that the networking guide team disintegrated after the initial release of the guide for Kilo. No one attends the meetings and no one outside of a couple of people make any significant contributions. Furthermore, the guide receives little attention from neutron developers who are key to keeping the content fresh. I suggest we either disband the team or find new leadership for it. ___ OpenStack-docs mailing list openstack-d...@lists.openstack.org <mailto:openstack-d...@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs ___ OpenStack-docs mailing list openstack-d...@lists.openstack.org <mailto:openstack-d...@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs ___ OpenStack-docs mailing list openstack-d...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs ___ OpenStack-docs mailing list openstack-d...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs ___ OpenStack-docs mailing list openstack-d...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs - -- Lana Brindley Technical Writer Rackspace Cloud Builders Australia http://lanabrindley.com -BEGIN PGP SIGNATURE- Ve
Re: [openstack-dev] [Fuel] Get rid of fuelmenu
On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn mmoses...@mirantis.com mailto:mmoses...@mirantis.com wrote: Here's a relic of what users used to have to configure by hand: https://github.com/stackforge/fuel-library/blob/b015ed975b58dddff3b8da0ce34d9a638c22d032/deployment/puppet/openstack/examples/site_simple.pp Am I alone in thinking it's not the best use of our development resources to throw it away and replace it with a text file that is edited by hand? Please, please, please, I'm having PTSD just remembering that @#$%@#%$ file. I think I was able to successfully deploy without major engineering help about 2% of the time. We absolutely, positively, MUST maintain the validation. Just because the people installing OpenStack are generally not afraid to edit config files doesn't mean that we should be making them do it. Nick __ OpenStack Development Mailing 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] Summit Voting and ATC emails?
Does anybody know if a) ATC emails have started to go out yet, and b) when proposal voting will start? Thanks --- Nick __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can!
On Fri, Oct 3, 2014 at 3:07 PM, Stefano Maffulli stef...@openstack.org wrote: 4. Send e-mail to reviewers network...@openstacknow.com. Why not use the docs mailing list or other facilities on @openstack.org? We've now switched over to use the [networking] topic on the openstack-docs list. So anybody who's interested in following the discussions, please feel free to join us. Thanks! - Nick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can!
On Sun, Oct 5, 2014 at 11:26 PM, Tom Fifield t...@openstack.org wrote: On 04/10/14 04:03, Nick Chase wrote: On Fri, Oct 3, 2014 at 3:07 PM, Stefano Maffulli stef...@openstack.org mailto:stef...@openstack.org wrote: 1. Pick an existing topic or create a new topic. For new topics, we're primarily interested in deployment scenarios. 2. Develop content (text and/or diagrams) in a format that supports at least basic markup (e.g., titles, paragraphs, lists, etc.). 3. Provide a link to the content (e.g., gist on github.com http://github.com, wiki page, blog post, etc.) under the associated topic. Points 1-3 seem to be oriented at removing Launchpad from the equation. Is that all there is? I guess it makes sense to remove obstacles, although editing the wiki (since it requires a launchpad account anyway) may not be the best way to track progress and see assignments. No, really, the main change is in step 5. Launchpad isn't the problem, as far as we can tell; Docbook is. Hi Nick, As best I can tell - 'step 5' has been in place for at least the last few summits at least, so this is not a change :) We have had a policy where anyone can dump text in bug reports and we'll wrangle it. This has been popular, see eg Marco Cossoni's contributions, but in my opinion not widely enough communicated - so thanks for your efforts. Right, again, it's fantastic that people can dump text in bug reports, and yes, it's probably not well known. We're just trying to sort of widen out what people are sending from a few paragraphs to entire topics. But hey, the general idea is the same. We're all trying to get to the same point. Obviously there's something about the current process that's not working as well as it could. This experiment is about trying to figure out what. If all we're changing is moving the contribution point from a bug report to a wiki, then great; having just one changed variable among control variables is good science. 4. Send e-mail to reviewers network...@openstacknow.com mailto:network...@openstacknow.com. Why not use the docs mailing list or other facilities on @openstack.org http://openstack.org? Who is responding to that address? If someone want to provide us a list on @openstack.org http://openstack.org, that'd be awesome. I set up this address because I control the forwarding and could do it immediately without having to ask for anyone's approval. :) People on the alias are myself, Edgar Magana, Matt Kasawara, Phil Hopkins, Anne Gentle, and Elke Vorheis. I find it quite odd that the larger team is being excluded from this effort. Why would it need a separate mailing list? We haven't intentionally excluded anybody; we were just keeping it small both to keep it a focused effort -- this way we could more easily hash things out without anybody stepping on anybody else -- and so that we weren't essentially volunteering people against their will. :) But we can easily change it over to the main docs list. Nick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can!
Actually the documentation process is already open to all, and has been. You can find information on how to contribute here: https://wiki.openstack.org/wiki/Documentation/HowTo Thanks! Nick On Mon, Oct 6, 2014 at 1:23 AM, Akilesh K akilesh1...@gmail.com wrote: Can someone create a Wiki for all the options available to contribute to openstack docs. I have a personel feeling that ArchWiki https://wiki.archlinux.org/index.php/Main_page is one of the best technical documentations available and they even have wiki for guidelines for writing. Can the the documentation process be open to all and then the admins can decide on what changes to accept and what to revert. s ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Contributing to docs without Docbook -- YES you can!
Yes, these are great, thanks. We'll go through and see what we can pull.
Thank you!
Nick
On Tue, Sep 30, 2014 at 3:26 AM, Akilesh K akilesh1...@gmail.com wrote:
Sorry the correct links are
1. Comparison between networking devices and linux software components
http://fosskb.wordpress.com/2014/06/25/a-bite-of-virtual-linux-networking/
2. Openstack ovs plugin configuration for single/multi machine setup
http://fosskb.wordpress.com/2014/06/10/managing-openstack-internaldataexternal-network-in-one-interface/
3. Neutron ovs plugin layer 2 connectivity
http://fosskb.wordpress.com/2014/06/19/l2-connectivity-in-openstack-using-openvswitch-mechanism-driver/
4. Layer 3 connectivity using neutron-l3-agent
http://fosskb.wordpress.com/2014/09/15/l3-connectivity-using-neutron-l3-agent/
On Tue, Sep 30, 2014 at 12:50 PM, Andreas Scheuring
scheu...@linux.vnet.ibm.com wrote:
Hi Ageeleshwar,
the links you provided are wordpress admin links and require a login. Is
there also a public link available?
Thanks
--
Andreas
(irc: scheuran)
On Tue, 2014-09-30 at 09:33 +0530, Akilesh K wrote:
Hi,
I saw the table of contents. I have posted documents on configuring
openstack neutron-openvswitch-plugin, comparison between networking
devices and thier linux software components and also about the working
principles of neutron-ovs-plugin at layer 2 and neutron-l3-agent at
layer 3 . My intention with the posts was to aid begginers in
debugging neutron issues.
The problem is that I am not sure where exactly these posts fit in the
topic of contents. Anyone with suggestions please reply to me. Below
are the link to the blog posts
1. Comparison between networking devices and linux software components
2. Openstack ovs plugin configuration for single/multi machine setup
3. Neutron ovs plugin layer 2 connectivity
4. Layer 3 connectivity using neutron-l3-agent
I would be glad to include sub sections in any of these posts if that
helps.
Thank you,
Ageeleshwar K
On Tue, Sep 30, 2014 at 2:36 AM, Nicholas Chase nch...@mirantis.com
wrote:
As you know, we're always looking for ways for people to be
able to contribute to Docs, but we do understand that there's
a certain amount of pain involved in dealing with Docbook. So
to try and make this process easier, we're going to try an
experiment.
What we've put together is a system where you can update a
wiki with links to content in whatever form you've got it --
gist on github, wiki page, blog post, whatever -- and we have
a dedicated resource that will turn it into actual
documentation, in Docbook. If you want to be added as a
co-author on the patch, make sure to provide us the email
address you used to become a Foundation member.
Because we know that the networking documentation needs
particular attention, we're starting there. We have a
Networking Guide, from which we will ultimately pull
information to improve the networking section of the admin
guide. The preliminary Table of Contents is here:
https://wiki.openstack.org/wiki/NetworkingGuide/TOC , and the
instructions for contributing are as follows:
1. Pick an existing topic or create a new topic. For new
topics, we're primarily interested in deployment
scenarios.
2. Develop content (text and/or diagrams) in a format
that supports at least basic markup (e.g., titles,
paragraphs, lists, etc.).
3. Provide a link to the content (e.g., gist on
github.com, wiki page, blog post, etc.) under the
associated topic.
4. Send e-mail to reviewers network...@openstacknow.com.
5. A writer turns the content into an actual patch, with
tracking bug, and docs reviewers (and the original
author, we would hope) make sure it gets reviewed and
merged.
Please let us know if you have any questions/comments.
Thanks!
Nick
--
Nick Chase
1-650-567-5640
Technical Marketing Manager, Mirantis
Editor, OpenStack:Now
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can!
On Fri, Oct 3, 2014 at 3:07 PM, Stefano Maffulli stef...@openstack.org wrote: hi Nick, On 09/29/2014 02:06 PM, Nicholas Chase wrote: Because we know that the networking documentation needs particular attention, we're starting there. We have a Networking Guide, from which we will ultimately pull information to improve the networking section of the admin guide. I love experiments and I appreciate your effort to improve the situation. It's not clear to me what the experiment wants to demonstrate and I'd appreciate more details. Absolutely. The preliminary Table of Contents is here: https://wiki.openstack.org/wiki/NetworkingGuide/TOC , and the instructions for contributing are as follows: This is cool and I see there is a blueprint also assigned https://blueprints.launchpad.net/openstack-manuals/+spec/create-networking-guide Correct. 1. Pick an existing topic or create a new topic. For new topics, we're primarily interested in deployment scenarios. 2. Develop content (text and/or diagrams) in a format that supports at least basic markup (e.g., titles, paragraphs, lists, etc.). 3. Provide a link to the content (e.g., gist on github.com, wiki page, blog post, etc.) under the associated topic. Points 1-3 seem to be oriented at removing Launchpad from the equation. Is that all there is? I guess it makes sense to remove obstacles, although editing the wiki (since it requires a launchpad account anyway) may not be the best way to track progress and see assignments. No, really, the main change is in step 5. Launchpad isn't the problem, as far as we can tell; Docbook is. 4. Send e-mail to reviewers network...@openstacknow.com. Why not use the docs mailing list or other facilities on @openstack.org? Who is responding to that address? If someone want to provide us a list on @openstack.org, that'd be awesome. I set up this address because I control the forwarding and could do it immediately without having to ask for anyone's approval. :) People on the alias are myself, Edgar Magana, Matt Kasawara, Phil Hopkins, Anne Gentle, and Elke Vorheis. 5. A writer turns the content into an actual patch, with tracking bug, and docs reviewers (and the original author, we would hope) make sure it gets reviewed and merged. This is puzzling: initially I thought that you had some experimental magic software that would monitor edits to the wiki TOC page, go grab html content from gist, blog post, etc, transform that into docbook or something similar and magically create a task on LP for a doc writer to touch up and send for review. Wouldn't THAT be fantastic. No, unfortunately not. This is a process experiment, rather than a technology experiment. My understanding is that the Docs team has been using bug reports on Launchpad to receive contributions and a writer would pick them from the list, taking care of the transformation to docbook and gerrit workflow. Bug reports are great, and we do want to continue getting those -- and the more information for the writer, the better! -- but that's a process where the developer says, hey, I think you should write something about X. This is the opposite. We're saying, Hey, we want to write about X, does anybody have any resources? Or if you think we should write about Y, do you have something already fleshed out (versus a paragraph you'd add in a bug report)? Point 5. makes the experiment look like the process already in place, only using a wiki page first (instead of a blueprint first) and a private email address instead of a public bug tracker. Well, you're half-right. It's like the process in already in place, only using a wiki page first and having a dedicated writer pick a developer's brain and actually produce the prose and put it into Docbook, rather than holding a gun to the developer's head and forcing him or her to write Docbook in order to contribute to the docs. Have I got it wrong? Can you explain a bit more why this experiment is not using the existing process? What is the experiment trying to demonstrate? The experiment is trying to determine whether we can increase the level of developer participation in the docs process by removing the hurtles of: 1) Deciphering where in the docs repo content goes 2) Learning XML in general, and Docbook in particular 3) Figuring out how to get docs to build 4) And so on, until the additions are actually merged Does that clear it up? Thanks... Nick /stef -- Ask and answer questions on https://ask.openstack.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Summit etherpad and discussion about making docs easier for developers
I've put together an etherpad to hopefully get a little discussion going about what people would like to happen to make it easier for them to provide more docs related to the code they're providing. ( http://junodesignsummit.sched.org/event/19381e6ad48e05abc9099eb7ff956231#.U20CR3Wx17Q ) The etherpad is here: https://etherpad.openstack.org/p/easier_documentation_for_developers Please feel free to contribute any ideas to discuss. I'd love for us to come out of the session with something we can implement during the Juno cycle. Thanks! Nick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
From a purely documentation and explanatory standpoint I vote for project, if we're going to standardize on one or the other. On Nov 23, 2013 7:13 AM, Christopher Yeoh cbky...@gmail.com wrote: Hi, So in the past we've used both tenant and project to refer to the same thing and I think its been a source of confusion for people new to OpenStack. In the Nova code we use both, but at least for the API we've been trying to consistently present to the client tenant (which is the majority usage) rather than project. And then Russell pointed out in https://review.openstack.org/#/c/57612/ that the Keystone uses project in the Keystone V3 API rather than tenant. http://api.openstack.org/api-ref-identity.html#identity-v3 I think that we should be consistent across the openstack projects. From a very quick look at the core openstack projects I think that they mostly use tenant at the moment rather than project. Does this change in Keystone nomenclature signify that we all should be moving to use project rather than tenant in the future (its not too late to do a big a search and replace for the Nova V3 API). And is the plan for Keystone python client to also change to project rather than tenant? Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Propose project story wiki idea
On Wed, Nov 20, 2013 at 6:45 PM, Stefano Maffulli stef...@openstack.orgwrote: I like the idea. I love this idea. ... Not sure the wiki is the best place for this sort of stuff (wiki pages are awful for anything but quick notes): since we want this content to be delivered and produced easily I would suggest setting up something that resembles more a commit log than a wiki page. A short, brief dump of text, written by developers or people involved, using tools they're already familiar with. I'd prefer a short email to the list, with a tag in the subject instead of a wiki page. I'd be glad to further distribute them in the weekly newsletter. We definitely want to make it as easy as possible for people to contribute, and to get the information. We would be happy to contribute space on our OpenStack information site (with a feed if people want it) and resources to make this as easy to contribute to and as useful as possible. Does anybody else want to head this up? If not, I would be more than happy to take the point. Nick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Split of the openstack-dev list (summary so far)
I am one of those horizontal people (working on docs and basically one of the people responsible at my organization for keeping a handle on what's going on) and I'm totally against a split. Of COURSE we need to maintain the integrated/incubated/proposed spectrum. Saying that we need to keep all traffic on one list isn't suggesting we do away with that. But it IS a spectrum, and we should maintain that. Splitting the list is definitely splitting the community and I agree that it's a poison pill. Integrating new projects into the community is just as important as integrating them into the codebase. Without one the other won't happen nearly as effectively, and we do lose one of the strengths of the community as a whole. Part of this is psychology. Many of us are familiar with broken windows theory[1] in terms of code. For those of you who aren't, the idea is based on an experiment where they left an expensive car in a crime-ridden neighborhood and nothing happened to it -- until they broke a window. In coding it means you're less likely to kludge a patch to pristine code, but once you do you are more likely to do it again. Projects work hard to do things the OpenStack way because they feel from the start that they are already part of OpenStack, even if they aren't integrated. It also leads to another side effect, which I'll leave to you to decide whether it's good or bad. We do have a culture of there can be only one. Once a project is proposed in a space, that's it (mostly). We typically don't have multiple projects in that space. That's bad because it reduces innovation through competition, but it's good because we get focused development from the finite number of developers we have available. As I said, YMMV. Look, Monty is right: a good threaded client solves a multitude of problems. Definitely try that for a week before you set your mind on a decision. TL; DR Splitting the list is splitting the community, and that will lead to a decline in overall quality. [1] http://en.wikipedia.org/wiki/Broken_windows_theory ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [summit] Youtube stream from Design Summit?
Possible ways of remote interaction: - direct hangout participation (key people) - questions/comments section in etherpad (delay, more difficult to follow - might need some assistant for tracking them) I have a realtime browser-based chat app that is normally used in conjunction with live events being streamed out of Second Life. I would be happy to volunteer it for this. Someone would have to monitor it for questions during the session and ask them out loud, but it does provide a log, and also has the advantage that we can leave it up outside the session for additional conversations. (Not sure actually what the difference would be from IRC, actually, though.) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] Announcing a new task scheduling and orchestration service for OpenStack
Maybe add a link to the Mistral page from the Convention page? On Oct 15, 2013 4:22 AM, Renat Akhmerov rakhme...@mirantis.com wrote: Hey Clint, thanks for your question. I think it's been fully answered by this time. You and other people are very welcome to collaborate :) Joshua, as far as renaming the original document I would suggest we keep it as it is for now just to preserve the explicit history of how it's been going so far. We now have a link from launchpad name to Convection proposal so one shouldn't be confused about what is what. Thanks! Renat Akhmerov Mirantis Inc. On 15.10.2013, at 0:32, Joshua Harlow harlo...@yahoo-inc.com wrote: +2 More collaboration the better :) From: Stan Lagun sla...@mirantis.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: Monday, October 14, 2013 1:20 PM To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Mistral] Announcing a new task scheduling and orchestration service for OpenStack Why exactly aren't you just calling this Convection and/or collaborating with the developers who came up with it? We do actively collaborate with TaskFlow/StateManagement team who are also the authors of Convection proposal. This is a joint project and we invite you and other developers to join and contribute. Convection is a Microsoft trademark. That's why Mistral On Tue, Oct 15, 2013 at 12:04 AM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Renat Akhmerov's message of 2013-10-14 12:40:28 -0700: Hi OpenStackers, I am proud to announce the official launch of the Mistral project. At Mirantis we have a team to start contributing to the project right away. We invite anybody interested in task service state management to join the initiative. Mistral is a new OpenStack service designed for task flow control, scheduling, and execution. The project will implement Convection proposal ( https://wiki.openstack.org/wiki/Convection) and provide an API and domain-specific language that enables users to manage tasks and their dependencies, and to define workflows, triggers, and events. The service will provide the ability to schedule tasks, as well as to define and manage external sources of events to act as task execution triggers. Why exactly aren't you just calling this Convection and/or collaborating with the developers who came up with it? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours Stanislav (Stan) Lagun Senior Developer Mirantis 35b/3, Vorontsovskaya St. Moscow, Russia Skype: stanlagun www.mirantis.com sla...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-docs] What's Up Doc? Oct 2 2013
If you have someone to talk to re: licenses and just need someone to do the legwork, I would be happy to do that. On Oct 2, 2013 11:36 AM, Anne Gentle a...@openstack.org wrote: Hi all, I'm excited to be going to the Grace Hopper Conference tomorrow, where I'll be with over 4500 other women in computing. I've never seen anything like it and I can't wait. Iccha Sethi and I are running an OpenStack workshop for Open Source day Saturday in Minneapolis. Wish us luck! I've spun up 20 Rackspace Cloud Servers and I've got some DevStack .ova files as backup. See all the plans in store at https://etherpad.openstack.org/ghc-os. On to docland! 1. In review and merged this past week: Over 85 patches merged in the last week and a half so I won't go through them all. Some highlights include: - Update auto-documented configuration items (1500 options in all of OpenStack, documented). - Removing the API Programming Guide for inaccuracies, working on a blueprint for an all-in-one API Guide. [1] - Document cinder quotas - Merged Neutron docs with other all-OpenStack docs 2. High priority doc work: The install guide is the highest priority right now. Shaun is working on drafts in his Github repo at [2] and will patch to openstack-manuals this week, today (hump day!) or tomorrow. 3. Doc work going on that I know of: Diane and I tested HTML and PDF output for all the books, using the 1.10.0 plugin, and made some patches when we found fixes were needed in the XML source. Otherwise we should all focus on doc bugs: https://bugs.launchpad.net/openstack-manuals/+milestone/havana -- 92 confirmed, 129 released and https://bugs.launchpad.net/openstack-api-site/+milestone/havana -- 48 confirmed, 20 fix released 4. New incoming doc requests: Release the havana docs October 17th! 5. Doc tools updates: The bug reporting link is available in 1.11.0 and we will finalize on that in all the pom.xml files for the havana release. See the release notes for the highlights. [3] We had a request this week to build HTML and PDF to docs-draft, I'd love to see someone pick up the work started at https://review.openstack.org/#/c/22768/ and make it happen. 6. Other doc news: David Cramer and I are scheduling a meeting with OxygenXML to discuss the donated licenses they give us. The last batch of six month licenses expires this month so this is a high priority. We found at the boot camp that while many people don't need Oxygen, it's nice to have the editor for certain types of authoring such as WADL creation and maintenance. We had a discussion about licensing for the documentation on the openstack-docs mailing list that might interest someone. I'd like a volunteer to work with a legal rep to find out advice for moving forward on licensing, please let me know if you're interested. If you're looking for a Gerrit search that lets you see all the reviews going in all the doc repos, paste this into the search box on review.openstack.org: status:open (project:openstack/openstack-manuals OR project:openstack/api-site OR project:openstack/object-api OR project:openstack/image-api OR project:openstack/identity-api OR project:openstack/compute-api OR project:openstack/volume-api OR project:openstack/netconn-api OR project:openstack/operations-guide) Hat tip to Sean Dague for writing this up in his blog. [4] 1. https://blueprints.launchpad.net/openstack-manuals/+spec/blueprint-os-api-docs 2. https://github.com/shaunix/openstack-manuals/tree/master/doc/install-guide 3. https://github.com/rackerlabs/clouddocs-maven-plugin/blob/master/README.rst 4. http://dague.net/2013/09/27/gerrit-queries-to-avoid-openstack-review-overload/ ___ Openstack-docs mailing list openstack-d...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
