Re: [Openstack] [openstack-dev] [nova] Call for Help -- OpenStack API XML Support

[Christopher B Ferris]

Has anyone surveyed those subscribed to openstack-operators@lists.openstack.org
 list for usage? While imperfect, at least it would be asking the 
constituency that might be most affected. You might also consider asking
whether they would prefer JSON or XML, regardless of what they use today.I agree with George that weighing developer interest in writing some test cases is likely not the best measure of how widely the XML API is used in practice.One last slightly unrelated point. There was discussion and a PPB decision not to maintain 3rd party APIs in core. Why does the EC2 API remain? Cheers,Christopher FerrisIBM Distinguished Engineer, CTO Industry and Cloud StandardsMember, IBM Academy of TechnologyIBM Software Group, Standards Strategyemail: chris...@us.ibm.comTwitter: christo4ferrisphone: +1 508 234 2986-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -To: OpenStack Development Mailing Listopenstack-...@lists.openstack.orgFrom: Vishvananda Ishaya Sent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.netDate: 08/09/2012 07:05PMCc: "openstack@lists.launchpad.net \(openstack@lists.launchpad.net\)"openstack@lists.launchpad.netSubject: Re: [Openstack] [openstack-dev] [nova] Call for Help --OpenStack	API XML SupportOn Aug 9, 2012, at 3:32 PM, George Reese george.re...@imaginary.comwrote:Why aren't the integration tests both XML and JSON?The simple answer is that no one has taken the time to write them.Our devstack exercises use the python client bindings. Tempest hasjson clients but no xml clients[1]. I think this demonstrates thatthere just isn't a huge desire for xml. Users that I have chattedwith just seem to care that the api works and that they they havegood bindings.I am definitely willing to be proven wrong on this point, but I'msecretly hoping everyone agrees with me. It is a lot of work tomaintain three APIs (we are still maintaining EC2 as well) and keepthem all functioning well, so if people are happy without OpenStackXML I would be perfectly content to deprecate it.Vish[1]https://github.com/openstack/tempest/tree/master/tempest/services/nova/xml ___ 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] best practices for merging common into specific projects

[Christopher B Ferris]

+1Cheers,Christopher FerrisIBM Distinguished Engineer, CTO Industry and Cloud StandardsMember, IBM Academy of TechnologyIBM Software Group, Standards Strategyemail: chris...@us.ibm.comTwitter: christo4ferrisphone: +1 508 234 2986-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -To: Doug Hellmann doug.hellm...@dreamhost.comFrom: Eric Windisch Sent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.netDate: 08/02/2012 04:59PMCc: Thierry Carrez thie...@openstack.org, openstack@lists.launchpad.netSubject: Re: [Openstack] best practices for merging common into specific projectsOn Monday, July 23, 2012 at 12:04 PM, Doug Hellmann wrote:   Sorry if this rekindles old arguments, but could someone summarize the   reasons for an openstack-common "PTL" without voting rights? I would   have defaulted to giving them a vote *especially* because the code in   common is, well, common to all of the projects.  So far, the PPB considered openstack-common to be driven by "all PTLs",  so it didn't have a specific PTL.As far as future governance is concerned (technical committee of the  Foundation), openstack-common would technically be considered a  supporting library (rather than a core project) -- those can have leads,  but those do not get granted an automatic TC seat.   OK, I can see the distinction there. I think the project needs an official leader, even if we don't call them a PTL in the sense meant for other projects. And I would expect anyone willing to take on the PTL role for common to be qualified to run for one of the open positions on the new TC, if they wanted to participate there.The scope of common is expanding. I believe it is time to seriously consider a proper PTL. Preferably, before the PTL elections.The RPC code is there now. We're talking about putting the membership services there too, for the sake of RPC, and even the low-level SQLAlchemy/MySQL access code for the sake of membership services. A wrapper around pyopenssl is likely to land there too, for the sake of RPC. These are just some of the changes that have already landed, or are expected to land within Folsom.Common contains essential pieces to the success of OpenStack which are currently lacking (official) leadership. Everyone's problem is nobody's problem.Consider this my +1 on assigning a PTL for common.Regards,Eric Windisch___Mailing list: https://launchpad.net/~openstackPost to   : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore 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] Default reply to behavior for mailing list

[Christopher B Ferris]

Thierry Carrez wrote:[snip] As such IMHO we should leave it as it is.Especially since Launchpad-based MLs don't give us the option tochangethat behavior anyway :)LMAO! TouchéCheers,Christopher FerrisIBM Distinguished Engineer, CTO Industry and Cloud StandardsMember, IBM Academy of TechnologyIBM Software Group, Standards Strategyemail: chris...@us.ibm.comTwitter: christo4ferrisphone: +1 508 234 2986

___
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] legacy client removal and python-glanceclient

[Christopher B Ferris]

Gabriel Hurley wrote:As a rule of thumb, we need to start doing proper deprecation on allpublic interfaces, whether that's a CLI, client method signatures,APIs, etc. It's a little late for this on the old vs. new glanceclient/CLI (unless Brian feels the work can be reasonably done tomake them compatible) but it's something we need to be really mindfulof going forward.+1!Cheers,Christopher FerrisIBM Distinguished Engineer, CTO Industry and Cloud StandardsMember, IBM Academy of TechnologyIBM Software Group, Standards Strategyemail: chris...@us.ibm.comTwitter: christo4ferrisphone: +1 508 234 2986

___
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] [cinder] Nova-volume vs. Cinder in Folsom

[Christopher B Ferris]

Speaking of the User Committee as proposed in the draft governance docs, I
can
certainly see value in having the committee chair chosen by the board.
However, as
currently proposed, there is a convoluted process for appointing the
representatives
of the committee. Frankly, if you want to give a voice to the end users,
the user
committee should be open to all who use the technology and wish to
contribute their
voice.

My $0.02 USD

Chris

Sent from my iPad

On Jul 16, 2012, at 12:10 PM, Thierry Carrez thie...@openstack.org
wrote:

 David Kranz wrote:
  Going forward, and this may be controversial, I think these kinds of
  issues would be best addressed by following these measures:
 
  1. Require each blueprint that involves an API change or significant
  operational incompatibility to include a significant justification of
  why it is necessary, what the impact would be, and a plan for
  deprecation/migration. This justification should assume that the remedy
  will have to be applied to a large, running OpenStack system in its
  many possible variations, without having to shut down the system
 for some unknown amount of time.

 That would be useful. Strengthening a bit the feature proposal process
 definitely can't hurt.

  2. Require such blueprints to be approved by a technical committee that
  includes a significant representation of users/operators. The tradeoffs
can
  be difficult and need to be discussed.

 The Foundation bylaws propose that a User committee be set up. I hope
 that the User committee can be quickly set up, gets respected people on
 it and manages to be representative of all the users/operators of
 OpenStack. If done properly, such a committee can get very influential
 and its public recommendations cannot be easily ignored by the
 developer side (the technical committee).

  3. The technical committee should declare that the bar for incompatible
  changes is high, and getting higher.
 
  Some might argue that this is too much of a burden and takes authority
  away from PTLs, but I think the statement of stability to the
  community (and others) would more than compensate for that.

 Using the user committee setup, you don't really need to take
 authority away from the PTL. You increase the influence of the users
 on technical decisions. You just provide a clear and official mechanism
 to represent the interests of the users as a whole. Once you have
 that, if the PTL or technical committee decides to ignore it, it's a
 rather strong decision that better has to be well justified. Its better
 than having some arbitrary percentage of users in a single committee
 and then have most decisions won by the most largely represented party.

 If the user committee is an active and respected group, it provides nice
 checks and balances against developers living in developer bubbles. Most
 issues we have right now with deployer-friendliness are linked to the
 fact that the users don't have a clear or official voice.

 The trick is, of course, to manage to set up such a committee in a way
 that represents all the users and deployers. It will be all the more
 influential if it is seen as representing all the users, rather than
 just a loosely-tied pre-determined subset of large users.

 --
 Thierry Carrez (ttx)
 Release Manager, OpenStack

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

Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom

[Christopher B Ferris]

+1 to Vish's proposal

I'd go a step further and suggest  adopt this model for such changes going
forward.

Chris

Sent from my iPad

On Jul 12, 2012, at 5:40 PM, Vishvananda Ishaya vishvana...@gmail.com
wrote:

 On Jul 12, 2012, at 2:36 PM, David Mortman wrote:

  On Thu, Jul 12, 2012 at 3:38 PM, Vishvananda Ishaya
  vishvana...@gmail.com wrote:
 
  Two thoughts:
 
  1) I think this is the wrong forum to poll operators on their
  preferences in general
 
  2) We don't yet even have a fully laid out set of requirements and
  steps for how someone would convert or how hard it will be.
  Historically (with openstack and software in general), it is _always_
  harder to upgrade then we think it will be. I'm an optimist and I
  think it will be a disaster...


 Excellent points. Let me make the following proposal:

 1) Leave the code in nova-volume for now.
 2) Document and test a clear migration path to cinder.
 3) Take the working example upgrade to the operators list and ask them
for opinions.
 4) Decide based on their feedback whether it is acceptable to cut the
nova-volume code out for folsom.

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

Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom

[Christopher B Ferris]

This is exactly the sort of interaction we need between the two perspectives of 
the OpenStack community.

Thanks

Chris

Sent from my iPad

On Jul 12, 2012, at 11:20 PM, Joe Topjian joe.topj...@cybera.ca wrote:

 Hello,
 
 I'm not an OpenStack developer nor any type of developer. I am, however, 
 heavily involved with operations for a few production OpenStack environments. 
 I understand the debate going on and wanted to add an administrator's point 
 of view.
 
 For admins, OpenStack is not our job, but a tool we use in our job. It's 
 terribly frustrating when that tool drastically changes every six months. 
 
 I find Gabriel's reply interesting and sane. I think if it was agreed upon to 
 ensure N+1 compatibility, then OpenStack should adhere to that. 
 
 The change being discussed involves storage volumes. This is dead serious. If 
 the migration goes awry, there's potential for production data loss. If the 
 badly-migrated OpenStack environment is used to offer services for outside 
 customers, we've just lost data for those customers. It's one of the worst 
 scenarios for admins.
 
 If upgrading from one version of OpenStack to the next is too dangerous due 
 to the possibility of getting into situations such as described above, then 
 it needs to be clearly announced. There's a reason why major RHEL releases 
 are maintained in parallel for so long.
 
 With regard to Option 1, I understand the benefits of making this change. If 
 Option 1 was chosen, IMO, the best-case scenario would be if the extra work 
 involved with upgrading to Cinder/Folsom was just a schema migration and 
 everything else still worked as it did with Essex. 
 
 If this were to happen, though, I would spend /weeks/ testing and planning 
 the Folsom upgrade. I'd estimate that my production environments would make 
 it to Folsom 3 months after it was released. But then what major change am I 
 going to have to worry about in another 3 months?
 
 Thanks,
 Joe
 
 
 On Thu, Jul 12, 2012 at 2:48 PM, Gabriel Hurley gabriel.hur...@nebula.com 
 wrote:
 The stated and agreed-upon goal from Essex forward is to make the core 
 OpenStack projects N+1 compatible (e.g. Essex-Folsom, Folsom-Grizzly), and 
 to make the clients capable of talking to every API version forever.
 
  
 
 Anything standing in the way of that should be considered a release-blocking 
 bug, and should be filed against the appropriate projects. I for one intend 
 to see to that as best I can.
 
  
 
 That said, there *is* a grey area around “migration” steps like Nova Volume 
 - Cinder. If the migration path is clear, stable, well-documented, uses the 
 same schemas and same APIs… I’d say that *may* still fall into the category 
 of N+1 compatible. It sounds like that’s the idea here, but that we need to 
 thoroughly vet the practicality of that assertion. I don’t think we can 
 decide this without proof that the clean transition is 100% possible.
 
  
 
 Code isn’t the only thing of value; constructively and respectfully shaping 
 design decisions is great, testing and filing bugs is also fantastic. 
 Profanity and disrespect are not acceptable. Ever.
 
  
 
 All the best,
 
  
 
 -  Gabriel
 
  
 
 
 -- 
 Joe Topjian
 Systems Administrator
 Cybera Inc.
 
 www.cybera.ca
 
 Cybera is a not-for-profit organization that works to spur and support 
 innovation, for the economic benefit of Alberta, through the use of 
 cyberinfrastructure.
 
 ___
 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] [nova] [cinder] Nova-volume vs. Cinder in Folsom

[Christopher B Ferris]

Sent from my iPad

On Jul 13, 2012, at 12:41 AM, Blake Yeager blake.yea...@gmail.com
wrote:

 snip

 I am excited to see such passion from the community but we need to make
sure that passion is directed in a constructive manner.

+1

Chris___
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] [cinder] Nova-volume vs. Cinder in Folsom

[Christopher B Ferris]

This level of response is unnecessary. 

That said, the perspectives which influenced the decision seemed somewhat 
weighted to the development community. I could be wrong, but I did not see much 
input from the operations community as to the impact.

Clearly, going forward, we want to be more deliberate about changes that may 
have impact on operations and he broader ecosystem that bases its efforts on 
assumptions established at the start of a release cycle, rather than on changes 
introduced late in the cycle.

Cheers

Chris

Sent from my iPad

On Jul 12, 2012, at 2:24 PM, George Reese george.re...@enstratus.com wrote:

 Well, I think overall OpenStack has done an absolute shit job of 
 compatibility and I had hoped (and made a huge point of this at the OpenStack 
 conference) Diablo - Essex would be the end of this compatibility bullshit.
 
 But the attitudes in this thread and with respect to the whole Cinder 
 question in general suggest to me that this cavalier attitude towards forward 
 migration hasn't changed.
 
 So you can kiss my ass.
 
 -George
 
 On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote:
 
 We actually care a hell of a lot about compatibility. We also recognize 
 there are times when we have to sacrifice compatibility so we can move 
 forward at a reasonable pace.
 
 If you think we are handling anything the wrong way, we would love to hear 
 your suggestions. If you just want to make comments like this, I would 
 suggest you keep them to yourself.
 
 Have a great day!
 Brian Waldon
 
 On Jul 12, 2012, at 9:32 AM, George Reese wrote:
 
 This community just doesn't give a rat's ass about compatibility, does it?
 
 -George
 
 On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote:
 
 Hello Everyone,
 
 Now that the PPB has decided to promote Cinder to core for the Folsom
 release, we need to decide what happens to the existing Nova Volume
 code. As far as I can see it there are two basic strategies. I'm going
 to give an overview of each here:
 
 Option 1 -- Remove Nova Volume
 ==
 
 Process
 ---
 * Remove all nova-volume code from the nova project
 * Leave the existing nova-volume database upgrades and tables in
   place for Folsom to allow for migration
 * Provide a simple script in cinder to copy data from the nova
   database to the cinder database (The schema for the tables in
   cinder are equivalent to the current nova tables)
 * Work with package maintainers to provide a package based upgrade
   from nova-volume packages to cinder packages
 * Remove the db tables immediately after Folsom
 
 Disadvantages
 -
 * Forces deployments to go through the process of migrating to cinder
   if they want to use volumes in the Folsom release
 
 Option 2 -- Deprecate Nova Volume
 =
 
 Process
 ---
 * Mark the nova-volume code deprecated but leave it in the project
   for the folsom release
 * Provide a migration path at folsom
 * Backport bugfixes to nova-volume throughout the G-cycle
 * Provide a second migration path at G
 * Package maintainers can decide when to migrate to cinder
 
 Disadvantages
 -
 * Extra maintenance effort
 * More confusion about storage in openstack
 * More complicated upgrade paths need to be supported
 
 Personally I think Option 1 is a much more manageable strategy because
 the volume code doesn't get a whole lot of attention. I want to keep
 things simple and clean with one deployment strategy. My opinion is that
 if we choose option 2 we will be sacrificing significant feature
 development in G in order to continue to maintain nova-volume for another
 release.
 
 But we really need to know if this is going to cause major pain to existing
 deployments out there. If it causes a bad experience for deployers we
 need to take our medicine and go with option 2. Keep in mind that it
 shouldn't make any difference to end users whether cinder or nova-volume
 is being used. The current nova-client can use either one.
 
 Vish
 
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp
 
 --
 George Reese - Chief Technology Officer, enStratus
 e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReese
 p: +1.207.956.0217
 enStratus: Enterprise Cloud Management - @enStratus - 
 http://www.enstratus.com
 To schedule a meeting with me: http://tungle.me/GeorgeReese
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp
 
 
 --
 George Reese - Chief Technology Officer, enStratus
 e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: 
 +1.207.956.0217
 enStratus: Enterprise Cloud 

Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom

[Christopher B Ferris]

+1

Chris

Sent from my iPad

On Jul 11, 2012, at 3:02 PM, Sean Dague sda...@linux.vnet.ibm.com
wrote:

 Before we completely pile on option 1, can we get devstack changed to
 run this way? I think the amount of pain / ease that transition is for
 users and the OpenStack CI team will greatly inform this decision, and
 give us some good data points on how tough this is for people to convert.

   -Sean

 On 07/11/2012 12:22 PM, Mike Perez wrote:
  +1 for option 1
 
  --
  Mike Perez
  DreamHost.com
 
  On Wednesday, July 11, 2012 at 8:26 AM, Vishvananda Ishaya wrote:
 
  Option 1 -- Remove Nova Volume
  ==
 
 
  This body part will be downloaded on demand.
 


 --
 Sean Dague
 IBM Linux Technology Center
 email: sda...@linux.vnet.ibm.com
 alt-email: slda...@us.ibm.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] [nova] [cinder] Nova-volume vs. Cinder in Folsom

[Christopher B Ferris]

Just to be clear, I was +1 ing Sean's point that we should get sme
experience behind this before pulling the plug.

Chris

Sent from my iPad

On Jul 11, 2012, at 3:02 PM, Sean Dague sda...@linux.vnet.ibm.com
wrote:

 Before we completely pile on option 1, can we get devstack changed to
 run this way? I think the amount of pain / ease that transition is for
 users and the OpenStack CI team will greatly inform this decision, and
 give us some good data points on how tough this is for people to convert.

   -Sean

 On 07/11/2012 12:22 PM, Mike Perez wrote:
  +1 for option 1
 
  --
  Mike Perez
  DreamHost.com
 
  On Wednesday, July 11, 2012 at 8:26 AM, Vishvananda Ishaya wrote:
 
  Option 1 -- Remove Nova Volume
  ==
 
 
  This body part will be downloaded on demand.
 


 --
 Sean Dague
 IBM Linux Technology Center
 email: sda...@linux.vnet.ibm.com
 alt-email: slda...@us.ibm.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] Compressed image support ?

[Christopher B Ferris]

 John Postlethwait wrote:
... Also, you need to make sure you are linking DIRECTLY to the image
itself, as if it is a redirect or any other HTTP response besides the file,
Glance will still create an image out of it and it will seem to have worked.
Sometimes you can even launch said instances that are totally invalid. (During
my testing of this I was able to successfully launch instances that were just
the HTTP data from 302 redirects.)

Why would the Glance client treat an HTTP 302 redirect as a 2xx? That seems 
rather odd behavior, 
and less like a feature and more like a bug, to me, if true. From the looks of 
the code, a RedirectException
should be thrown. 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry and Cloud Standards
Member, IBM Academy of Technology
IBM Software Group, Standards Strategy
email: chris...@us.ibm.com
Twitter: christo4ferris
phone: +1 508 234 2986

-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -

To: Wang Li fox...@gmail.com
From: John Postlethwait 
Sent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.net
Date: 07/09/2012 03:38PM
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Compressed image support ?

 
 Hi Wang,

Horizon simply uses the Python interface to Glance and tells it to create the
image. Glance supports creating images from remote locations that are in a
compressed format. There are examples in the Glance documentation
here: https://github.com/openstack/glance/blob/master/doc/source/glance.rst#exa
mples-of-uploading-different-kinds-of-images and in the Glance binary itself
here: https://github.com/openstack/glance/blob/master/bin/glance#L190 So this
is widely supported and documented in Glance.

The caveats are that through Horizon, the file MUST be accessible via the
network configuration where Glance resides, if it is not accessible due to
network configuration or something else, it will fail but seem to have
succeeded. Also, you need to make sure you are linking DIRECTLY to the image
itself, as if it is a redirect or any other HTTP response besides the file,
Glance will still create an image out of it and it will seem to have worked.
Sometimes you can even launch said instances that are totally invalid. (During
my testing of this I was able to successfully launch instances that were just
the HTTP data from 302 redirects.)

I would first confirm that where Horizon is installed is able to communicate to
where you are trying to copy the image from, and that the link you are using
for the image is, in fact, a valid binary and not some other HTTP response.

John Postlethwait
Nebula, Inc.

   On Monday, July 9, 2012 at 1:04 AM, Wang Li
wrote:
  
 hi, all

As to the horizon UI,   zip and tar.gz image files are supported.


Specify an image to upload to the Image Service.

Currently only images available via an HTTP URL are supported. The
image location must be accessible to the Image Service. Compressed image
binaries are supported (.zip and .tar.gz.)



My test environment is as follow:

1. LVM as image backend of vms.
2. running vms on Xen in PV mode

But when I upload a tar gzipped raw image file, nova just dd from it to
logical volume, thus, nova error logged 

Boot loader didn't return any data!

I grepped the nova and glance source code, found nothing about of gz
or zip that related to image.

This feature is valuable to our use case, for the raw image file is
4GB, but the compressed version is only 400MB.

Did I misunderstand the compressed image support?


Regards.
Wang Li



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

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

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

Re: [Openstack] OpenStack G naming poll

[Christopher B Ferris]

-1

Gazelle seems to carry more of the characteristics we would want (nimble, 
quick). Grizzly carries rather grim connotations
 of mauling, lumbering, and having a rather nasty disposition. I would not want 
that in a cloud.

Also, as an adjective, grizzly means 'showing characteristics of age, 
especially having grey or white hair'.

While the name may sound cool, it is actually ill fitting.

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry and Cloud Standards
Member, IBM Academy of Technology
IBM Software Group, Standards Strategy
email: chris...@us.ibm.com
Twitter: christo4ferris
phone: +1 508 234 2986

-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -

To: Gabriel Hurley gabriel.hur...@nebula.com
From: Mark Collier 
Sent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.net
Date: 07/03/2012 09:46PM
Cc: openstack@lists.launchpad.net \(openstack@lists.launchpad.net\)
openstack@lists.launchpad.net, Thierry   Carrez thie...@openstack.org
Subject: Re: [Openstack] OpenStack G naming poll

 
+1 grizzly 
 
 On Jul 3, 2012, at 7:45 PM, Gabriel Hurley
gabriel.hur...@nebula.com wrote:
 
   
   
 +1 on #8220;close enough to an arbitrary territory and also a great 
 name#8221;.
;-)
  
 Also, the Grizzly is the California state animal:
 http://www.statesymbolsusa.org/California/animal_grizzly_bear.html
  
 Food for thought.
  
  -  Gabriel
  
 
 
 
 From:  openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
] On Behalf Of Brian Waldon
 Sent: Tuesday, July 03, 2012 4:50 PM
 To: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
 Cc: Thierry Carrez
 Subject: Re: [Openstack] OpenStack G naming poll
    
 
 TL;DR - Screw the rules, let's call the next release 'Grizzly'
  
  
  As California is rather lacking in the 'municipality names starting
with a G that we should use for an OpenStack release' department, I
have had to look *slightly* outside the ruleset to find a suitable 'G'
release name - that name being  'Grizzly'. The rules clearly state that
a release name must represent a city or county near the corresponding
design summit and be comprised of a single word of ten characters or
less - the problem here being that 'Grizzly' is actually 'Grizzly
Flats.' Having  already polled a small subset of the community, I feel
like there would be enough support for 'Grizzly' to win if it were on
the ballot. As I'm more interested in selecting a suitable name than
accurately representing some arbitrary territory, I'd love to  either
permanently amend the rules to make this acceptable or grant an
exception in this one case. As Thierry said, if this reaches critical
mass, we will figure out what to do. Otherwise, I'll shut up and deal
with 'Gazelle'.
 
 
 
 
  
  
 Brian
 
  
  
  
 
 
 On Jul 3, 2012, at 3:20 PM, Thierry Carrez wrote:
  
 
 
 
 Yes, it's that time of the year again... time for us to choose the
name
 of the next OpenStack release !
 
 This time, cities and counties in California (San Diego, CA being the
 location of the G design summit)
 
 I set up a poll with the available options (based on our current rules
 of naming) at:
 
 https://launchpad.net/~openstack/+poll/g-release-naming
 
 Poll is accessible to all members of ~openstack group in Launchpad,
and
 ends next Tuesday, 21:30 UTC. Please cast your vote!
 
 I'm aware that a subversive movement wants to try to amend the rules
so
 that another name option becomes available. Since we can't stop (or
 modify) the poll now that it's been launched, if that movement reaches
 critical mass, we may organize a second round of polling :)
 
 -- 
 Thierry Carrez (ttx)
 Release Manager, OpenStack
 
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp
    
   
___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp
 ___ 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] best practices for merging common into specific projects

[Christopher B Ferris]

-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -

To: openstack@lists.launchpad.net
From: Monty Taylor 

[snip]

So honestly, I'd say the real key is getting us closer to the point
where openstack-common is a proper library, because all of the rest of
the complexity is stuff we're inventing to make life harder on
ourselves, when the standard library with api-contract and a version
model of the world works pretty fine without needing coordinated changes
across multiple repositories.

+1

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry and Cloud Standards
Member, IBM Academy of Technology
IBM Software Group, Standards Strategy
email: chris...@us.ibm.com
Twitter: christo4ferris
phone: +1 508 234 2986


___
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] best practices for merging common into specific projects

[Christopher B Ferris]

-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -

To: andrewbog...@gmail.com andrewbog...@gmail.com, Andrew Bogott
abog...@wikimedia.org, openstack openstack@lists.launchpad.net
From: Joshua Harlow 
Sent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.net
Date: 07/02/2012 07:21PM
Subject: Re: [Openstack] best practices for merging common into
specific projects



Re: [Openstack] best practices for merging common into specific
projects


What about using openstack-common as a library instead of a
preprocessor #8216;inclusion#8217; system/copy code around system??



Maybe its time for that to happen? 



It always seemed sort of silly to me that files are being copied around
to different projects like this, instead of referring to code in a
common library package.

+1

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry and Cloud Standards
Member, IBM Academy of Technology
IBM Software Group, Standards Strategy
email: chris...@us.ibm.com
Twitter: christo4ferris
phone: +1 508 234 2986


___
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] Adding docs gating jobs?

[Christopher B Ferris]

+1

Chris

Sent from my iPad

On Jun 26, 2012, at 3:42 PM, Anne Gentle a...@openstack.org wrote:

 Sounds good to me. Mo working doc builds, mo betta.

 Anne Gentle
 Content Stacker
 a...@openstack.org

 On Tue, Jun 26, 2012 at 9:02 AM, Monty Taylor mord...@inaugust.com
wrote:
  Hey guys!
 
  We have all of the projects properly and consistently building and
  uploading sphinx docs from in tree. This is pretty exciting, because it
  means one more resource we can expect to work.
 
  So related to that, we were talking about putting in a gating job for
  each project to prevent changes from breaking the docs. I don't really
  expect these jobs to fail builds very often, as the jobs themselves are
  pretty stable - but obviously it's the kind of thing people might have
  an opinion on.
 
  Thoughts?
  Monty
 
  ___
  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] [metering] Cinder usage data retrieval

[Christopher B Ferris]

Probably not important on a privatecloud deployment, but certainly important in the public cloud space.Actually, I'd say it is equally important in a private cloud context as public. Just because the cloud is behind a firewall does not mean it does not need to be secured as carefully as if it were exposed to the internet.Cheers,Christopher FerrisIBM Distinguished Engineer, CTO Industry and Cloud StandardsMember, IBM Academy of TechnologyIBM Software Group, Standards Strategyemail: chris...@us.ibm.comTwitter: christo4ferrisphone: +1 508 234 2986-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -To: John Griffith john.griff...@solidfire.com, Nick Barcet	nick.bar...@canonical.comFrom: "Thomas, Duncan" Sent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.netDate: 06/21/2012 07:13AMCc: "openstack@lists.launchpad.net" openstack@lists.launchpad.netSubject: Re: [Openstack] [metering] Cinder usage data retrievalJohn Griffith on 20 June 2012 18:26 wrote: On Wed, Jun 20, 2012 at 10:53 AM, Nick Barcet nick.bar...@canonical.com wrote:  What we want is to retrieve the maximum amount of data, so we can meter  things, to bill them in the end. For now and for Cinder, this would  first include (per user/tenant):  - the amount of reserved volume space  - the amount of used volume space  - the number of volumes  but we'll need probably more in a near future. We should chat about how things are shaping up so far and how you're implementing things on the other sides (consistency where practical/possible). Also, it sort of depends on the architecture and use model details of Ceilometer, which I hate to admit but I'm not really up to speed on.  My first reaction/thought is the best most appropriate place to tie in is via the python-cinderclient. There would be a number of ways to obtain some of this info, whether deriving it or maybe some extensions to obtain things directly.One thing to watch for here is access control... Don't want one tenant able to find out about another's usage. Probably not important on a privatecloud deployment, but certainly important in the public cloud space. Havinga separate endpoint to do this kind of admin stuff over also means you canhave much tighter IP level access controls...-- Duncan ThomasHP Cloud Services, Galway___Mailing list: https://launchpad.net/~openstackPost to   : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore 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] WADL [was: v3 API draft (update and questions to the community)]

[Christopher B Ferris]

+1Over-reliance on WADL will only make it more challenging to gracefully evolve the APIs such that implementations can be forwards and/or backwards compatible, especially when exchanging XML based on an XSD that is not carefully crafted with proper extensibility points incorporated throughout the schema design, unless we were to adopt XSD1.1 which has an optional open content model (but which has not yet seen wide adoption, sadly).Cheers,Christopher FerrisIBM Distinguished Engineer, CTO Industry and Cloud StandardsMember, IBM Academy of TechnologyIBM Software Group, Standards Strategyemail: chris...@us.ibm.comTwitter: christo4ferrisphone: +1 508 234 2986-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -To: "Nguyen, Liem Manh" liem_m_ngu...@hp.comFrom: Mark Nottingham Sent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.netDate: 06/14/2012 08:34PMCc: "openstack@lists.launchpad.net" openstack@lists.launchpad.netSubject: [Openstack] WADL [was: v3 API draft (update and questions	to the	community)]Hi Liem,I'm one of the folks who helped Marc get WADL off of the ground. At the time, my use cases were exactly as you describe: documentation (e.g., https://github.com/mnot/wadl_stylesheets) and testing.Even back then, there was a lot of discussion in the community; e.g., see: http://bitworking.org/news/193/Do-we-need-WADL http://old.nabble.com/Is-it-a-good-idea-to-make-your-WADL-available--tc6087155r1.html http://www.25hoursaday.com/weblog/CommentView.aspx?guid=f88dc5a6-0aff-44ca-ba42-38c651612092I think many of the concerns that were expressed then are still valid -- some even within these limited uses. In no particular order:* People can and will use WADL to represent a "contract" to a service (really, an IDL), and "bake" client code to a snapshot of it in time. While it's true that the client and server need to have agreement about what goes on the wire and what it means, the assumptions around what guarantees WADL makes are not well-thought-out (in a manner similar to WSDL), making clients generated from it very tightly bound to the snapshot of the server they saw at some point in the past. This, in turn, makes evolution / extension of the API a lot harder than it needs to be.* WADL's primitives are XML Schema datatypes. This is a horrible match for dynamic languages like Python.* WADL itself embodies certain patterns of use that tend to show through if you design for it; these may or may not be the best patterns for a particular use case. This is because HTTP and URLs are very flexible things, and it isn't expressive enough to cover all of that space. As a result, you can end up with convoluted APIs that are designed to fit WADL, rather than do the task at hand.From what I've seen, many developers in OpenStack are profoundly uninterested in working with WADL. YMMV, but AFAICT this results in the WADL being done by other folks, and not matching the reality of the implementation; not a good situation for anyone.What we need, I think, is a specification of the API that's precise, unambiguous, and easy to understand and maintain. I personally don't think WADL is up to that task (at least as a primary artefact), so (as I mentioned), I'm going to be proposing another approach.Cheers,On 15/06/2012, at 2:08 AM, Nguyen, Liem Manh wrote: IMHO, a well-documented WADL + XSD would say a thousand words (maybe more)... And can serve as a basis for automated testing as well. I understand that the v3 API draft is perhaps not at that stage yet; but, would like to see a WADL + XSD set as soon as the concepts are solidified.  Liem  -Original Message- From: openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net [mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] On Behalf Of Mark Nottingham Sent: Tuesday, June 12, 2012 8:43 PM To: Gabriel Hurley Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [keystone] v3 API draft (update and questions to the community)   On 13/06/2012, at 1:24 PM, Gabriel Hurley wrote:  Totally agree with all of Jay's points, and I also couldn't agree more with Mark on the importance of being crystal clear, and not operating on just a "common understanding" which is quickly misunderstood or forgotten.  Ideally I'd like to see an OpenStack API feature contract of some sort... essentially a document describing the FULL list of features, how those parameters are controlled and how they would interact, and what a project should do if they do not implement an API feature (hopefully only for technical reasons such as Keystone paging with LDAP or swift with complex DB-esque operations). This isn't saying we should have a unified API spec, I'm talking solely about a contract for the features all APIs should strive to support.  This would be a big project, but everyone would then have a common agreement about what the user experience of interacting with OpenStack should be. The project APIs as they stand are siloed and stunningly 

Re: [Openstack] [keystone] v3 API draft (update and questions to the community)

[Christopher B Ferris]

+1 Ideally I'd like to see an OpenStack API feature contract of some sort... essentially a document describing the FULL  list of features, how those parameters are controlled and how they would interact, and what a project should do if they do not implement an API feature (hopefully only for technical reasons such as Keystone paging with LDAP or swift with complex DB-esque operations). This isn't saying we should have a unified API spec, I'm talking solely about a contract for the features all APIs should strive to support.We were discussing just that on the docs meeting earlier in the week. Whether it is a formal spec, or just documentation, is certainly open to debate. We may have need of both. This applies across all projects, IMO.Cheers,Christopher FerrisIBM Distinguished Engineer, CTO Industry and Cloud StandardsMember, IBM Academy of TechnologyIBM Software Group, Standards Strategyemail: chris...@us.ibm.comTwitter: christo4ferrisphone: +1 508 234 2986-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -To: "openstack@lists.launchpad.net" openstack@lists.launchpad.netFrom: Gabriel Hurley Sent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.netDate: 06/12/2012 11:28PMSubject: Re: [Openstack] [keystone] v3 API draft (update and questions	to	the community)Totally agree with all of Jay's points, and I also couldn't agree more with Mark on the importance of being crystal clear, and not operating on just a "common understanding" which is quickly misunderstood or forgotten.Ideally I'd like to see an OpenStack API feature contract of some sort... essentially a document describing the FULL list of features, how those parameters are controlled and how they would interact, and what a project should do if they do not implement an API feature (hopefully only for technical reasons such as Keystone paging with LDAP or swift with complex DB-esque operations). This isn't saying we should have a unified API spec, I'm talking solely about a contract for the features all APIs should strive to support.This would be a big project, but everyone would then have a common agreement about what the user experience of interacting with OpenStack should be. The project APIs as they stand are siloed and stunningly inconsistent, and I'd love to work toward fixing that.My two cents, - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Mark Nottingham Sent: Tuesday, June 12, 2012 7:20 PM To: Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [keystone] v3 API draft (update and questions to the community)   On 13/06/2012, at 3:31 AM, Jay Pipes wrote:   This isn't necessarily true. Nova's compute layer goes through a number of steps to ensure a semi-transactional nature to certain operations like resizing. Certain times a query needs to indicate that it intends to make a reservation of resources (see quota/reservation system now .. this is the SELECT FOR UPDATE paradigm) and other times, the query doesn't care about such things. In the latter case, there aren't expectations that the list returned is 100% accurate according to the state of the database at a particular timestamp of when the transaction occurred. In this case, filters and optimistic pagination works perfectly fine, IMHO.  That might work, but we need to be crystal-clear about the semantics of what we're giving back; having it understood between OpenStack projects isn't good enough.  I.e., we're not building the APIs just for Horizon; they're for lots of folks, and subtle semantics -- even when well-documented, much less when they're not -- are often misunderstood.  Cheers,  -- Mark Nottingham  http://www.mnot.net/ ___ 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/~openstackPost to   : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore 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] Comparing roles - case (in)sensitivity

[Christopher B Ferris]

case-insensitive - why would 'Admin' and 'admin' be different? Sure, a role is represented by a string, but why does that string need to be case sensitive?I'd think that if you had distinct roles attributed to 'Admin' and 'admin' that that would lead to confusion.Cheers,Christopher FerrisIBM Distinguished Engineer, CTO Industry and Cloud StandardsMember, IBM Academy of TechnologyIBM Software Group, Standards Strategyemail: chris...@us.ibm.comTwitter: christo4ferrisphone: +1 508 234 2986-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -To: Kiall Mac Innes ki...@managedit.ieFrom: Brian Waldon Sent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.netDate: 06/08/2012 07:21PMCc: "openstack@lists.launchpad.net \(openstack@lists.launchpad.net\)" openstack@lists.launchpad.netSubject: Re: [Openstack] Comparing roles - case (in)sensitivityI guess I'm looking at this from more of a purist development point of view: 'Admin' and 'admin' just can't be equal. If I think of this as comparing roles, where a role is an abstract concept, case-insensitivity makes more sense. A string is simply being used to represent the role, where the intent of the role is what really needs to be compared.My goal here is to get everybody on board with a single approach and apply it across all projects. I don't *really* care too much which approach we take.WaldonOn Jun 8, 2012, at 3:27 PM, Kiall Mac Innes wrote:Sure - The most obvious reason is human error leading to a security hole. E.g. Accidently assigning a user "Admin" when you really meant to assign "admin".Treating roles as case insensitive helps prevent this kind of human error.What advantages does allowing distinct "Admin" and "admin" roles provide?Thanks,
KiallSent from my phone.
On Jun 8, 2012 11:20 p.m., "Brian Waldon" brian.wal...@rackspace.com wrote:
Can you explain why?On Jun 8, 2012, at 3:18 PM, Kiall Mac Innes wrote:No, I'm suggesting they should all be treated as a single role. I.e. roles should be case insensitive.
Thanks,
KiallSent from my phone.
On Jun 8, 2012 11:16 p.m., "Brian Waldon" brian.wal...@rackspace.com wrote:

I'm suggesting we support only a single representation of a role across all projects: 'admin', 'Admin', and 'admIn' would be three separate roles.

Are you suggesting otherwise?On Jun 8, 2012, at 3:14 PM, Kiall Mac Innes wrote:What's the argument for allowing both, for example, "admin", "Admin" and "admIn" roles?This seems like one place where case insensitive makes the most sense.Thanks,
KiallSent from my phone.
On Jun 8, 2012 11:01 p.m., "Joseph Suh" j...@isi.edu wrote:


I'd vote case-sensitive.

Joseph


(w) 703-248-6160
(c) 571-340-2434
(f) 703-812-3712
3811 N. Fairfax Drive Suite 200
Arlington, VA, 22203, USA
http://www.east.isi.edu/~jsuh

- Original Message -
From: "Brian Waldon" brian.wal...@rackspace.com
To: "openstack@lists.launchpad.net (openstack@lists.launchpad.net)" openstack@lists.launchpad.netSent: Friday, June 8, 2012 5:50:45 PM
Subject: [Openstack] Comparing roles - case (in)sensitivitytl;dr - Should we compare roles as case-sensitive or case-insensitive? I vote case-sensitive.

This bug was recently filed in Glance: https://bugs.launchpad.net/glance/+bug/1010519 . It points out that Nova and Keystone are both case-insensitive when it comes to role comparison, yet Glance *is* case sensitive. I'm in favor of moving other projects to a case-sensitive approach for two main reasons:

1) If a role is a string, and comparing strings is inherently case-sensitive, then role comparison would logically be case-sensitive
2) I get to do less workThoughts?


Brian Waldon

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

___
Mailing list: https://launchpad.net/~openstack
Post to   : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help  : https://help.launchpad.net/ListHelp
___Mailing list: https://launchpad.net/~openstackPost to   : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore 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] search on the mailing list

[Christopher B Ferris]

Could we get these links added to the splash onhttps://launchpad.net/openstack? I'm sure this is a rather common problem.e.g.:Mailing list - openstack@lists.launchpad.net	-seehttps://launchpad.net/~openstackto join	- searchable archives:		http://www.mail-archive.com/openstack@lists.launchpad.net/  http://openstack.markmail.org/We might also consider adding to the FAQ.Cheers,Christopher FerrisIBM Distinguished Engineer, CTO Industry and Cloud StandardsMember, IBM Academy of TechnologyIBM Software Group, Standards Strategyemail: chris...@us.ibm.comTwitter: christo4ferrisphone: +1 508 234 2986-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -To: Massimo Canonico m...@di.unipmn.itFrom: Michael J Fork/Rochester/IBM@IBMUSSent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.netDate: 06/01/2012 06:47AMCc: openstack-bounces+mjfork=us.ibm@lists.launchpad.net, openstack@lists.launchpad.netSubject: Re: [Openstack] search on the mailing list
Searchable archives are available at 

http://www.mail-archive.com/openstack@lists.launchpad.net/

http://openstack.markmail.org/


Michael

-
Michael Fork
Cloud Architect, Emerging Solutions
IBM Systems  Technology Group

Massimo Canonico ---06/01/2012 04:50:25 AM---Hi, I'm having a problem deleting my running instance and I would like to

From:Massimo Canonico m...@di.unipmn.it
To:openstack@lists.launchpad.net, 
Date:06/01/2012 04:50 AM
Subject:[Openstack] search on the mailing list
Sent by:openstack-bounces+mjfork=us.ibm@lists.launchpad.netHi,
I'm having a problem deleting my running instance and I would like to 
search on the mailing list in order to figure out if someone had already 
had this problem (i'm quite sure).

So I went to https://lists.launchpad.net/openstack/with my credentials, 
but I did not find any "search" button.

Am I wrong?

M

___
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/~openstackPost to   : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore help  : https://help.launchpad.net/ListHelpinline: Image.1__=0ABBF083DFA932B88f9e8a93df938@us.ibm.com.gif___
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] search on the mailing list

[Christopher B Ferris]

Cool! ThanksCheers,Christopher FerrisIBM Distinguished Engineer, CTO Industry and Cloud StandardsMember, IBM Academy of TechnologyIBM Software Group, Standards Strategyemail: chris...@us.ibm.comTwitter: christo4ferrisphone: +1 508 234 2986-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -To: openstack@lists.launchpad.netFrom: Stefano Maffulli <stef...@openstack.org>Sent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.netDate: 06/01/2012 12:23PMSubject: Re: [Openstack] search on the mailing listOn 06/01/2012 04:21 AM, Christopher B Ferris wrote: Could we get these links added to the splash on https://launchpad.net/openstack?Good idea. Done.thanks,stef___Mailing list: https://launchpad.net/~openstackPost to   : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore 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] I18n issue for OpenStack

[Christopher B Ferris]

+1It is important that we distinguish between those who might contribute to the development of OpenStack, who often have advancedlanguage skills, as contrasted with those who might be asked to operate a cloud based on OpenStack. While it may be that the languageof open source development is English, it is not as likely that you'll findsomeone in IT operations at a company in a non-English language speakingcountry who has advanced (and in some cases, any) english language skills. For them, English language log messages might as well have beenwritten in Romulan.As a means of making this real, imagine trying to operate and debug OpenStack if all of the log messages were written in Simple Chinese.Who amongst us could do that, or would much less even attempt it? I rest my case.It is critically important that welocalize as much as possible, including log messages, install and operations manuals as wellas UI components for locales that we would like to see adopt OpenStack. Thorough globalization will be critical to broad adoption of OpenStack,especially in emerging geographies.Cheers,Christopher FerrisIBM Distinguished Engineer, CTO Industry and Cloud StandardsMember, IBM Academy of TechnologyIBM Software Group, Standards Strategyemail: chris...@us.ibm.comTwitter: christo4ferrisphone: +1 508 234 2986-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -To: openstack@lists.launchpad.netFrom: Sean Dague Sent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.netDate: 04/11/2012 03:01PMSubject: Re: [Openstack] I18n issue for OpenStackOn 04/11/2012 08:41 AM, Thierry Carrez wrote: Sheng Bo Hou wrote: After the research done by my colleage Edward Zhang and myself, we have found the following issues for openstack. We have already raised bug https://bugs.launchpad.net/nova/+bug/974810 https://bugs.launchpad.net/nova/+bug/974810 . [...] Thanks for your analysis. We plan to discuss how to fix and extend I18N at the summit. One question that was raised on the ML in February was whether internationalization was actually worth the effort for infrastructure software like OpenStack. I'll be the first to admit that there are other languages than English, but all our open development is based in English already (bugs, reviews, commit messages, mailing-lists, IRC...), so I don't think supporting more languages in the software itself will help growing our developer community.I would tend to disagree with that. People are more likely to invest their time in software if they'll be able to use it better in their locale. I think this is definitely even more true in places where English has less of a dominant presence. It may even bring people to the table solely interested in helping with translation. I've seen that happen elsewhere. On our users community, do operators of OpenStack need translated error messages ? Given that translations are often incomplete, is it worth it ? What do comparable infrastructure open source software projects provide ? The effort to provide them has proven non-trivial, I'd like to make sure it's time well spent.If we want to think about OpenStack as a basic building block like Apache, i18n is critical. Otherwise there are regions that won't adopt it solely because of a lack of i18n.Is there a metric on the completeness so far? Something automated that could be a jenkins coverage kind of test?	-Sean-- Sean DagueIBM Linux Technology Centeremail: slda...@us.ibm.comalt-email: sda...@linux.vnet.ibm.com___Mailing list: https://launchpad.net/~openstackPost to   : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore 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