I use a token ), tht last char is ), then when I logon dashboard
to instances or images or keypairs web. it occurs:
Unable to get instance list: 401 Unauthorized This server could not verify
that you are authorized to
access the document you requested. Either you supplied the wrong
Hi there,
As far as I understand, each Glance app uses its own configuration file.
However, it seems to me that it induces a couple of weird things.
Today, I started taking a look on images cache and prefetch stuff, and
bumping my head on the wall because something was not working.
Then I
I have just installed nova/glance/keystone/dashboard on one controller and
compute/network nodes.
Images and instances are stored in local disk. I know the instances are (base
image + Copy-On-Write) files.
Which file should I backup that are enough to restore a instance in another
disk?
If
I'm all for exposing only the major version in the URI (/v1). We have fallen
into a trap with v1.0 and v1.1 as they are not backckwards-compatible specs
while their versioning implies they are. I think we can have a whole separate
discussion on how to solve that problem, so like I said earlier,
Versioning should not be included in the URI. It belongs in the headers. A URI
should be a persistent reference to a resource. As such, versioning always
breaks that persistent reference.
-George
On Oct 11, 2011, at 1:40 PM, Brian Waldon wrote:
I'm all for exposing only the major version in
On Tue, Oct 11, 2011 at 1:11 AM, Mark Nottingham m...@mnot.net wrote:
+1 (sorry for the lag, been travelling).
I'd like to start two wiki pages; one collecting goals for the APIs, one for
collecting common patterns of use in the APIs (not rules, not even
guidelines).
Maybe split each one
Hello everyone,
Our first post-design-summit meeting will take place at 21:00 UTC this
Tuesday in #openstack-meeting on IRC. PTLs, if you can't make it, please
name a substitute on [2].
We'll discuss the final Essex release schedule, get early status on the
Essex themes and blueprints for all
I filed this as a bug. We'll need to fix it so special characters get encoded
correctly: https://bugs.launchpad.net/keystone/+bug/872287
Thanks,
Ziad
From: DeadSun mwjpi...@gmail.commailto:mwjpi...@gmail.com
Date: Tue, 11 Oct 2011 16:29:21 +0800
To:
Hi Brian,
I think the versioning rules below are fine, but there are some other
things to think about:
- As others raised, what version (if any) should be in the URIs?
We could put the full version number in the URIs so long as we
maintain support for the older, compatible versions i.e.
Hi,
We work at SERPRO (serpro.gov.br), a Brazilian government TI company and
also in the CISL (Brazilian federal government committee for open source
implementation). We are organizing an event on next 19 with a full day of
talks about free software and private clouds. We are seeking an Openstack
Just added slides for Orchestration and Advanced Scheduling to wiki.
(sparse etherpad URL's on title slides)
-Sandy
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf
I'm not sure I agree with that. A URI should be a persistent reference to a
resource within the context of a major version of an API. Between major
versions, the URI structure can change completely (for example /servers -
/instances), destroying your persistent reference.
Additionally, if we
2011/10/11 George Reese george.re...@enstratus.com:
Versioning should not be included in the URI. It belongs in the headers. A
URI should be a persistent reference to a resource. As such, versioning
always breaks that persistent reference.
I don't follow. If the version is included in the
Thanks for the feedback, Mark! Comments inline:
On Oct 11, 2011, at 9:51 AM, Mark McLoughlin wrote:
Hi Brian,
I think the versioning rules below are fine, but there are some other
things to think about:
- As others raised, what version (if any) should be in the URIs?
We could put
On Tue, 2011-10-11 at 16:11 +1100, Mark Nottingham wrote:
+1 (sorry for the lag, been travelling).
I'd like to start two wiki pages; one collecting goals for the APIs,
one for collecting common patterns of use in the APIs (not rules, not
even guidelines).
Yeah, it'd be awesome to have the
Hi Mark,
On Tue, 2011-10-11 at 16:17 +1100, Mark Nottingham wrote:
On 19/09/2011, at 4:03 PM, Mark McLoughlin wrote:
OTOH, POST to update the object's metadata doesn't make much sense. We
don't accept the entity enclosed in the request as a new subordinate.
PATCH[1] would probably have
On Tue, Oct 11, 2011 at 9:56 AM, Brian Waldon
brian.wal...@rackspace.com wrote:
I'm not sure I agree with that. A URI should be a persistent reference to a
resource within the context of a major version of an API. Between major
versions, the URI structure can change completely (for example
On Tue, 2011-10-11 at 16:40 +0200, Soren Hansen wrote:
2011/10/11 Mark McLoughlin mar...@redhat.com:
I think the versioning rules below are fine, but there are some other
things to think about:
- As others raised, what version (if any) should be in the URIs?
We could put the full
No, not at all.
The object is /servers/1234 regardless of the versioning of the API. It's an
object that exists independent of your API and its version. A URI should
represent a single, persistent reference to that object.
The version is really an attribute of the content type you are
Pretending we are talking about User resource for me, kiall for moment.
The v1 API might represent the kiall user resource as {name:kiall} while
the v2 API might represent the kiall user resource as {USERname:kiall}.
The kiall resource has not changed, only the API representation. Hence, a
Hello Alexandre
On Tue, 2011-10-11 at 08:42 -0300, Alexandre Haguiar wrote:
We work at SERPRO (serpro.gov.br), a Brazilian government TI company
and also in the CISL (Brazilian federal government committee for open
source implementation). We are organizing an event on next 19 with a
full day
It's wildly inappropriate to equate a thing with its representation.
On Oct 11, 2011, at 4:06 PM, Soren Hansen wrote:
I see what you're saying. I guess I'm just used to equating a thing
with its representation.
--
Soren Hansen| http://linux2go.dk/
Ubuntu Developer|
Yes, my proposed solution requires OpenStack implementations to support ALL
major versions of ALL APIs. That's absolutely critical for building a healthy
ecosystem.
See EC2 for someone doing it damn well. I've never had to write new code to
talk to them unless I want to take advantage of new
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have noticed another weird issue with dnsmasq which might be related
to the problem.
# tail -1 /etc/nova/nova.conf
- --dnsmasq_config_file=/etc/dnsmasq.conf
#killall dnsmasq
# /etc/init.d/openstack-nova-network restart
Stopping OpenStack Nova
Hi
We are planning to have regular meets/syncups for Donabe. Possible
timings include Wed 2pm PST (since 2pm seems to work for openstack
meets). Please unicast myself/Rick if you want to participate but this
time doesn't work for you ... and please suggest some alternatives. Will
do my best
hello folks,
a group of people interested in academia met in Boston during the
unconference. I was there to take notes and facilitate this community
run initiative. Here is what we agreed so far. I'm sharing it on the
list to gather more ideas.
/stef
OpenStack Academic Initiative
Mission:
That is one case that would require a major version change where a URI is still
valid. However, changes to the URI are still allowed across major versions.
That causes me to think content-types are not good enough to handle versioning.
On Oct 11, 2011, at 11:21 AM, Kiall Mac Innes wrote:
Ceci n'est pas un pipe. ;)
--
Lorin Hochstein, Computer Scientist
USC Information Sciences Institute
703.812.3710
http://www.east.isi.edu/~lorin
On Oct 11, 2011, at 11:28 AM, George Reese wrote:
It's wildly inappropriate to equate a thing with its representation.
On Oct 11, 2011, at 4:06
++ Like the idea..yes I think we should aim to include all OpenStack APIs --
whatever that means :-)
-jOrGe W.
On Oct 11, 2011, at 9:52 AM, Jay Pipes wrote:
On Tue, Oct 11, 2011 at 10:08 AM, Mark McLoughlin mar...@redhat.com wrote:
On Tue, 2011-10-11 at 16:11 +1100, Mark Nottingham wrote:
Putting the version in the URI is a variant resource just like adding
.xml or .json . If you want the ability to get to a specific
representation in a browser (as opposed to a custom client) you can't
rely on content negotiation because browsers hard code their accepts clause.
REST is media
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As Jorge was pointing out last week
(https://lists.launchpad.net/openstack/msg04596.html), the problem seems
to be iptables related. When I added these two rules, I was able to ping
google.com with 10.0.1.1 as the nameserver.
# iptables -I
George Reese wrote:
No, not at all.
The object is /servers/1234 regardless of the versioning of the API.
It's an object that exists
independent of your API and its version. A URI should represent a
single, persistent reference to that object.
The version is really an attribute of the
Hi Stefano,
This event is an iniciative from some friends from SERPRO and CISL to
present a day with talks about private clouds with open software.
*Event date:* 19/10/2011
*Program*
1 - Connectivity Architecture for Cloud Computing Environments - Herlon
Fernandes - 9:00 to 10:00 - São Paulo
2
On Oct 11, 2011, at 1:53 PM, Lorin Hochstein wrote:
Ceci n'est pas un pipe. ;)
Exactly!
-- Ed Leafe
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list:
I do not know from where that comes, but I would consider it a bug and
that there is no good reason in this context to be using MyISAM for any
purpose.
On 10/11/2011 01:55 PM, Nick Sokolov wrote:
Hi stackers!
I noticed, that tables in database use two database engines instead of
two, but
OK, I get it now :-)
http://en.wikipedia.org/wiki/The_Treachery_of_Images
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Oct 11, 2011, at 2:53 PM, Lorin Hochstein wrote:
Ceci
On 10/11/2011 02:15 PM, Vishvananda Ishaya wrote:
For some reason tables are getting created as default type. There is
a migration in the history to convert tables to InnoDB, but anything
created after that migration will go in as the default type. We can
add another migration to convert
++
On Tue, Oct 11, 2011 at 3:59 PM, Brian Waldon brian.wal...@rackspace.comwrote:
I would like to propose we remove our implementation of OSAPI v1.0 from
Nova for the following reasons:
1) Our implementation is incomplete, and there are no (visible) plans to
complete it. Shared IP Groups
+1
On Tue, Oct 11, 2011 at 6:01 PM, Trey Morris trey.mor...@rackspace.com wrote:
+1
On Tue, Oct 11, 2011 at 3:59 PM, Brian Waldon brian.wal...@rackspace.com
wrote:
I would like to propose we remove our implementation of OSAPI v1.0 from
Nova for the following reasons:
1) Our implementation
+1
On Tue, Oct 11, 2011 at 3:59 PM, Brian Waldon brian.wal...@rackspace.comwrote:
I would like to propose we remove our implementation of OSAPI v1.0 from
Nova for the following reasons:
1) Our implementation is incomplete, and there are no (visible) plans to
complete it. Shared IP Groups
++
On Tue, Oct 11, 2011 at 2:46 PM, Josh Kearney j...@jk0.org wrote:
++
On Tue, Oct 11, 2011 at 3:59 PM, Brian Waldon brian.wal...@rackspace.com
wrote:
I would like to propose we remove our implementation of OSAPI v1.0 from
Nova for the following reasons:
1) Our implementation is
On Oct 11, 2011, at 4:10 PM, Caitlin Bestler wrote:
George Reese wrote:
No, not at all.
The object is /servers/1234 regardless of the versioning of the API.
It's an object that exists
independent of your API and its version. A URI should represent a
single, persistent reference to that
HTTP methods are well defined and the system should behave in accordance with
those definitions. Otherwise, even saying the word REST is a joke.
On Oct 11, 2011, at 9:10 PM, Caitlin Bestler wrote:
George Reese wrote:
No, not at all.
The object is /servers/1234 regardless of the
-Original Message-
From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
[mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net]
On Behalf Of Stefano Maffulli
Sent: 11 October 2011 08:43
To: Alexandre Haguiar
Cc: openstack@lists.launchpad.net
Subject: Re:
Hi, I'd like to request merge reviews on the following. These have been
outstanding since September 24.
https://review.openstack.org/#change,642 (Soren has +1'd)
https://review.openstack.org/#change,643
These are related to the Open vSwitch rules applied in a Xen domain 0, for
multi-tenant
On Tue, 2011-10-11 at 16:59 -0400, Brian Waldon wrote:
I would like to propose we remove our implementation of OSAPI v1.0
from Nova for the following reasons:
[snip]
+1
--
Kevin L. Mitchell kevin.mitch...@rackspace.com
This email may include confidential information. If you received it in
+3
On Oct 11, 2011, at 1:59 PM, Brian Waldon brian.wal...@rackspace.com wrote:
I would like to propose we remove our implementation of OSAPI v1.0 from Nova
for the following reasons:
1) Our implementation is incomplete, and there are no (visible) plans to
complete it. Shared IP Groups
Hi All,
As it was discussed during the Design Summit, there was a desire to create a
Working Group for Nova Volume changes.
If you would like to participate, pls feel free to add yourself to:
https://launchpad.net/~openstack-volume
and/or its mailing list:
On 12/10/2011, at 1:00 AM, Mark McLoughlin wrote:
We're not attempting to enumerating all the valid ways that POST can be
used, we're trying to narrow down those possibilities to a set of
guidelines which describe the general style and idioms of OpenStack
APIs.
Understood. I've been
On 12/10/2011, at 12:51 AM, Mark McLoughlin wrote:
- Version numbers aren't necessarily the best way to advertise the
availability of features - if we made clients query for the
availability of the features they're using, you could version the
features independently.
For
It might help to talk about *what* might change, and what kinds of versioning
are available.
E.g.,
* Changing the methods supported by a resource, or their semantics (in the
case of POST)
* Changing the URI query parameters available to a resource
* Changing the range of formats that a
I've started a list of proposed goals here:
http://wiki.openstack.org/Governance/Proposed/APIGoals
Please pile on...
On 11/10/2011, at 11:53 PM, Jay Pipes wrote:
On Tue, Oct 11, 2011 at 1:11 AM, Mark Nottingham m...@mnot.net wrote:
+1 (sorry for the lag, been travelling).
I'd like to
I logon dashboard and when I click to images/instances web, error occurs on
terminal.
Traceback (most recent call last):
File /usr/lib/pymodules/python2.7/eventlet/greenpool.py, line 80, in
_spawn_n_impl
func(*args, **kwargs)
File /usr/lib/pymodules/python2.7/eventlet/wsgi.py, line 508, in
Hey Everyone,
We had a great design summit. Lots of new features were presented, along with
some great proposals for cleanup, stability, upgradability, etc. I'm
attempting to capture all of the proposed action items in one etherpad, with
links to specific blueprints. You can find the
On 10/11/2011 10:27 AM, George Reese wrote:
Yes, my proposed solution requires OpenStack implementations to support ALL
major versions of ALL APIs. That's absolutely critical for building a healthy
ecosystem.
That may be completely impossible if different versions require
incompatible
Hi!
Could someone answer for my question?
2011/10/7 Roman Sokolkov rsokol...@gmail.com
Hi! For my research I think Diablo doesn't support LVM block devices for
VMs, does it?
In /usr/share/nova/libvirt.xml.template only file supports for main disk
device. I am right?
#if
Anyone have any items to discuss? Looks like Mark Nottingham is taking some
steps to move the API guideline discussion forward which was something we were
going to touch base on after the conference. Anything else we should follow up
on?
I need to send out a summary of our in-person meeting,
Let's skip this week then unless anyone objects. I think we'll have a few
things to cover next week.
Jonathan.
On Oct 11, 2011, at 1:31 PM, Joshua McKenty wrote:
I'll need another week with the followup to our FITS discussions before I'm
ready to bring it back to the PPB. I have some
58 matches
Mail list logo
