Re: [Openstack-doc-core] Extra ATCs for Newton

[Tom Fifield]

On 11/08/16 07:28, Lana Brindley wrote:

Hi cores,

Are you aware of anyone who should be granted Extra ATC status? From Doug's 
email to the dev list:


Following the Foundation bylaws [1] and TC Charter [2], Project
teams should identify contributors who have had a significant impact
this cycle but who would not qualify for ATC status using the regular
process because they have not submitted a patch.


In the past, docs have given extra ATC status to people who participated in 
docs sprints, as an example. If you know of anyone, let's shop the idea on this 
list. We need to have our proposals to Foundation by 16 August, so we don't 
have much time.



FWIW - Co-Authored-By is not included in ATC unless requested by the 
project:



git log --grep=Co-Authored-By --since=6.months | grep "Co-Authored-By" |
sort | uniq


fifieldt@usagi:~/temp/api-site$ git log --grep=Co-Authored-By 
--since=6.months | grep "Co-Authored-By" |

> sort | uniq
Co-Authored-By: Cao Xuan Hoang (hoan...@vn.fujitsu.com)
Co-Authored-By: Manjeet Singh Bhatia 


fifieldt@usagi:~/temp/openstack-manuals$ git log --grep=Co-Authored-By 
--since=6.months | grep "Co-Authored-By" |

> sort | uniq
Co-Authored-By: Cathy Hong Zhang 
Co-Authored-By: Harish K
Co-Authored-By: KATO Tomoyuki 
Co-Authored-By: Matt Kassawara 
Co-Authored-By: Nathaniel Dillon 
Co-Authored-By: Neela Shah 
Co-Authored-By: OlgaGusarenko 
Co-Authored-By: Suhartono 
Co-Authored-By: Victor Howard 


--
Mailing list: https://launchpad.net/~openstack-doc-core
Post to : openstack-doc-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-doc-core
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack-doc-core] Bug triaging issue

[Tom Fifield]

On 01/10/15 06:37, Lana Brindley wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30/09/15 16:41, Andreas Jaeger wrote:

Let me open a side discussion:

I also see far too many bug reports getting asked for.

We have been liberal about "obvious" bugs. So, a typo does not need a
bug report. A one-line addition of an OpenStack project that is part o

f

the big tent to a list of repos doesn't need one (a complete new chapt

er

needs IMHO something) etc.


Some people just create those but let's not complicate contribution an

d

if a patch is obvious, include it.

There's no sense to create a bug report "like X is missing in list Y"
and then confirm it, and fix it.



I absolutely agree with you here, and it's more or less what I was
trying to get to by saying we needed to trust everyone's judgement. If
you notice a typo, you don't need a bug, and if you have a bug, you
don't need it triaged before you fix it.

We need to allow people to have control over what they're doing, while
still maintaining good quality control. That's a tricky balance to
manage, and I don't have any brilliant ideas outside of 'keep talking to
people about this'. Happy to hear your collective wisdom :)



+1 Completely agree. This is what I was trying to get at with the 'case 
study' as well.


Instead of looking at the technical content, we went straight to getting 
hung up on whether a bug was triaged or not. That doesn't make sense to 
me :)


Regards,


Tom



--
Mailing list: https://launchpad.net/~openstack-doc-core
Post to : openstack-doc-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-doc-core
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack-doc-core] Bug triaging issue

[Tom Fifield]

On 29/09/15 14:44, Lana Brindley wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 29/09/15 16:30, Andreas Jaeger wrote:

On 2015-09-29 07:20, Alexandra Settle wrote:

Hi everyone,

I�ve been noticing in the last few months (and I�m sure it�s been a
problem before) that we have contributors submitting bug reports, and
then immediately fixing before triage,  or there are patches without
bugs (or blueprints) and it�s becoming quite confusing.

I am finding that this is a problem because some of these bugs are
personal issues they�re finding with their individual builds, or on
occasion it is a bug that needs to be fixed and individuals are offer

ing

the wrong solutions and immediately trying to patch it up in the
documentation.

Personally, I�m unsure how to solve this issue, and wondering if we c

an

get a think tank going on how to solve this.

So far all I�ve been able to do is to remind contributors to wait for

  a

second individual to triage, or the patch is eventually abandoned due

  to

several negative reviews (which, ultimately encourages said contribut

or

not to come back because we look like a very negative community).

We can do more �bug triaging days�, but not everyone is to give the t

ime

to this exercise.

Thoughts? Suggestions? Comments? Questions?


This is not a simple topic, thanks for raising it!

Some OpenStack projects encourage this behaviour - if you send a patch
without a bug, they often ask for a bug that you create and assign
directly to you...


Normally, this works, and we can trust people to use their best
judgement. I certainly don't want to enforce this for everyone, because
finding a typo or something trivial really doesn't need this level of
process. Recently, though, there's been a flurry of people finding and
'fixing' things that are actually bugs, and I've had a few different
core team members point it out to me that we need to try and remind
people about triage for things like that.



Also, we have Documentation like
  http://docs.openstack.org/infra/manual/developers.html#working-on-bug

s

  https://wiki.openstack.org/wiki/BugTriage

Neither asks for an independent review.


No, and neither should they, I think. I actually suspect the better way
to handle this is for our core team to be ever-vigilant, and make sure
we're checking for independent review on patches that require it. Most
of the culprits aren't regular committers, anyway, and I don't want to
alienate any of our regular group.

I suspect this is a people problem, which we shouldn't try and fix
through extra processes, but by conversation and education.



I acknowledge the problems we have and I think this might be a broader
topic to discuss - not on this limited list but perhaps together with
developers on openstack-dev? Or in some cross-project meeting?


Let's bring it up at Summit. I've applied for a cross-project session,
so if that gets approved, it might be a good place.




Case study: https://review.openstack.org/#/c/228186

Someone identifies and sends in a patch that fixes a technical problem, 
some outdated text - a one sentence change. Though the wording could 
perhaps be tweaked, their fix is technically accurate.


Our current response: 6 reviewers marking the patch down because the bug 
wasn't confirmed.




Regards,


Tom




--
Mailing list: https://launchpad.net/~openstack-doc-core
Post to : openstack-doc-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-doc-core
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack-doc-core] DocImpact - What to do?

[Tom Fifield]

On 26/06/15 08:01, Lana Brindley wrote:
 On 25/06/15 18:05, Tom Fifield wrote:
 On 25/06/15 10:03, Lana Brindley wrote:
 Hi core team,

 One of the things that came up as a pain point at Summit was the DocImpact 
 automation. I�ve been doing some thinking about this, and this is where I�m 
 at right now:

 Workflow: Devs create a patch, and at commit time they think oh yeah, 
 probably there should be some docs about that and whack in a 'DocImpact' 
 flag. In other words, there's not a lot of thought going in here, it's just 
 an easy thing to do, they get a warm fuzzy, and there�s an assumption that 
 the documentation fairy comes along and takes care of things. In reality, 
 what then happens is some docs triager spends an hour looking at the patch, 
 searching through the docs, then deciding it has nothing to do with 
 openstack-manuals. Often, the actual doc impact (if there even is one) is 
 against docs in the dev repo, not openstack-manuals.

 In short, devs recognise they need docs, and DocImpact is an easy way to 
 feel like they're doing something productive to make that happen. What 
 really happens is that those bugs are largely irrelevant for 
 openstack-manuals, which puts pressure on our core team to triage them 
 effectively. To try and get some perspective on the size of the problem, 
 here are some numbers:

 Of the 508 current openstack-manuals bugs, 214 are the result of the 
 DocImpact script. 51 of these are yet to be triaged.
 Right now, there are 170 patches in-flight with the DocImpact tag. To state 
 the obvious, if all them land, that�s 170 new bugs in our queue.

 So, solutions:

 1: We have a crack team of docs people (potentially with automation 
 assistance) going through docimpact bugs, cc'ing the original patch 
 authors, and moving them into dev repos where necessarily, and marking the 
 rest invalid. We could team this with a an education campaign on the dev 
 mailing list.

 2: We ditch docimpact, and force devs to create their own docs bugs (and 
 patches). This would mean fewer devs get on with the job of documentation, 
 but at least what we do get would be well-considered, rather than hastily 
 added to their commit message.

 3: We adjust docimpact to raise a bug in their own dev repo. So, patch 
 against swift with docimpact raises a bug in the swift bug queue, not the 
 openstack-manuals doc queue. Maintenance overhead then remains with dev, 
 and I bet you any money they would self-police that better than we ever 
 could.

 4: Some other thing I haven�t thought of yet � ?

 I have a feeling 3 is where the money's at. I took the liberty of quickly 
 checking with an Infra core, and this change should be relatively easy to 
 implement, too, for the record.

 Thoughts?
 
 
 Combo of modified #1  modified #3, with a bit of #4 (communication back
 on their patch), with a bit of #5 (modified docimpact parameters).
 
 Can you elaborate?

That is indeed the plan :) Coming back to this in the next few days I
hope - sorry for the delay!

-- 
Mailing list: https://launchpad.net/~openstack-doc-core
Post to : openstack-doc-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-doc-core
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack-doc-core] DocImpact - What to do?

[Tom Fifield]

On 25/06/15 10:03, Lana Brindley wrote:
 Hi core team,
 
 One of the things that came up as a pain point at Summit was the DocImpact 
 automation. I�ve been doing some thinking about this, and this is where I�m 
 at right now:
 
 Workflow: Devs create a patch, and at commit time they think oh yeah, 
 probably there should be some docs about that and whack in a 'DocImpact' 
 flag. In other words, there's not a lot of thought going in here, it's just 
 an easy thing to do, they get a warm fuzzy, and there�s an assumption that 
 the documentation fairy comes along and takes care of things. In reality, 
 what then happens is some docs triager spends an hour looking at the patch, 
 searching through the docs, then deciding it has nothing to do with 
 openstack-manuals. Often, the actual doc impact (if there even is one) is 
 against docs in the dev repo, not openstack-manuals.
 
 In short, devs recognise they need docs, and DocImpact is an easy way to feel 
 like they're doing something productive to make that happen. What really 
 happens is that those bugs are largely irrelevant for openstack-manuals, 
 which puts pressure on our core team to triage them effectively. To try and 
 get some perspective on the size of the problem, here are some numbers:
 
 Of the 508 current openstack-manuals bugs, 214 are the result of the 
 DocImpact script. 51 of these are yet to be triaged.
 Right now, there are 170 patches in-flight with the DocImpact tag. To state 
 the obvious, if all them land, that�s 170 new bugs in our queue.
 
 So, solutions:
 
 1: We have a crack team of docs people (potentially with automation 
 assistance) going through docimpact bugs, cc'ing the original patch authors, 
 and moving them into dev repos where necessarily, and marking the rest 
 invalid. We could team this with a an education campaign on the dev mailing 
 list.
 
 2: We ditch docimpact, and force devs to create their own docs bugs (and 
 patches). This would mean fewer devs get on with the job of documentation, 
 but at least what we do get would be well-considered, rather than hastily 
 added to their commit message.
 
 3: We adjust docimpact to raise a bug in their own dev repo. So, patch 
 against swift with docimpact raises a bug in the swift bug queue, not the 
 openstack-manuals doc queue. Maintenance overhead then remains with dev, and 
 I bet you any money they would self-police that better than we ever could.
 
 4: Some other thing I haven�t thought of yet � ?
 
 I have a feeling 3 is where the money's at. I took the liberty of quickly 
 checking with an Infra core, and this change should be relatively easy to 
 implement, too, for the record.
 
 Thoughts?


Combo of modified #1  modified #3, with a bit of #4 (communication back
on their patch), with a bit of #5 (modified docimpact parameters).


While I fully agree that DocImpact is in am imperfect state, and
developers are falling into the magic fairy trap, I want to first go
back to the reason DocImpact exists and understand the large benefit it
does give us, despite misgivings.

Prior to enlisting developer assistance to identify patches that
potentially resulted in the need for some documentation, our team had to
put in an enormous amount of effort to try and work out what was going
on dev-wise. We kinda had an inkling that there were some new features
going in, and there were probably some pretty important bugs being
fixed. To work that out, it involved reading almost every single
blueprint for features, and then trying to read a few hundred random
patches that looked interesting enough that they might result in docs.

What the introduction of DocImpact did was, for the most part, solve
this tracking problem. We successfully leveraged the collective
developer effort to let us know what the interesting things were.

Our developers aren't perfect in doing this, but in general, we get bugs
lodged so we can track major features, ensure our scripts for config
changes are working, and find out rather important updates.

In addition, we are able to fairly apply a priority to the patch that
comes in. Vendor driver? Don't really care: low.
Deprecation/Introduction of a major feature? Important: High. Bug Fix
that seriously changes behaviour: High. See also
https://wiki.openstack.org/wiki/Documentation/HowTo#Doc_Bug_Triaging_Guidelines

Though flawed and in need of a serious kick in the pants, currently
DocImpact provides the only place this tracking occurs.

So, whatever solution we adopt, wherever/however it ends up, we need to
make sure this tracking ability continues - leveraging the effort of
many to filter the firehose a little.


I now think this email is too long - I think I might address my first
line response/actual solution ideas in a separate one instead, standby!





Regards,


Tom




-- 
Mailing list: https://launchpad.net/~openstack-doc-core
Post to : openstack-doc-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-doc-core
More help   

[Openstack-doc-core] [Bug 1110137] Re: running openstack guide is exhaustive to the point of being past useful

[Tom Fifield]

** Changed in: openstack-manuals
 Assignee: (unassigned) = OpenStack Documentation Coordinators 
(openstack-doc-core)

** Changed in: openstack-manuals
   Status: Fix Committed = Fix Released

-- 
You received this bug notification because you are a member of OpenStack
Documentation Coordinators, which is a bug assignee.
https://bugs.launchpad.net/bugs/1110137

Title:
  running openstack guide is exhaustive to the point of being past
  useful

Status in OpenStack Manuals:
  Fix Released

Bug description:
  running openstack guide is exhaustive to the point of being past
  useful.

  It lacks a clear path from 0 to 100.

  It contains too much information

  eg Examples of model names in CPU.

  There is a lack of clear linkage between the sections.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-manuals/+bug/1110137/+subscriptions

-- 
Mailing list: https://launchpad.net/~openstack-doc-core
Post to : openstack-doc-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-doc-core
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] IMPORTANT: Openstack List Migration (Please read)

[Tom Fifield]

On 26/07/13 00:09, Sylvain Bauza wrote:
 Le 25/07/2013 18:34, Thierry Carrez a écrit :
 My understanding is that the current subscriptions will be migrated to
 the new list automatically. I suspect that direct subscription will not
 be available until the migration occurred.
 Thanks, hope so as well.
 
 Could s/o clarify ?

This is correct.

You will be automagically migrated to the new list, and from then on you
should send emails to openst...@lists.openstack.org, not anything with
'launchpad' in it :)

Pro Tip: ensure your email client filters are updated for the new list,
if necessary.

The work going on is documented at
https://etherpad.openstack.org/mailmain-migration-notes if you have
interest.

Regards,

Tom


___
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 did openstack choose ceph (and not glusterfs)

[Tom Fifield]

Hi,

Community Manager here - just confirming - OpenStack has not chosen 
Ceph. Not sure where that information is coming from - got a blog link 
so we can fix any confusion? :)



Regards,

Tom

On 12/07/13 10:23, Zippy Zeppoli wrote:

Hello,
I apologize if this email causes some kind of subjective ruckus, but
frankly I don't care (sorry etiquette) since it will resolve a
reasonable question that isn't clearly answered on the web.

Why did openstack choose ceph and not glusterfs. There doesn't seem to
be a lot of (good) information on how/why to choose one over the other,
and I'm sure most folks do a proof-of-concept to figure this out, but it
doesn't seem like a lot of information has been shared on the matter.

That being said, OpenStack is a large open source project that has
decided to use this storage platform (big decision). Why and how did the
technical architects for OpenStack come to this decision (blog post
would be awesome, wasn't able to find one Googling).

CheerZ



___
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-doc-core] Adding members to openstack-doc-core

[Tom Fifield]

+2

On 02/07/13 12:45, Lorin Hochstein wrote:
 Hi Anne:
 
 Both additions to doc-core sound good to me.
 
 Take care,
 
 Lorin
 
 
 On Mon, Jul 1, 2013 at 10:14 PM, Anne Gentle a...@openstack.org 
 mailto:a...@openstack.org wrote:
 
 Hi all you doc-core members! I have a couple of candidate ideas for
 your consideration.
 
 1. Steven Deaton has been working with Tom a lot on doc automation
 and tooling around DocImpact. I think he'd be a good addition to
 doc-core and I'd like to extend the invitation even though he's not
 writing content or doing reviews. David Cramer, the maintainer of
 the Maven plugin for our builds, is on doc-core and is in this
 category as well, so I believe there's enough precedence set to make
 Steven Deaton a match for doc-core. Any concerns about this one?
 
 2. The Security Guide team talked with me about adding their own
 separate repo for their new book, and then having a -core team just
 for that book for their reviews. I don't imagine that's a good
 scalable idea, so I suggested that we just add those who are
 interested to the openstack-doc-core list, and they can bring their
 content into openstack-manuals and manage reviews within that
 context. So far I don't have objections from them on this idea, and
 I think it's a good way to try to get more review eyes on the rest
 of the repo. What I'm suggesting is that as a general rule, if
 you've participated fully in a book sprint, you can apply to become
 an openstack-doc-core member. Does that general rule make sense? Any
 other thoughts or ideas?
 
 Hope you don't mind me combining these two separate ideas in one
 email, but they're related to expanding our merry crew with some new
 rules so I wanted to get input.
 Thanks,
 Anne
 
 --
 Mailing list: https://launchpad.net/~openstack-doc-core
 Post to : openstack-doc-core@lists.launchpad.net
 mailto:openstack-doc-core@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack-doc-core
 More help   : https://help.launchpad.net/ListHelp
 
 
 
 
 -- 
 Lorin Hochstein
 Lead Architect - Cloud Services
 Nimbis Services, Inc.
 www.nimbisservices.com http://www.nimbisservices.com
 
 


-- 
Mailing list: https://launchpad.net/~openstack-doc-core
Post to : openstack-doc-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-doc-core
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Does cell support qpid

[Tom Fifield]

I could also be very wrong here, but my impression was while most of 
nova does work in that way, I believe cells is a special case and only 
really supports rabbitmq right now...



Regards,

Tom


On 03/06/13 22:01, Endre Karlson wrote:

What I'm writing here might be uncorrect but here goes.

I think the Qpid support is just to change the config parameter in
nova.conf to the class that has Qpid no?.

I think the support is handled in the different api classes and not at
the MQ transport library level.

Endre


2013/6/3 Lau Jay jay.lau@gmail.com mailto:jay.lau@gmail.com

Hi Chris and Stackers,

I'm trying to do some evaluation on cell, does cell also support
qpid? If support, how to configure?

Thanks,
Jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
mailto: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] How to install a Network Node ?

[Tom Fifield]

On 03/06/13 07:49, Alexandre De Carvalho wrote:

Hi !


Hi!


I followed this document :
http://docs.openstack.org/grizzly/basic-install/apt/content/basic-install_network.html
 but
i have a problem with the dhcp agent.
And there are some mistakes in the official document.


We need your help. Please report any mistakes in the documents at 
https://bugs.launchpad.net/openstack-manuals/+filebug :)


Regards,

Tom

___
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] Reg: Compute node resources sharing Clarification

[Tom Fifield]

It sounds like you need something like ScaleMP 
(http://www.scalemp.com/products/selective-scaling/).


OpenStack treats servers as servers - it won't magically combine CPUs 
from different machines to form a single VM.


Regards,

Tom

On 03/06/13 13:26, Dhanasekaran Anbalagan wrote:

Hi Lau,

over commit not helping me. Because I need aggregate the servers. few
machine having 8 cores. others 16 and 32 cores also we will do load
testing of the machine. My plan is cores aggregation. to spin up the
instance. If any other project helps my requirement.

Please guide me.

-Dhanasekaran.

Did I learn something today? If not, I wasted it.


On Sat, Jun 1, 2013 at 11:00 AM, Lau Jay jay.lau@gmail.com
mailto:jay.lau@gmail.com wrote:

Does resource over commit can help? I mean enable RamFilter and
CoreFilter for resource over commit.

Thanks,

Jay


2013/6/1 Joe Gordon joe.gord...@gmail.com
mailto:joe.gord...@gmail.com




On Fri, May 31, 2013 at 8:20 AM, Dhanasekaran Anbalagan
bugcy...@gmail.com mailto:bugcy...@gmail.com wrote:

Hi Guys,

I would like to know how the sharing of resources happening
in OpenStack. Assume that there are two compute nodes of 4
physical cores each with 16 GB of Physical RAM each, would I
be able to start an instance with 8 cores and 32 Gb of RAM.
How this is handled in Openstack.


Currently this is not supported.

Please guide me.

-Dhanasekaran.


Did I learn something today? If not, I wasted it.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
mailto: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
mailto: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] Import professional translations

[Tom Fifield]

This is an amazing contribution! I also think option #1 is a good
starting point :)


On 15/05/13 19:01, Ying Chun Guo wrote:
 Hi,
 
 My company, IBM, has finished the translation of messages in Nova,
 Glance, Keystone, Quantum and Cinder
 to 9 languages (de, es, fr, it, ja, ko, pt_BR, zh_CN, zh_TW) for
 Grizzly, by outsourcing to professional
 translators. We tend to contribute these translations to community.
 
 Some volunteers have done part of the translations in Transifex. The
 average completion percentage among all
 these 9 languages is below 20%. If we can merge these professional
 translations into Transifex, we can improve
 the completion percentage to a very high number.
 
 In my mind, there are several ways to import professional translation to
 Transifex:
 
 1. Merge the professional version of po files and community version,
 using the professional version when conflicting.
 2. Merge the community version of po files and professional version,
 using the community version when conflicting.
 3. Import the professional translations as translation memory, thus the
 professional translations will appear
 as suggestion while volunteers do the translation in Transifex.
 
 I prefer the first one, because it can improve the percentage of
 translation completion very quickly,
 while the third one needs some time for volunteers to review the strings
 one by one. What's more, the quality of
 professional version should be better.
 
 I'm going to start this work. If you have any different opinions, please
 let me know.
 
 Regards
 Ying Chun Guo (Daisy)
 
 
 ___
 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] release process and sample configs

[Tom Fifield]

On 30/04/13 02:12, Anne Gentle wrote:
 
 
 
 On Mon, Apr 29, 2013 at 10:50 AM, Thierry Carrez thie...@openstack.org
 mailto:thie...@openstack.org wrote:
 
 Darren Birkett wrote:
  I've noticed that a lot of the projects do not get their sample
 configs
  updated as part of the release process.  I'd suggest that one of the
  final commits to each project before a release is cut, is to
 update the
  sample config so it's relevant to the codebase that's being
 released and
  packaged.
 
  For those that aren't aware, in each project there is a script
 that can
  be run that will parse the entire project tree and extract all options
  cleanly into a new sample config file, so it need not be an
 onerous task
 
 
 Yes, docs uses that sample config file. We also have a Blueprint in
 progress to automatically generate docs from conf code. [1] Tom Fifield
 has a working proof-of-concept I believe.

Just confirming it exists - standby for the first cut of new
automagic-from-code config option table creation. It will need feedback.

 
 We do need developers to group config settings in ways that make sense
 to deployers. We can try to keep an eye on code that does this but
 ideally each project will know to keep an eye out for merges that should
 include re-built sample config files.
  
 
 That's a very good point. This should be done before the first release
 candidate is cut -- and tested/refreshed if necessary afterwards. I'll
 add it to the release process.
 
  I also think that the entire sample config should go into the docs
 for a
  release, so that people (non devs) don't need to hunt around in the
  source code to find the elusive option they want to use.
 
 I'll let Anne comment on that, but it sounds sane to me :)
 
 
 I think it's a fantastic idea and we want to make it worth your while.
 
 Anne
 
 [1]
 https://blueprints.launchpad.net/openstack-manuals/+spec/autogenerate-config-tables


___
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-community] OpenStack Teacher /Student Certification

[Tom Fifield]

Hi all,
(apologies to the many lists - I'm not sure if all of you are
interested, but wanted to keep the original CCs just in case)

I'm also working on content for a masters-level course involving OpenStack.

Since so many are interested, perhaps we should have a meeting to
discuss aims and potential pooled efforts? (or just start an etherpad?)

It's important to note that there are different levels at which this can
be pitched. That is, from teaching until being 'able to use' an
OpenStack cloud, through to being 'able to develop' the middleware - and
at various degrees within each level. Of course, a lot of content is
common and any such academic effort should see how it ties in with the
recent questions about training material. Perhaps the first step is to
collate our various plans and see where compatibilities are ?


Regards,


Tom



On 28/04/13 23:34, Frans Thamura wrote:
 Tim
 
 Glad you do a smiliar work with me.
 
 Yes. Agree. Curriculum is more.important.
 
 My experience. For student handout step by step also a good way to teach.
 
 I will share.my ToC.of openstack content that we develop asap. Because
 it is Indonesian language. It is open content witg creative.license.
 
 I think global work for this work will be awesome to groq commmunity and
 also standard.
 
 Frans
 
 On Apr 28, 2013 8:19 PM, Tim Horgan tim.hor...@cit.ie
 mailto:tim.hor...@cit.ie wrote:
 
 Hi Frans,
 
 I work in the Higher Education (HE) sector at Cork Institute of
 Technology (CIT), Ireland (www.cit.ie http://www.cit.ie) and I'm
 also the organiser of OpenStack Ireland meetups
 (http://www.meetup.com/OpenStack-Ireland/). At CIT we run various
 cloud related academic programmes (http://cloud.cit.ie) which are
 delivered online to a global audience. For sometime now I have been
 thinking about offering an online course related to OpenStack and
 would be delighted to hear views from you and others about this
 suggestion. Your ideas about certification are great but we probably
 would need to focus on the curriculum first.
 
 One idea that I have had is to explore the possibility of setting up
 and running a free MOOC
 (http://en.wikipedia.org/wiki/Massive_open_online_course) similar to
 https://www.coursera.org/. This would allow us to reach a scalable
 global audience. Coming from the HE sector I can help with
 certification and have extensive knowledge of online delivery,
 that's my day job!
 
 Regards,
 Tim
 
 
 
 
 On 28 Apr 2013, at 12:50, Frans Thamura fr...@meruvian.org
 mailto:fr...@meruvian.org wrote:
 
 hi all

 I am working with Education, take a look www.jeni-academy.org
 http://www.jeni-academy.org

 now i am thinking to create OpenSTack + CLoudFoundry certification,
 that we will give to the teacher in every school (targeting vocational
 highschool/secondary school and polytechnics).

 any one can work together for this? because I want to put logo in our
 certification

 for OpenStack, where is the place i can ask for this permission?

 this program usually part of my experience create user group,

 every school or region of state will become regional academy = state
 based user group,


 I love to work together with anyone outside Indonesia, for smiliar
 work, so we can create one content, one program, and better result.


 West JAva State only, have 263 schools , and around 12.000 school
 target all over Indonesia, that will be interesting work, around
 500.000 student.

 right now they focus is IaaS, and our focus in JAva User
 Group/JENI is PaaS.

 Microsoft asks me to put Azure, but they cannot provide the license
 for education, so I give the rest of the network to OpenStack.. plus
 CloudFoundry


 Right now we use Ubuntu..

 NB: I wish Redhat interest with this, but I email to RH SEA, no
 program for this yet in our region.



 We have create a free material to setup, deploy, setup OpenSTack and
 CloudFoundry, the missing thing is
 --
 Frans Thamura (曽志胜)
 Shadow Master and Lead Investor
 Meruvian.
 Integrated Hypermedia Java Solution Provider.

 Mobile: +628557888699 tel:%2B628557888699
 Blog: http://blogs.mervpolis.com/roller/flatburger (id)

 FB: http://www.facebook.com/meruvian
 TW: http://www.twitter.com/meruvian / @meruvian
 Website: http://www.meruvian.org

 We grow because we share the same belief.

 ___
 Community mailing list
 commun...@lists.openstack.org mailto:commun...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/community
 
 
 
 -
 *TIM HORGAN*
 Head of Online Delivery
 Cork Institute of Technology, Cork, Ireland
 phone: +353 214335120 callto:+353%2021%204335120 | mobile: +353 

Re: [Openstack] Thanks for using DocImpact

[Tom Fifield]

With Havana development starting, we're already seeing some DocImpacts 
coming in - thanks for those!


We want to sure we catch all those removals, deprecations and pent-up 
updates that tend to come in at the beginning of the cycle.


So, as usual:


 If your commit could have an impact on documentation - be it an
 added/altered/removed commandline option, a deprecated or new feature, a
 caveat, if you've written docs in the patch, or if you're just not sure
 - there's a way to let us know.

 = Just add DocImpact to a line in your commit message.

 This sends us an email so we can triage. It doesn't guarantee docs will
 be written, but at least it gives us visibility of the changes.



Don't forget to tell your friends :)


Regards,


Tom, on behalf of the docs team


On 03/01/13 13:25, Tom Fifield wrote:

Hi all,

Just wanted to drop a quick note on the list to say thanks to all who
have gone to the effort of using the DocImpact flag in your commit messages.

We're now receiving a steady stream of useful information on changes
that affect the documentation, and logging and targeting them[1][2]. The
aim is that as Grizzly is released, the manuals should be much more up
to date than in previous releases.

Of course, the workload[3] is still a struggle, so any help[4] fixing up
docbugs is much appreciated :)

Thanks again for your efforts!

Regards,


Tom, on behalf of the docs team

[1] https://bugs.launchpad.net/openstack-manuals/+milestone/grizzly
[2] https://bugs.launchpad.net/openstack-api-site/+milestone/grizzly
[3] http://kiks.webnumbr.com/untouched-bugs-in-openstack-manuals-
[4] http://wiki.openstack.org/Documentation/HowTo

On 30/10/12 12:31, Tom Fifield wrote:

TL;DR - If anything you submit could have an impact on documentation,
just add DocImpact to a line in your commit message.

Developers,


We need your help.

In the face of the 500 contributors to the code base, those small
handful of us working on documentation are losing the war.

One of the worst pains we have right now is that we're not getting
information from you about the changes you make. We just don't have the
people to review every single commit on every single project for its
impact on documentation.

This is where you can make a difference.

If your commit could have an impact on documentation - be it an
added/altered/removed commandline option, a deprecated or new feature, a
caveat, if you've written docs in the patch, or if you're just not sure
- there's a way to let us know.

= Just add DocImpact to a line in your commit message.

This sends us an email so we can triage. It doesn't guarantee docs will
be written, but at least it gives us visibility of the changes.


Thanks for reading.

As always - if you have any time to write/fix docs, we've more than one
hundred bugs waiting for your contribution . . .


Regards,


Tom, on behalf of the docs team.



___
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] Documentation - Push for Grizzly

[Tom Fifield]

Hi all,

We need your help to get the documentation up to scratch for grizzly.

Please see if there is anything you can address from the list at:

https://bugs.launchpad.net/openstack-manuals/+milestone/grizzly

55 bugs ready for your work
59 completed so far, 8 in progress

Thanks to the efforts of everyone who used DocImpact, for the first time
we actually have a reasonable list of changes between Grizzly and Foslom
to document - which is triaged into the above link.

The docs process follows the same GerritWorkflow as the code, and uses a
pretty straightforward XML syntax (
https://wiki.openstack.org/wiki/Documentation/Conventions ). If the
syntax, or maven build is giving you pain - submit what you have for
review and we'll fix it.

If you hate writing - perhaps instead, pick your favourite topic at
http://docs.openstack.org/trunk/ and nitpick for correctness ;)

For any help, please grab us at #openstack-doc,
openstack-d...@lists.openstack.org, or feel free to contact me direct if
you don't feel comfortable.


Regards,


Tom
on behalf of the Docs team.

___
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] Project quotas on multi-region

[Tom Fifield]

On 24/03/13 23:36, Tim Bell wrote:
  
 
 The Boson project was looking at this sort of problem
 (https://wiki.openstack.org/wiki/Boson).
 
  
 
 There is a session at the summit to review this and other activities
 since it appears quotas are appearing in many projects and there is a
 clear need for multi-cell and quota delegation (i.e. domain quota
 manager gives sub-sections to project quota managers). This sort of
 function is quite complex to implement and consistency of implementation
 would be strongly desirable.

Indeed. Cells right now supports the centralised quotas that Glaucimar
needs, but doesn't deal with situations where certain projects have
quotas on certain cells.

 
  
 
 Tim
 
  
 
 *From:*openstack-bounces+tim.bell=cern...@lists.launchpad.net
 [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] *On
 Behalf Of *Nathanael Burton
 *Sent:* 24 March 2013 02:31
 *To:* Aguiar, Glaucimar (Brazil RD-ECL)
 *Cc:* OpenStack Development Mailing List; openstack@lists.launchpad.net
 *Subject:* Re: [Openstack] Project quotas on multi-region
 
  
 
 On Mar 23, 2013 7:59 PM, Aguiar, Glaucimar (Brazil RD-ECL)
 glaucimar.agu...@hp.com mailto:glaucimar.agu...@hp.com wrote:

 Hi,

 In a deployment scenario where one keystone has several regions
 registered, how the project quota are managed by, as an example, two
 nova services in two different regions?
 I am wondering if is it possible to set quota on the project for all
 regions or this must to be done on a region by region basis which really
 means a quota for a project in a region.

 Thanks in advance,
 Glaucimar Aguiar




 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 mailto:openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp
 
 Glaucimar,
 
 Currently quotas are maintained within each nova system so there is not
 a global view/management/enforcement of quotas. I would love to see a
 discussion of centralizing things from nova like key pairs, AZs, and
 quotas in keystone.
 
 Thanks,
 
 Nate
 
 
 
 ___
 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] Glance with S3 backend

[Tom Fifield]

I'll take the blame for the S3 backend miscomment - apologies - I have
updated the book online.

In exchange, I would, however, be interested in where those typo and
grammatical errors are :)

Regards,

Tom

On 08/03/13 07:43, Jay Pipes wrote:
 Yes, it certainly can write images to the S3 backend.
 
 Best,
 -jay
 
 On 03/07/2013 03:02 PM, Logan McNaughton wrote:
 From docs.openstack.org http://docs.openstack.org:
 Written in a five-day book sprint in February 2013, targeting the
 Folsom release for stability. 

 Anyway, that's beside the point, I'm really just wondering if Glance can
 write images and snapshots to an S3 backend?


 On Thu, Mar 7, 2013 at 2:43 PM, Brad Knowles bknow...@momentumsi.com
 mailto:bknow...@momentumsi.com wrote:

 On Mar 7, 2013, at 1:37 PM, Logan McNaughton lo...@bacoosta.com
 mailto:lo...@bacoosta.com
  wrote:

  PS: I know the goal of the Operations Guide was to finish it in 5
 days, but there are a lot of typos and grammatical errors...maybe 7
 days next time?

 It's a living document, and it was produced as a step towards the
 Grizzly Release Candidate that is scheduled to be made available in
 April.  So, you have plenty of time to contribute various changes to
 help correct any problems that you might run across.

 As for myself, I'm currently going through the installation
 documentation [1] with a fine-toothed comb.  As I run into things
 that appear to be wrong or need to otherwise be updated, I'm filing
 bug reports and associated commits to fix them.  I know that I draw
 my experience from the community, and this is one way that I try to
 contribute back to the community in return.



 [1]
 
 http://docs.openstack.org/trunk/openstack-compute/install/apt/content/ap_installinggrizzlyubuntuprecise.html

 --
 Brad Knowles bknow...@momentumsi.com mailto:bknow...@momentumsi.com
 Senior Consultant




 ___
 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] List of Cinder compatible devices

[Tom Fifield]

Here's a starting point:

http://wiki.openstack.org/CinderSupportMatrix

Regards,

Tom

On 31/01/13 09:00, Sébastien Han wrote:
 + RBD (Ceph)
 
 +1 for the matrix, this will be really nice :-)
 --
 Regards,
 Sébastien Han.
 
 
 On Wed, Jan 30, 2013 at 5:04 PM, Tim Bell tim.b...@cern.ch wrote:


 Is there a list of devices which are currently compatible with cinder and
 their relative functionality ?



 Looking through the source code, there are EMC, IBM, NetApp, Nexenta but it
 is not clear which models are supported or if there are other products also.



 A functionality matrix (like there is for hypervisors in Nova) would be very
 useful.



 Tim




 ___
 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-doc-core] Welcome Salvatore Orlando to doc-core

[Tom Fifield]

Welcome ;)

On 29/01/13 07:33, Razique Mahroua wrote:
 Hi Salvatore!
 Welcome in the team :)
 
 
 
 *Razique Mahroua** - **Nuage  Co*
 razique.mahr...@gmail.com mailto:razique.mahr...@gmail.com
 Tel : +33 9 72 37 94 15
 
 
 Le 28 janv. 2013 à 21:30, Anne Gentle a...@openstack.org
 mailto:a...@openstack.org a écrit :
 
 Hi all -

 Salvatore is going to be doing bug triaging for the Quantum API, so
 I'd like him to be able to work on bugs in the openstack-api-site
 project. So, let's welcome him to the core documentation team! He has
 also submitted doc patches for Quantum and done reviews.

 Welcome Salvatore -- use your new found power wisely!

 Anne
 -- 
 Mailing list: https://launchpad.net/~openstack-doc-core
 Post to : openstack-doc-core@lists.launchpad.net
 mailto:openstack-doc-core@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack-doc-core
 More help   : https://help.launchpad.net/ListHelp
 
 
 


-- 
Mailing list: https://launchpad.net/~openstack-doc-core
Post to : openstack-doc-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-doc-core
More help   : https://help.launchpad.net/ListHelp

[Openstack] Thanks for using DocImpact

[Tom Fifield]

Hi all,

Just wanted to drop a quick note on the list to say thanks to all who
have gone to the effort of using the DocImpact flag in your commit messages.

We're now receiving a steady stream of useful information on changes
that affect the documentation, and logging and targeting them[1][2]. The
aim is that as Grizzly is released, the manuals should be much more up
to date than in previous releases.

Of course, the workload[3] is still a struggle, so any help[4] fixing up
docbugs is much appreciated :)

Thanks again for your efforts!

Regards,


Tom, on behalf of the docs team

[1] https://bugs.launchpad.net/openstack-manuals/+milestone/grizzly
[2] https://bugs.launchpad.net/openstack-api-site/+milestone/grizzly
[3] http://kiks.webnumbr.com/untouched-bugs-in-openstack-manuals-
[4] http://wiki.openstack.org/Documentation/HowTo

On 30/10/12 12:31, Tom Fifield wrote:
 TL;DR - If anything you submit could have an impact on documentation,
 just add DocImpact to a line in your commit message.
 
 Developers,
 
 
 We need your help.
 
 In the face of the 500 contributors to the code base, those small
 handful of us working on documentation are losing the war.
 
 One of the worst pains we have right now is that we're not getting
 information from you about the changes you make. We just don't have the
 people to review every single commit on every single project for its
 impact on documentation.
 
 This is where you can make a difference.
 
 If your commit could have an impact on documentation - be it an
 added/altered/removed commandline option, a deprecated or new feature, a
 caveat, if you've written docs in the patch, or if you're just not sure
 - there's a way to let us know.
 
 = Just add DocImpact to a line in your commit message.
 
 This sends us an email so we can triage. It doesn't guarantee docs will
 be written, but at least it gives us visibility of the changes.
 
 
 Thanks for reading.
 
 As always - if you have any time to write/fix docs, we've more than one
 hundred bugs waiting for your contribution . . .
 
 
 Regards,
 
 
 Tom, on behalf of the docs team.


___
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-doc-core] Doc meeting Tues. 1300 UTC #openstack-meeting

[Tom Fifield]

If my timezone math is correct, this is approximately now - see you all
there!

Regards,

Tom

On 13/11/12 07:01, Anne Gentle wrote:
 Hi all -
 
 As we discussed last month, we'll have our Doc Team meeting in
 #openstack-meeting at 13:00 UTC Tuesday.
 http://www.timeanddate.com/worldclock/meetingtime.html?iso=20121113p2=24p3=33
 
 Feel free to add anything to the Doc Team meeting agenda at
 http://wiki.openstack.org/Meetings/DocTeamMeeting.
 
 We're changing our schedule to accommodate more sunshine time on the
 other side of the world.
 
 See you then and there!
 
 Thanks,
 Anne
 


-- 
Mailing list: https://launchpad.net/~openstack-doc-core
Post to : openstack-doc-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-doc-core
More help   : https://help.launchpad.net/ListHelp

[Openstack] Running other services on swift nodes

[Tom Fifield]

Hi,

This came in as a doc bug, but I thought I'd throw it to the list:

https://bugs.launchpad.net/openstack-manuals/+bug/988053

I think it would be worthwhile to talk about what services can be
co-located on the same servers as Swift. For example Can I run Keystone
in combination with Swift Proxy and Swift Storage?

example other potential combo that might not break: glance / swift proxy

I think this is most relevant to small-scale deployments, where there
isn't quite enough hardware to go around, rather than anywhere
approaching best practice ;)


Realistically expecting this is a terrible, terrible idea replies to
this, but perhaps reasons, and the odd outside-the-box idea will be
presented ...


Regards,

Tom

___
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] Action Required: Use DocImpact flag when commits might impact docs

[Tom Fifield]

TL;DR - If anything you submit could have an impact on documentation,
just add DocImpact to a line in your commit message.

Developers,


We need your help.

In the face of the 500 contributors to the code base, those small
handful of us working on documentation are losing the war.

One of the worst pains we have right now is that we're not getting
information from you about the changes you make. We just don't have the
people to review every single commit on every single project for its
impact on documentation.

This is where you can make a difference.

If your commit could have an impact on documentation - be it an
added/altered/removed commandline option, a deprecated or new feature, a
caveat, if you've written docs in the patch, or if you're just not sure
- there's a way to let us know.

= Just add DocImpact to a line in your commit message.

This sends us an email so we can triage. It doesn't guarantee docs will
be written, but at least it gives us visibility of the changes.


Thanks for reading.

As always - if you have any time to write/fix docs, we've more than one
hundred bugs waiting for your contribution . . .


Regards,


Tom, on behalf of the docs team.

___
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] Cells Status

[Tom Fifield]

On 05/10/12 03:40, Joshua Harlow wrote:

Along this type of line, I know we've talked about it before.

But is cells the right way that we want to go? Not that it isn't, but
possibly at the summit we can talk about it in detail before pushing it
into trunk.


Given the overflowing room of people who turned up to the last summit to 
talk about Cells, the enormous amount of positive feedback there, the 
fact it's been so delayed and that the code is already ~done and being 
used in production in some instances, waiting to get it into trunk 
(which is already becoming more and more difficult to do) seems like a 
suboptimal idea.


By all means, discuss the methodology, propose an excellent new idea, 
code it up and rip cells out then. However, knocking back something 
that's this far advanced just seems a little cruel for both those who 
worked so hard, and the deployers who have been screaming for it :)


In NeCTAR's case (perhaps in Rackspace and HP's case before us?), we 
can't wait, we're happy with Cells and we're going live with it whether 
it's in trunk or not. However, it would really, really, really, really 
make it easier to make an awesome OpenStack-based cloud if it was in 
trunk :)


Regards,

Tom



From: Chris Behrens cbehr...@codestud.com mailto:cbehr...@codestud.com
Date: Wednesday, October 3, 2012 4:57 AM
To: Sam Morrison sorri...@gmail.com mailto:sorri...@gmail.com
Cc: openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net, Chris Behrens
cbehr...@codestud.com mailto:cbehr...@codestud.com
Subject: Re: [Openstack] Cells Status

Ok.  This took a lot longer to resolve than I expected, but here we go:

https://github.com/comstud/nova/tree/cells_service

This is rebased against trunk and contains a bunch of new things since
the last branch:

Random fixes for things that trunk broke with cells (deleting instances
for one)
RPC versioning (Thanks to Brian Elliott!)
Split Replies and Bandwidth Updates into their own queues to better deal
with them
A number of admin API extensions modified to support cells (Thanks to
Dragon, Alex Meade, Brian Lamar, Matt Sherborne, et al)
Snapshots/backups query glance in API cell (Thanks to Iccha)
Handle quotas in API cell  (Thanks to Johannes for fixes!)

Things are rapidly getting more kludgy because of changes in trunk that
don't have any consideration for cells (because cells is not in trunk!).
  I'm hoping we can get this into an acceptable shape such that we can
get it merged ASAP.

- Chris


On Oct 2, 2012, at 10:13 PM, Sam Morrison sorri...@gmail.com
mailto:sorri...@gmail.com wrote:


OK great, will be good to get this into master. I have some stuff
relating to key pairs, security groups that I'd like to contribute.

Also we are looking at the ability for you to specify the cell when
booting an instance.

Cheers,
Sam


On 02/10/2012, at 1:06 PM, Chris Behrens cbehr...@codestud.com
mailto:cbehr...@codestud.com wrote:


Yup, it's done.  I just have to deal with some conflicts with our
internal branch and my public one..


On Oct 1, 2012, at 7:47 PM, Sam Morrison sorri...@gmail.com
mailto:sorri...@gmail.com wrote:


On 02/10/2012, at 12:33 PM, Chris Behrens cbehr...@codestud.com
mailto:cbehr...@codestud.com wrote:


Thanks, Tom!  I have changes to push up that add rpc versioning,
etc.  Maybe I can get those up tomorrow.


Great! I was going to start looking into it but will hold off if
you've already done it.

Cheers,
Sam








___
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] Enabling logging in keystone.

[Tom Fifield]

Hi,

Can you please lodge a documentation bug at :

https://bugs.launchpad.net/openstack-manuals/+filebug

Thanks!

Regards,

Tom

On 03/10/12 10:10, Ahmed Al-Mehdi wrote:

Hello,
I have gone through the document numerous times trying to configure
keystone - mistyping keys, wrong key value, missing steps, etc (error
prone). I was looking forward to using the script, as it would save a
lot of typing/pain for a newcomer. However, if there are no plans to
document the script (including adding a name / email to the Readme file
to contact for issues in the script), test, and keep it updated (synced)
with each new release of OpenStack(keystone), then I feel it is best to
remove mention of it from the document.
While at it, the document also mentions a bash script to configure
keystone, which I have not tried. If the bash script suffers from the
same issue, maybe worthconsidering removing it from the document also.
The above are just my opinions.
Regards,
Ahmed.

*From:* Dolph Mathews [dolph.math...@gmail.com]
*Sent:* Tuesday, October 02, 2012 4:50 PM
*To:* openstack@lists.launchpad.net
*Cc:* heckj; Ahmed Al-Mehdi; Anne Gentle
*Subject:* Re: [Openstack] Enabling logging in keystone.

I find it odd that the document describes two approaches for configuring
keystone -- one being a relatively undocumented, scripted approach not
managed or distributed by OpenStack. Surely these two approaches will
continue to evolve seperately and we'll experience more issues such as
this one.

Anyone have any objections to removing this scripted configuration
section in favor of focusing on the existing manual approach?

http://docs.openstack.org/trunk/openstack-compute/install/apt/content/setting-up-tenants-users-and-roles.html

-Dolph


On Tue, Oct 2, 2012 at 6:42 PM, Ahmed Al-Mehdi ah...@coraid.com
mailto:ah...@coraid.com wrote:

Hi Dolph,
I am now getting the same output as the curl command, basically
Invalid Tenant. At this point
root@ubuntu1 mailto:root@ubuntu1:~# keystone
--os-username=adminUser--os-password=secretword--os-tenant-name=service
--os-auth-url=http://10.0.
2.15:35357/v2.0token-get

No handlers could be found for logger keystoneclient.client
Invalid tenant (HTTP 401)
Without the os-tenant-name parameter, I seem to get good' response.
root@ubuntu1 mailto:root@ubuntu1:~# keystone

--os-username=adminUser--os-password=secretword--os-auth-url=http://10.0.2.15:35357/v2.0
token-get
No handlers could be found for logger keystoneclient.v2_0.client
+--+--+
| Property | Value |
+--+--+
| expires | 2012-10-03T23:31:17Z|
| id | 31078072aae94f5aab5c8e46ff5f6373|
| user_id| 3e674f7f64ba452cb20781b8d5e26b7f|
+--+--+
At this point, I feel like I am running into issues with/in the
python / PyYAMLscript (https://github.com/nimbis/keystone-init.git)
which must not be populating info into keystone accurately and
most probably not equivalent to manual steps mentioned in Deployand
Install OpenStack- Red Hat Ubuntu. I will look into the script.
Regards,
Ahmed.

*From:* Dolph Mathews [dolph.math...@gmail.com
mailto:dolph.math...@gmail.com]
*Sent:* Tuesday, October 02, 2012 2:19 PM

*To:* Ahmed Al-Mehdi
*Cc:* heckj; openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
*Subject:* Re: [Openstack] Enabling logging in keystone.

No worries, that's what a second set of eyes is for!

By specifying a token and endpoint, you're bypassing the
authentication process that your curl command is performing.

You can test authentication with the keystone client using:

$ keystone --os-username=adminUser --os-password=secretword
--os-tenant-name=adminTenant
--os-authurl=http://10.0.2.15:35357/v2.0
http://10.0.2.15:35357/v2.0/tokens token-get

But as Anne pointed out, you don't have a tenant named
adminTenant. You'll also need to make sure you've granted a role
to your user on the specified tenant for authorization to succeed.
You can remove the tenant name argument from the token-get call to
test authentication without authorization (therefore without
requiring anything but a valid user in your keystone install).

-Dolph

On Tuesday, October 2, 2012, Ahmed Al-Mehdi wrote:

Hi Dolph,
Very sorry about that.  With the correct token, calling keystone
from the cliis working.However, the curl command is
failing.  Will this cause an issue down the line as I start to
install glance and nova?
# keystone --token 012345SECRET99TOKEN012345--endpoint
http://10.0.2.15:35357/v2.0 tenant-list

[Openstack] Cells Status

[Tom Fifield]

Hi all,

As Chris is a rather busy guy, I've taken the liberty of putting up a 
blueprint and wiki page for Nova Compute Cells.


https://blueprints.launchpad.net/nova/+spec/nova-compute-cells

http://wiki.openstack.org/blueprint-nova-compute-cells

NeCTAR's got to have this feature working well before year-end, and 
recently Sam Morrison and the team at the University of Melbourne have 
been working to try and iron out some of the kinks (security group and 
access key propagation) from Chris' current branch. The plan is to move 
forward and try and update the code from the comstud repo and the local 
changes here to get them into master asap.



Regards,


Tom

___
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] Compute Node Down!

[Tom Fifield]

On 20/09/12 13:50, Vishvananda Ishaya wrote:

**

On Wed, Sep 19, 2012 at 4:03 AM, Wolfgang Hennerbichler
wolfgang.hennerbich...@risc-software.at
mailto:wolfgang.hennerbich...@risc-software.at wrote:

Hello Folks,

Although it seems a pretty straightforward scenario I have a hard
time finding documentation on this.
One of my compute nodes broke down. All the instances are on shared
storage, so no troubles here, but I don't know how to tell openstack
that the VM should be deployed on another compute node. I tried
fiddling around in the mysql-db with no success.
Any help is really appreciated.

Wolfgang





== Dead compute host ==
Working with the host information
pre
i-15b9 at3-ui02 running nectarkey (376, np-rcc54) 0 m1.xxlarge 
2012-06-19T00:48:11.000Z 115.146.93.60

/pre

# review the status of the host using the nova database, some of the 
important information is highlighted below.

pre
SELECT * FROM instances WHERE id = CONV('15b9', 16, 10) \G;
*** 1. row ***
  created_at: 2012-06-19 00:48:11
  updated_at: 2012-07-03 00:35:11
  deleted_at: NULL
...
  id: 5561
...
 power_state: 5
vm_state: shutoff
...
hostname: at3-ui02
host: np-rcc54
...
uuid: 3f57699a-e773-4650-a443-b4b37eed5a06
...
  task_state: NULL
...
/pre

Update the vm's compute host.
pre
UPDATE instances SET host = 'np-rcc46' WHERE uuid = 
'3f57699a-e773-4650-a443-b4b37eed5a06';

/pre

Update the libvirt xml

* change the DHCPSERVER value to the host ip address.
* possibly the VNC IP if it isn't already 0.0.0.0

Dump a copy of a nwfilter to use as a template for creating the missing 
nwfilter.

pre
virsh nwfilter-list
vrish nwfilter-dumpxml nova-instance-instance-.
/pre

Example of the template file
pre
filter name='nova-instance-instance-1cc6-fa163e003b43' chain='root'
  uuidd5f6f610-d0b8-4407-ae00-5dabef80677a/uuid
  filterref filter='nova-base'/
/filter

/pre
The filter name value is available from the instances.xml file 
(filterref filter=nova-instance-instance-1cc6-fa163e003b43).

*Note the filter name must be exact!
Generate a new uuid and replace it at the uuid value.

Update filter to match id from instance xml
pre
virsh nwfilter-define /tmp/filter.xml
virsh define libvirt.xml
virsh list --all
/pre

Kill all dnsmasq and restart nova services.
pre
killall dnsmasq; service nova-network restart; service nova-compute restart
/pre

Start the vm
pre
virsh start instance-0
/pre

On the nova DB
pre
UPDATE instances SET vm_state = 'active', power_state = 1 WHERE uuid = 
'3f57699a-e773-4650-a443-b4b37eed5a06';

/pre

___
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-doc-core] openstack-api-quick-start failing to build

[Tom Fifield]

Hmm,

This had actually been failing for quite some time - probably mid August :) 

Can we get emailed on build failure or some such?

Regards,

Tom

From: Tom Fifield
Sent: Sunday, 16 September 2012 8:47 PM
To: openstack-doc-core@lists.launchpad.net
Subject: openstack-api-quick-start failing to build

Hi,

openstack-api-quick-start is failing to build since adding the quantum client 
user guide:
 Add quantum client user guide. — yong sheng gong / commit  
116236e8f56671aa66d1df3067ee1fde34472a40

Changes:
https://jenkins.openstack.org/view/API-docs/job/openstack-api-quick-start/changes

Console error:
https://jenkins.openstack.org/view/API-docs/job/openstack-api-quick-start/504/console

Will put in a bug


Regards,

Tom


-- 
Mailing list: https://launchpad.net/~openstack-doc-core
Post to : openstack-doc-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-doc-core
More help   : https://help.launchpad.net/ListHelp

[Openstack-doc-core] Pending Reviews

[Tom Fifield]

Hi all,

There's almost 10 pending reviews waiting - some from 5 days ago:

https://review.openstack.org/#/q/status:open+project:openstack/openstack-manuals,n,z


Regards,

Tom

--
Mailing list: https://launchpad.net/~openstack-doc-core
Post to : openstack-doc-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-doc-core
More help   : https://help.launchpad.net/ListHelp

[Openstack] Nova bindings for ... PHP?

[Tom Fifield]

Hi all,

I've been handed an interesting piece of PaaS software (its various 
pieces are in Java, PHP, python and bash!) and told make it work with 
OpenStack.


Noone's done any work to make nova play with PHP, have they?


Regards,


Tom

___
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] Nova bindings for ... PHP?

[Tom Fifield]

On 03/09/12 16:11, Robert Collins wrote:

On Mon, Sep 3, 2012 at 6:07 PM, Tom Fifield fifie...@unimelb.edu.au wrote:

Hi all,

I've been handed an interesting piece of PaaS software (its various pieces
are in Java, PHP, python and bash!) and told make it work with OpenStack.

Noone's done any work to make nova play with PHP, have they?


Depends on what you mean. There may not be a PHP native API, but you
could use http://aws.amazon.com/sdkforphp/

-Rob



Ta. 'What I mean' is probably just the functionality to start and stop 
VMs. Straightforward enough that direct HTTP calls to implement that 
should be fine, but if there was something out there which already has 
the functionality that'd be lovely :)


I've had a play with the AWS SDK, and it needs a bit of work to patch in 
the endpoints, painful but doable. However, the preference is to go 
OpenStack native if possible ...


Regards,

Tom

___
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] Default rules for the 'default' security group

[Tom Fifield]

On 24/08/12 20:50, Yufang Zhang wrote:

2012/8/24 Gabriel Hurley gabriel.hur...@nebula.com
mailto:gabriel.hur...@nebula.com

I traced this through the code at one point looking for the same
thing. As it stands, right now there is **not** a mechanism for
customizing the default security group’s rules. It’s created
programmatically the first time the rules for a project are
retrieved with no hook to add or change its characteristics.

__ __

I’d love to see this be possible, but it’s definitely a feature
request.

__


  Really agreed. I have created a blueprint to track this issue:
https://blueprints.launchpad.net/nova/+spec/default-rules-for-default-security-group


At NeCTAR, rather than modifying the default group we create 3 new 
groups (SSH, ICMP, HTTP/S) for the tenant at the time of tenant 
creation, and found this to be a reasonable compromise between security 
and convenience. This has its issues of course, but perhaps the 
blueprint could be extended to cover the creation of new groups, as well 
as modifying the existing default one . . .




__

__-__Gabriel

__ __

*From:*openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
mailto:nebula@lists.launchpad.net
[mailto:openstack-bounces+gabriel.hurley
mailto:openstack-bounces%2Bgabriel.hurley=nebula@lists.launchpad.net
mailto:nebula@lists.launchpad.net] *On Behalf Of *Boris-Michel
Deschenes
*Sent:* Thursday, August 23, 2012 7:59 AM
*To:* Yufang Zhang; openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
*Subject:* Re: [Openstack] Default rules for the 'default' security
group

__ __

I’m very interested in this, we run essex and have a very bad
workaround for this currently, but it would be great to be able to
do this (set default rules for the default security group).

__ __

Boris

__ __

*De 
:*openstack-bounces+boris-michel.deschenes=ubisoft@lists.launchpad.net

mailto:openstack-bounces+boris-michel.deschenes=ubisoft@lists.launchpad.net

[mailto:openstack-bounces+boris-michel.deschenes=ubisoft@lists.launchpad.net]

mailto:[mailto:openstack-bounces+boris-michel.deschenes=ubisoft@lists.launchpad.net]
*De la part de* Yufang Zhang
*Envoyé :* 23 août 2012 08:43
*À :* openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
*Objet :* [Openstack] Default rules for the 'default' security group

__ __

Hi all,

__ __

Could I ask how to set the default rules for the 'default' security
group for all the users in openstack? Currently, the 'default'
security group has no rule by default, thus newly created instances
could only be accessed by instances from the same group. 

__ __

Is there any method to set default rules(such as ssh or icmp) for
the 'default' security group for all users in openstack, so that I
don't have to remind the new users to modify security group setting
the fist time they logged into openstack and create instances?  I
have ever tried HP could which is built on openstack, they permit
ssh or ping to the instances in the 'default' security group. 

__ __

Best Regards.

__ __

Yufang




___
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] [keystone] Keystone on port 5000 - proposing change default port to 8770

[Tom Fifield]

As an operator, I can say we have had issues with the fact that keystone 
is on port 5000, and wouldn't mind if it changed to something else :)


Regards,

Tom

On 21/06/12 11:19, Dolph Mathews wrote:

Alternatively, if anyone would like to tar and feather me for picking
port 5000 in the first place, I'm available. That said, I have no
attachment to port 5000... but I'm curious, are people experiencing real
issues trying to use port 5000?

-Dolph

On Wed, Jun 20, 2012 at 6:16 PM, Joseph Heck he...@mac.com
mailto:he...@mac.com wrote:

At the risk of a terrible public tar and feathering...

I've learned that port 5000 (which Keystone is using for it's
default public-token-auth stuff) is commonly blocked by many
firewalls, as it's been registered as a Microsoft uPnP port.

I thought I'd go ahead and propose changing the default to 8770. I
picked this number because it's close to the Nova ports in common
use (8773, 8774, 8775, and 8776).

And yes, I'll submit updates to all REST docs, XML docs, devstack,
and the code.

So... how many people do I need to worry about murdering me for this
next design summit?

-joe

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
mailto: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] Identity API v3 - Why allow multi-tenant users?

[Tom Fifield]

Just to echo Tim's comments here about the research space - we certainly 
have this requirement over in NeCTAR (Australia's national cloud for 
research).


Australia actually has entire institutions setup to work in this mode - 
helping out multiple universities simultaneously with software 
development et al, and it's certainly a common case with our OpenStack 
cloud.


Regards,

Tom

On 05/30/2012 07:16 AM, Gabriel Hurley wrote:

Terminology:

Project == Tenant. They are equivalent in Keystone parlance.

What you're referring to as a tenant in that last email is the role a 
domain might play going forward in Keystone.

All the best,

 - Gabriel


-Original Message-
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-
bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of
Caitlin Bestler
Sent: Tuesday, May 29, 2012 11:47 AM
To: Tim Bell; openstack@lists.launchpad.net
Subject: Re: [Openstack] Identity API v3 - Why allow multi-tenant users?

Tim Bell wrote:

➢ In the research environment, we have frequent cases where a user is
associated with multiple tenants.


  For example, when you are finishing work on a previous project but are

mainly working on the new one.


As we move towards domain/tenant/user, we need to ensure that the

tools support multi-tenant per user. Correct accounting is critical.


This does require extra code but it is relevant given the use cases.


What you are describing strikes me as a single tenant with multiple projects.
It is similar to a corporate environment with multiple departments.

I am seeing a major problem here when the tenants are truly separate and
the only possible administrator in common is the service provider.


___
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] I18n issue for OpenStack

[Tom Fifield]

A good idea to separate into two parts, however I fear that the current 
English strings don't serve the first role as well as first appears. 
This has to do with the pre-processing we do on error strings to make 
more accurate searches and error report titles.


A quick, very artificial example:

Unable to get service info: Malformed request url

As English speakers, we can look at this and see that Unable to get 
service info is what happened, and Malformed request url is why.


So, knowing that there are probably many possible reasons for 'why' we 
were Unable to get service info, we might chop this part out of our 
search term, or when we ask for help - and indeed you can see an example 
of this in a title here: 
https://answers.launchpad.net/horizon/+question/190188


In other languages sometimes the sentence order is much different. For 
example, in Chinese, that error could be written something like:


因为错误格式的请求URL所以无法获得服务信息

As a Chinese speaker, you know what this says and you can work out the 
'why' and the 'what' in your search term.


As a non-Chinese speaker, you're stuck putting the whole thing into your 
search engine and hoping that no-one chopped off or changed the 
structural elements of the sentence such as 因为 and 所以.


So, perhaps the part that can be used for searches and bug reports 
really does need to be 'locale-independent'. Complex system of 
impossible to understand error numbers, anyone? ;)



Regards,


Tom

On 04/12/2012 11:46 PM, David Kranz wrote:

Both points of view being expressed about this with respect to log error
messages are valid and need to be accommodated.
An answer, as was suggested a while back, is for error messages to have
two parts:

1. A locale-independent part that can be used for searches or understood
by developers who get logs as parts of bug reports.
2. A localized part that lets operators determine if the problem is
their issue or an OpenStack bug to be reported.

The current English string would serve the first role, and the logging
code could be changed to also emit the localized string if available. I
would argue
for this only in the case of ERROR messages and not DEBUG.

While on the subject of logs, it would be good to agree on what actions
should cause errors in logs to appear. Ideally, they would only occur if
an OpenStack bug
was detected (out-of-bounds array ref, etc.) or some operational problem
occurred (disk ran out of space, etc.). Right now errors are sometimes
output for other
reasons such as bad arguments to api calls. This makes it difficult for
an operator to know when a real problem with the system has occurred.

David Kranz
Quanta Research Cambridge




On 4/12/2012 9:06 AM, Sheng Bo Hou wrote:

Dear OpenStack friends,

It will be happy and great for our OpenStack community to see this
open project open to more market all over the world.
In China, OpenStack community is very active. I heard many Chinese
engineers talking about their wish to have a Chinese versioned
openStack, including documentation's, manuals, user interfaces, error
messages, etc in OpenStack meet-ups.
I have many European friends and also Danish friends, since I used to
do my university there. They all spoke perfect English, which made me
admire, cos they were linguists in my point of view. Oriental
languages are different. They are too far from the western lingual
system. In China, there are many talented engineers, who are not that
kind of linguists, but they are lover of open source. I think it is
amazing to open the door to them. In China, it is very appreciated
for software to be localized as much as possible.
I used to google or baidu(a famous Chinese search engine) error
messages and logs in Chinese for other software, though it is not
Apache. I found a lot of useful references in Chinese, because it has
been localized. If it is not localized well first, of course it does
not have the google or yahoo ability to search.:-)
So far I am rather grateful for all the messages following this i18
issue. Thank you so much.

Best wishes.
Vincent Hou (侯胜博)

Software Engineer, Standards Growth Team, Emerging Technology
Institute, IBM China Software Development Lab

Tel: 86-10-82450778 Fax: 86-10-82453660
Notes ID: Sheng Bo Hou/China/IBM@IBMCN E-mail: sb...@cn.ibm.com
Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang
West Road, Haidian District, Beijing, P.R.C.100193


*Soren Hansen so...@linux2go.dk*
Sent by: openstack-bounces+sbhou=cn.ibm@lists.launchpad.net

2012-04-12 19:50


To
Hua ZZ Zhang/China/IBM@IBMCN
cc
openstack@lists.launchpad.net, Thierry Carrez
thie...@openstack.org,
openstack-bounces+zhuadl=cn.ibm@lists.launchpad.net
Subject
Re: [Openstack] I18n issue for OpenStack









Don't get me wrong.. I'd be happy to have the various openstack
clients offer localised error messages. I'd also encourage a
centralised effort to collect these translationns (so that all the
various language 

Re: [Openstack] Swift, Keystone, and S3 pipeline configuration

[Tom Fifield]

Doesn't the s3token patch by Yoshiyama san fix this for Diablo/Keystone 
... http://www.debian.or.jp/~yosshy/openstack-diablo/s3token.txt ?


Regards,

Tom

On 03/28/2012 08:36 AM, Chmouel Boudjnah wrote:

Hi,

On Tue, Mar 27, 2012 at 10:32 PM, Lillie Ross-CDSR11
ross.lil...@motorolasolutions.com
mailto:ross.lil...@motorolasolutions.com wrote:

Then, if I want to use S3 binding with Swift (Diablo), I need to
used the simpler 'swauth' middleware for authenticatoin? Just wondering.

Yes this is correct.

Cheers,
Chmouel.



___
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] [Swift]Swift Client Synchronization

[Tom Fifield]

Hi,

Which version of Swift are you using?

Do you have the swift3 middleware in the pipeline of your swift proxy? 
(also the s3token if you are using keystone)


Regards,

Tom

On 02/12/2012 09:38 PM, Hieu Le wrote:

Hi again everyone,

I have tried s3fs and there are some problems, can anyone that have
tried s3fs with swift help me solve this ?

The first problem is that s3fs have a format for the password store file
(may be) incompatible for using swift authentication. s3fs password file
have a format like: accessKeyId:secretAccessKey. S3fs use colon symbol
to get ID and secret key, but Swift ID have a format like system:root,
so if I using s3fs password file, it will be: system:root:testpass. S3fs
will not establish an connection to Swift because S3fs can not get ID
and key from above format. :(

I try environment variable for ID and secretkey for solving this, but it
is uncomfortable if I have multiple account. When using environment
variable, I got the second problem. It is when I use s3fs command to
mount folder via https connection, s3fs give me error: s3fs: curlCode:
60 msg: Peer certificate cannot be authenticated with known CA
certificates. I think there may be an error in configuration of curl or
something else, so I disable https and use http instead of. Then s3fs
give me error: Authenticated failed, via log I got Feb 12 14:34:35
swift s3fs: ### CURLE_COULDNT_RESOLVE_HOST
Feb 12 14:34:37 swift s3fs: ###retrying... :( I can not understand why
because I can authenticate and using via Cyberduck successfully.

I'm using fuse 2.8.6, s3fs lastest version and my command is: s3fs
myfiles /mnt -o url=https://192.168.50.110:8080/auth/v1.0

Someone have tried S3fs can give me some help ?

On Sat, Feb 11, 2012 at 9:43 PM, Hieu Le hieul...@gmail.com
mailto:hieul...@gmail.com wrote:

Thank you Stephen, I will try s3fs and give feedback.

I don't want to use Cyberduck or Gladinet, I like mounting
file/folders and work with them like normal folder, so I will try to
use s3fs.

Thank you all :)


On Sat, Feb 11, 2012 at 12:00 AM, Stephen Broeker
sbroe...@internap.com mailto:sbroe...@internap.com wrote:

Looks like you want to mount your Swift Account as a UFS like
file system.
This is called Gateway.
Folks typically use Fuse to do this.
Check out s3fs.

On Fri, Feb 10, 2012 at 7:53 AM, Hieu Le hieul...@gmail.com
mailto:hieul...@gmail.com wrote:

Hello everyone,

I'm starting to study about openstack cloud and it is very
great to learn with Swift.
Now I'm wondering is there some methods to make downloaded
file/folder in client automatically synchronize with Swift.

For example, I downloaded a file/folder in my computer from
Swift, after modify contents in this file/folder I want it
to synchronize with Swift (smt like Dropbox). Can you
suggest me some methods to do this ?

IMO, I think I need to set up rsync in my computer and
configure it to sync with swift ? But this seem to be
difficult .. Another solutions is finding a way to mount
folder from Swift in client. But it (again) seems to be
difficult, I can not find any documentation described it.

Please give me some solutions.

Thank you for your attention !



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp





--
..:: Lê Quang Hiếu ::..

Class: Information System - Course 52
School of Information and Communication Technology
Hanoi University of Technology
No 1, Dai Co Viet street - Hai Ba Trung district - Hanoi

Y!M: h2_...@yahoo.com mailto:h2_...@yahoo.com
Gmail: hieul...@gmail.com mailto:hieul...@gmail.com




--
..:: Lê Quang Hiếu ::..

Class: Information System - Course 52
School of Information and Communication Technology
Hanoi University of Technology
No 1, Dai Co Viet street - Hai Ba Trung district - Hanoi

Y!M: h2_...@yahoo.com mailto:h2_...@yahoo.com
Gmail: hieul...@gmail.com mailto:hieul...@gmail.com



___
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] Remove Zones code - FFE

[Tom Fifield]

Just raising another deployment waiting on this new Zone implementation 
- we currently have 2000 cores sitting idle in another datacentre that 
we can use better if this is done.


How can we help? ;)

Regards,

Tom

On 02/08/2012 07:30 PM, Ziad Sawalha wrote:

We were working on providing the necessary functionality in Keystone but
stopped when we heard of the alternative solution. We could resume the
conversation about what is needed on the Keystone side and implement if
needed.

Z

From: Sandy Walsh sandy.wa...@rackspace.com
mailto:sandy.wa...@rackspace.com
Date: Thu, 2 Feb 2012 01:49:58 +
To: Joshua McKenty jos...@pistoncloud.com
mailto:jos...@pistoncloud.com, Vishvananda Ishaya
vishvana...@gmail.com mailto:vishvana...@gmail.com
Cc: openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
Subject: Re: [Openstack] Remove Zones code - FFE

Understood, timing is everything. I'll let Chris talk about expected
timing for the replacement. From a deployers side, nothing would really
change, just some configuration options ... but a replacement should be
available.

I'm sure we could get it working pretty easily. The Keystone integration
was the biggest pita.

I can keep this branch fresh with trunk for when we're ready to pull the
trigger.

-S


*From:* Joshua McKenty [jos...@pistoncloud.com
mailto:jos...@pistoncloud.com]
*Sent:* Wednesday, February 01, 2012 4:45 PM
*To:* Vishvananda Ishaya
*Cc:* Sandy Walsh; openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
*Subject:* Re: [Openstack] Remove Zones code - FFE

+1 to Vish's points. I know there are some folks coming online in the
Folsom timeline that can help out with the new stuff, but this feels a
bit like going backwards.

--
Joshua McKenty, CEO
Piston Cloud Computing, Inc.
w: (650) 24-CLOUD
m: (650) 283-6846
http://www.pistoncloud.com

Oh, Westley, we'll never survive!
Nonsense. You're only saying that because no one ever has.

On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya wrote:


I am all for pulling this out, but I'm a bit concerned with the fact
that we have nothing to replace it with. There are some groups still
trying to use it. MercadoLibre is trying to use it for example. I know
you guys are trying to replace this with something better, but it
would be nice not to break people for 7+ months


So I guess I have some questions:
1.a) is the current implementation completely broken?

1.b) if yes, is it fixable

2) If we do remove this, what can we tell people that need something
like zones between now and the Folsom release?

Vish
On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote:


As part of the new (and optional) Zones code coming down the pipe,
part of this is to remove the old Zones implementation.

More info in the merge prop:
https://review.openstack.org/#change,3629

So, can I? can I? Huh?
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
mailto: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
mailto: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
mailto: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