Hi,
I'm trying to run InstanceGroup.get_hosts() on a havana installation
that uses postgres. When I run the code, I get the following error:
RemoteError: Remote error: ProgrammingError (ProgrammingError) operator
does not exist: timestamp without time zone ~ unknown
2014-03-14 09:58:57.193
On Fri, 14 Mar 2014 09:03:22 +0100
Chmouel Boudjnah wrote:
> fujita (the maint of swift3 in CC of this email) has commented that he's
> been working on it.
I think we should've not kicked it out. Maybe just re-fold it
back into Swift?
-- Pete
___
Op
On Fri, Mar 14, 2014 at 2:50 PM, Joe Gordon wrote:
> Hi All, so as some of you may have noticed the stable/havana jobs just
> broke.
>
python-keystoneclient patch https://review.openstack.org/#/c/77977/ Broke
stable
https://review.openstack.org/#/c/80726/ Reverts that change
>
> The stable/ha
+1 to the idea.
However, I think we should discuss whether the rescue interface is the
appropriate path. It's initial intention was to tie into Nova's rescue
interface, allowing a user whose instance is non-responsive to boot into a
recovery mode and access the data stored within their instance. I
> Just to answer this point, despite the review latency, please don't be
> tempted to think one big change will get in quicker than a series of
> little, easy to review, changes. All changes are not equal. A large
> change often scares me away to easier to review patches.
>
> Seems like, for Juno-
We have started looking at how the Neutron advanced services being defined
and developed right now can be used within the Neutron policy framework we
are building. Furthermore, we have been looking at a new model for the
policy framework as of the past couple of weeks. So, I have been trying to
se
Hi All, so as some of you may have noticed the stable/havana jobs just
broke.
The stable/havana jobs are missing a dependency on oathlib [1]. It looks
like like oauthlib is a keystoneclient dependency, but it wasn't in the
global-requirements for stable/havana [2], so it never got installed.
Curre
ah - forget it - it was stable/havana of course
https://review.openstack.org/#/c/75825/
On Friday, 14 March 2014, 20:29, Darragh O'Reilly
wrote:
I'm looking at errors in the dhcp-agent using logstash and I see openstack/nova
Jenkins jobs running today [1] that have an outdated
neutron/o
I think we need to split the scenarios and focus on the end user experience
with the cloud
a few come to my mind from the CERN experience (but this may not be all):
1. Accidental deletion of an object (including meta data)
2. Multi-level consistency (such as between Cell API and child ins
On Fri, Mar 14, 2014 at 12:48 PM, Duncan Thomas wrote:
> On 13 March 2014 21:13, Roman Podoliaka wrote:
> > Hi Steven,
> >
> > Code from openstack/common/ dir is 'synced' from oslo-incubator. The
> > 'sync' is effectively a copy of oslo-incubator subtree into a project
> > source tree. As syncs a
On Thu, Mar 13, 2014 at 6:44 PM, Joshua Harlow wrote:
> From: Doug Hellmann
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday, March 13, 2014 at 12:44 PM
> To: "OpenStack Development Mailing List (not for usage que
On 03/06/2014 04:00 PM, Sergey Lukjanov wrote:
Hi folks,
the third development milestone of Icehouse cycle is now available for Savanna.
Here is a list of new features and fixed bug:
https://launchpad.net/savanna/+milestone/icehouse-3
and here you can find tarballs to download it:
http://tar
On 2014-03-14 14:49, Solly Ross wrote:
It would also be great if there was a way to only sync one package.
There is. :-)
--nodeps will only sync the modules specified on the command line:
https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator
That said, it's not always safe to do
I'm looking at errors in the dhcp-agent using logstash and I see openstack/nova
Jenkins jobs running today [1] that have an outdated
neutron/openstack/common/lockutils.py. The message format used to be 1 line per
lock/unlock eg:
Got semaphore "dhcp-agent" for method "subnet_delete_end"...
But
On 2014-03-13 11:12, James Slagle wrote:
On Thu, Mar 13, 2014 at 2:51 AM, Robert Collins
wrote:
So we already have pretty high requirements - its basically a 16G
workstation as minimum.
Specifically to test the full story:
- a seed VM
- an undercloud VM (bm deploy infra)
- 1 overcloud contr
Here is a summary from yesterday's meeting:
** Flavors (topic lead: Eugene Nikanorov)
* Hide the provider implementation details from the user
- The admin API would still need to be able to configure the
provider artifacts
- Suggestion to leverage existing provider model for this
- Also sugg
+1
Especially googledocs that are "final" or implemented should be moved to an
OpenStack repository and pointed to in the design and/or developer documents.
It's easy to lose history, reference and/or context if the document(s) are hard
or impossible to find.
--Rocky
> -Original Message-
Hi,
I just read through some of the design docs that were linked to the DVR
blueprints - and realized we probably have a ton of Neutron developer
documentation and architecture stuff in Google docs.
Should we try and gather them all up and place links to them in
the Developer Documentation - or p
You're far from the only one who feels this way. It should be noted, however,
that it would appear that the Oslo team is
trying to graduate some more of the modules into separate libraries. I talked
to someone about the process, and they said
that the Oslo team is trying to graduate the "lowest
It would also be great if there was a way to only sync one package. When
adding a new library
to a project (e.g. openstack.common.report to Nova), one would want to only
sync the openstack.common.report
parts, and not the any changes from the rest of openstack.common. My process
has been
1. E
From: Brant Knudson
To: "OpenStack Development Mailing List (not for usage questions)"
,
Date: 03/14/2014 02:21 PM
Subject:Re: [openstack-dev] [Oslo] Improving oslo-incubator
update.py
On Fri, Mar 14, 2014 at 2:05 PM, Jay S Bryant wrote:
It would be great if we could get
Hi Nathan,
I agree that we should be using filters on LDAP search whenever possible.
I still believe it is a valid use case for a new 'roles' API to retrieve
users with role grants and I am not sure it is possible to do without
querying LDAP for one user at a time.
Anna Sortland
Cloud System
Hi,
Is it possible (in the latest upstream) to partition the same
integration bridge "br-int" into multiple isolated partitions (in terms of
lvids ranges, patch ports, etc.) between OVS mechanism driver and ODL
mechanism driver? And then how can we pass some details to Neutron API (as
in the
On Fri, Mar 14, 2014 at 2:05 PM, Jay S Bryant wrote:
>
> It would be great if we could get the process for this automated. In the
> mean time, those of us doing the syncs will just have to slog through the
> process.
>
> Jay
>
>
>
> ___
> OpenStack-dev
From: Duncan Thomas
To: "OpenStack Development Mailing List (not for usage questions)"
,
Date: 03/14/2014 11:56 AM
Subject:Re: [openstack-dev] Duplicate code for processing REST
APIs
On 13 March 2014 21:13, Roman Podoliaka wrote:
> Hi Steven,
>
> Code from openstack/common/
From: Duncan Thomas
To: "OpenStack Development Mailing List (not for usage questions)"
,
Date: 03/14/2014 11:49 AM
Subject:Re: [openstack-dev] [Oslo] Improving oslo-incubator
update.py
On 14 March 2014 16:10, Jay S Bryant wrote:
> --> Duncan, It is important to know what com
All,
As requested at the F2F we’ve created a design doc to cover changes to the
L3-Agent. We have already sent out the L2-Agent doc for review and now we are
providing the L3-Agent doc.Please provide your review comments. See below
for a link to the google doc page.
https://docs.google.c
Hi Yatin,
I'm glad you are thinking about the drawbacks of the zmq-receiver causes, I
want to give you a reason to keep the zmq-receiver and get your feedback.
The way I think about the zmq-receiver is a tiny little mini-broker that
exists separate from any other OpenStack service. As such, it's
i
Hi,
I noticed that the criteria proposed is still ambiguous during reviews.
Currently Horizon team deal with mini features as bugs in the
beginning of RC cycle,
and they usually include a few string changes from the nature of Horizon.
The project policy that we accept mini features as bugs needs t
Off topic but, I'd like to see a word doc written out with the history of the
cloud, that'd be pretty sweet.
Especially if its something like google docs where u can watch the changes
happen in realtime.
+2
From: Jay Pipes mailto:jaypi...@gmail.com>>
Reply-To: "OpenStack Development Mailing Li
Meeting minutes:
Minutes:
http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-03-13-14.00.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-03-13-14.00.txt
Log:
http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neu
+1 to what Jay says here. This hidden behavior moistly just causes problems
and allows hacking hidden ways to restore things.
-Mike
On Fri, Mar 14, 2014 at 9:55 AM, Jay Pipes wrote:
> On Fri, 2014-03-14 at 08:37 +0100, Radomir Dopieralski wrote:
> > Hello,
> >
> > I also think that this thread
So this is an interesting question.
Let me explain why I think exposing is_sync is actually relatively dangerous
and breaks the task oriented model (at least taskflows view of it).
First let me explain a little bit of what happens in taskflow to create and
execute things.
1. User X creates obj
Hi Simon,
Thank you! One of those bugs helped me focus on an area of the (nova)
code that I hadn't found my way to yet, and I was able to at least get
back the functionality I had with Havana (hybrid OVS+Ethernet-Bridge
model) by setting firewall_driver in nova.conf to
nova.virt.libvirt.firewall.I
Sure, I can try to help,
I started https://etherpad.openstack.org/p/taskflow-mistral so that we can all
work on this.
Although I'd rather not make architecture for mistral (cause that doesn't seem
like an appropriate thing to do, for me to tell mistral what to do with its
architecture), but I'
Hi all,
>>> Worth noting that there have been a few cases of projects patching OSLO
>>> bugs intheir own tree rather than fixing in OSLO then resyncing. If anybody
>>> has any tooling that can detect that, I'd love to see the results.
They shouldn't have done that :(
I totally agree, that 'syn
On 7 March 2014 08:17, Yuzhou (C) wrote:
> First, generally, in public or private cloud, the end users of VMs
> have no right to create new VMs directly.
> If someone want to create new VMs, he or she need to wait for approval
> process.
> Then, the administrator Of cloud create a new VM
On 14 March 2014 03:07, sxmatch wrote:
> So, if we delete volume really, just keep snapshot alive, is it possible?
> User don't want to use this volume at now, he can take a snapshot and then
> delete volume.
>
> If he want it again, can create volume from this snapshot.
>
> Any ideas?
This has
On 13 March 2014 21:13, Roman Podoliaka wrote:
> Hi Steven,
>
> Code from openstack/common/ dir is 'synced' from oslo-incubator. The
> 'sync' is effectively a copy of oslo-incubator subtree into a project
> source tree. As syncs are not done at the same time, the code of
> synced modules may indee
On 14 March 2014 16:10, Jay S Bryant wrote:
> --> Duncan, It is important to know what commits are being brought over to
> help provide a pointer to
> --> the possible cause of subsequent bugs that arise. I.E. if we sync up
> the DB, there is a commit for fixing
> --> db connection order and sudd
As we said on the Thursday meeting, I've filled a bug with the details
https://bugs.launchpad.net/neutron/+bug/1292598
Feel free to add / ask for any missing details.
Best,
Miguel Ángel.
On 03/13/2014 10:52 PM, Carl Baldwin wrote:
Right, the L3 agent does do this already. Agreed that the lim
From: Brant Knudson
To: "OpenStack Development Mailing List (not for usage questions)"
,
Date: 03/14/2014 10:26 AM
Subject:Re: [openstack-dev] [Oslo] Improving oslo-incubator
update.py
On Wed, Mar 12, 2014 at 11:03 AM, Duncan Thomas
wrote:
On 15 January 2014 18:53, Brant
On Fri, 2014-03-14 at 08:37 +0100, Radomir Dopieralski wrote:
> Hello,
>
> I also think that this thread is going in the wrong direction, but I
> don't think the direction Boris wants is the correct one either. Frankly
> I'm a little surprised that nobody mentioned another advantage that soft
> de
As a technical person, I would love to hear the major/significant/big
differences between Mistral and TaskFlow.
Last October I read this blog
http://www.mirantis.com/blog/announcing-mistral-task-flow-as-a-service/ ,
and also saw ML/IRC communications, but still could not quite figure out
the grand
Hello stackers!
Thanks everyone who took part in our meeting :)
Meeting minutes are:
Minutes:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-14-15.09.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-14-15.09.txt
Log:
http://eavesdrop
On Wed, Mar 12, 2014 at 11:03 AM, Duncan Thomas wrote:
> On 15 January 2014 18:53, Brant Knudson wrote:
>
> > At no point do I care what are the different commits that are being
> brought
> > in from oslo-incubator. If the commits are listed in the commit message
> then
> > I feel an obligation t
On 03/14/2014 09:11 PM, Julie Pichon wrote:
> On 14/03/14 11:31, Thomas Goirand wrote:
>> Hi,
>>
>> A few months ago, I raised the fact that Selenium *CANNOT* be a hard
>> test-requirements.txt build-dependency of Horizon, because it is
>> non-free (because of binaries like the browser plug-ins not
On Fri, 2014-03-14 at 08:44 +, Yuzhou (C) wrote:
> Hi stackers,
>
> Are there any plans about DNSaaS on the neutron roadmap?
>
> As far as I known, Designate provides DNSaaS services for
> OpenStack.
>
> Why DNSaaS is Independent service , not a network service like LBaas
> o
On 03/14/2014 07:14 AM, Jiří Stránský wrote:
On 14.3.2014 14:42, Steven Dake wrote:
On 03/14/2014 06:33 AM, Jiří Stránský wrote:
On 12.3.2014 17:03, Jiří Stránský wrote:
Thanks for all the replies everyone :)
I'm leaning towards going the way Robert suggested on the review [1] -
upload pre-c
Howdy!
Here's some follow-up on setting up devstack-vm-gate as a 3rd party.
On 13 March 2014 15:30, Luke Gorrie wrote:
> 1. I need to enable an ML2 mech driver. How can I do this? I have been
> trying to create a localrc with a "Q_ML2_PLUGIN_MECHANISM_DRIVERS=..."
> line, but it appears that th
On 14.3.2014 14:42, Steven Dake wrote:
On 03/14/2014 06:33 AM, Jiří Stránský wrote:
On 12.3.2014 17:03, Jiří Stránský wrote:
Thanks for all the replies everyone :)
I'm leaning towards going the way Robert suggested on the review [1] -
upload pre-created signing cert, signing key and CA cert t
On 03/14/2014 06:33 AM, Jiří Stránský wrote:
On 12.3.2014 17:03, Jiří Stránský wrote:
Thanks for all the replies everyone :)
I'm leaning towards going the way Robert suggested on the review [1] -
upload pre-created signing cert, signing key and CA cert to controller
nodes using Heat. This seem
On 12.3.2014 17:03, Jiří Stránský wrote:
Thanks for all the replies everyone :)
I'm leaning towards going the way Robert suggested on the review [1] -
upload pre-created signing cert, signing key and CA cert to controller
nodes using Heat. This seems like a much cleaner approach to
initializing
On 14/03/14 11:31, Thomas Goirand wrote:
> Hi,
>
> A few months ago, I raised the fact that Selenium *CANNOT* be a hard
> test-requirements.txt build-dependency of Horizon, because it is
> non-free (because of binaries like the browser plug-ins not being
> build-able from source). So it was remove
On 14 Mar 2014, at 05:00, Dmitri Zimine wrote:
> - Async actions: how do results of async action communicates back?
> My understanding it it assumes that the remote system will call back to
> mistral with action execution id, it's on the engine to call-back, and action
> needs to let the engin
Take a look at method get_pecan_config() in mistral/api/app.py. It’s where you
can pass any parameters into pecan app (see a dictionary ‘cfg_dict’
initialization). They can be then accessed via pecan.conf as described here:
http://pecan.readthedocs.org/en/latest/configuration.html#application-co
Russell, first of all thanks for your opinion and taking part in this
discussion.
> What we need to dig in to is *why* do you feel it needs to be global?
>
> I'm trying to understand what you're saying here ... do you mean that
> since we're trying to get to where there's a global scheduler, that
Am 14. März 2014 12:32:41 schrieb Thomas Goirand :
Hi,
A few months ago, I raised the fact that Selenium *CANNOT* be a hard
test-requirements.txt build-dependency of Horizon, because it is
non-free (because of binaries like the browser plug-ins not being
build-able from source). So it was re
On Wed, Mar 12, 2014 at 8:07 PM, Chris Jones wrote:
>
> Hey
>
> I wanted to throw out an idea that came to me while I was working on
> diagnosing some hardware issues in the Tripleo CD rack at the sprint last
> week.
>
> Specifically, if a particular node has been dropped from automatic
> schedul
Hi,
A few months ago, I raised the fact that Selenium *CANNOT* be a hard
test-requirements.txt build-dependency of Horizon, because it is
non-free (because of binaries like the browser plug-ins not being
build-able from source). So it was removed.
Now, on the new Icehouse beta 3, it's back again,
On 03/14/2014 04:49 AM, victor stinner wrote:
> Hi,
>
> I'm working for eNovance and we are working on porting OpenStack to Python 3.
> Status of the port:
>
> http://techs.enovance.com/6722/status-of-the-openstack-port-to-python-3-2
> https://wiki.openstack.org/wiki/Python3
>
> I understan
On Fri, Mar 14, 2014 at 11:01:36AM +0100, Simon Pasquier wrote:
> Hi,
>
> I've played a little with XenAPI + OVS. You might be interested by this
> bug report [1] that describes a related problem I've seen in this
> configuration. I'm not sure about Xen libvirt though. My assumption is
> that the
On 14/03/14 11:08, Alexei Kornienko wrote:
> On 03/14/2014 09:37 AM, Radomir Dopieralski wrote:
[snip]
>> OpenStack is a big, distributed system of multiple databases that
>> sometimes rely on each other and cross-reference their records. It's not
>> uncommon to have some long-running operation s
On 03/14/2014 09:37 AM, Radomir Dopieralski wrote:
Hello,
I also think that this thread is going in the wrong direction, but I
don't think the direction Boris wants is the correct one either. Frankly
I'm a little surprised that nobody mentioned another advantage that soft
delete gives us, the on
Hi,
I've played a little with XenAPI + OVS. You might be interested by this
bug report [1] that describes a related problem I've seen in this
configuration. I'm not sure about Xen libvirt though. My assumption is
that the future-proof solution for using Xen with OpenStack is the
XenAPI driver but
On Mon, Mar 10 2014, Eoghan Glynn wrote:
> I'd like to nominate Ildikó Váncsa and Nadya Privalova as ceilometer
> cores in recognition of their contributions([1], [2]) over the Icehouse
> cycle, and looking forward to their continued participation for Juno.
I've just added Nadya and Ildikó to the
Hi,
I'm working for eNovance and we are working on porting OpenStack to Python 3.
Status of the port:
http://techs.enovance.com/6722/status-of-the-openstack-port-to-python-3-2
https://wiki.openstack.org/wiki/Python3
I understand that it becomes late for Python 3 changes before Icehouse rele
Hi stackers,
Are there any plans about DNSaaS on the neutron roadmap?
As far as I known, Designate provides DNSaaS services for OpenStack.
Why DNSaaS is Independent service , not a network service like LBaas or VPNaaS?
Thanks,
Zhou Yu
__
On Thu, Mar 13, 2014 at 6:39 PM, Marco Fargetta
wrote:
> Hi Chmouel,
>
> using this approach should I need to have the same users in both keystone?
>
yes.
>
> Is there any way to map user A from cloud X to user B in cloud Y?
>
not without some changes to swsync (or other software), container sy
Joshua,
why wait? Why not just help Renat with his research on that integration and
bring your own vision to the table? Write some 1-page architecture
description on how Mistral can be built on top of TaskFlow and we discuss
pros and cons. In would be much more productive.
On Fri, Mar 14, 2014 a
On Thu, Mar 13, 2014 at 3:44 PM, Sean Dague wrote:
> In Juno I'd really be pro removing all the devstack references to git
> repos not on git.openstack.org, because these kinds of failures have
> real impact.
>
> Currently we have 4 repositories that fit this bill:
>
> SWIFT3_REPO=${SWIFT3_REPO:-
Thank you for the reply.
I understand notification driver should be set of essential drivers.
I would like to consider using stacktach.
Thanks
--hiroyuki
-Original Message-
From: Sandy Walsh [mailto:sandy.wa...@rackspace.com]
Sent: Thursday, March 13, 2014 2:28 AM
To: OpenStack Devel
Hello,
I also think that this thread is going in the wrong direction, but I
don't think the direction Boris wants is the correct one either. Frankly
I'm a little surprised that nobody mentioned another advantage that soft
delete gives us, the one that I think it was actually used for originally.
Thanks Renat,
I'll keep waiting, and hoping that we can figure this out for everyone's
benefit. Because in the end we are all much stronger working together and much
weaker when not.
Sent from my really tiny device...
On Mar 13, 2014, at 11:41 PM, "Renat Akhmerov"
mailto:rakhme...@mirantis.co
74 matches
Mail list logo