Neat,
Didn't know that existed.
http://kentonv.github.io/capnproto/language.html does look pretty nice...
-Josh From: Robert Collins
To: OpenStack Development Mailing List (not for usage questions)
Sent: Wednesday, November 12, 2014 10:12 PM
Subject: Re: [openstack-dev] [all] Versioned
On Wed, Nov 12, 2014 at 08:35:18AM -0500, Monty Taylor wrote:
> Just for the record, I believe that we should chose the tools that make
> sense for making our software, as long as it's not physically impossible
> for them to be packaged. This means we should absolutely not use things
> that require
On Wed, Nov 12, 2014 at 08:31:08AM -0500, Monty Taylor wrote:
> > jshint is NOT free software.
> >
> > https://github.com/jshint/jshint/blob/master/src/jshint.js#L19
>
> Reasonable people disagree on this point. I, for one, am one of them. In
> my opnion:
>
> A usage clause in a license header i
Hi, all.
I hit an error about ovs agents state report after deployed openstack by chef.
I check the code in agents_db. Found there are some greenthread.sleep(0) in
_create_or_update_agent (
https://github.com/openstack/neutron/commit/21bf6f7e4945bc7e8c303273ad10c28b6cfc8b08
). I'm not sure why
Hi,
> I'm wondering why you are just hitting it now? Does your CI pull the
> latest python-keystoneclient and python-openstackclient from master?
Yes before it began to fail, but now it is No because of this change:
https://github.com/openstack-dev/devstack/commit/8f8e2d1fbfa4c51f6b68a6967e330cd
I cant attend it if it moves to the week of Dec 15th. I have already booked a
trip for that week and even other commitments.
Is there any chance to push it back to Dec 8th?
Thanks,
Edgar
> On Nov 13, 2014, at 2:18 AM, Kyle Mestery wrote:
>
>> On Tue, Nov 11, 2014 at 7:04 AM, Kyle Mestery w
On 11 November 2014 13:30, Angus Salkeld wrote:
> Hi all
>
> I just wanted to make sure we are all under the same understanding of the
> outcomes and what the next steps for the versioned objects session are.
>
> 1. There is a lot of interest in other projects using oslo versioned objects
> and it
About a month ago, we made changes to python-openstackclient that seem
related to the error message you posted. Change is
https://review.openstack.org/#/c/127655/3/setup.cfg
I'm wondering why you are just hitting it now? Does your CI pull the
latest python-keystoneclient and python-openstackclie
> Hi,
>
> My third party CI becomes failed from about 21:00 12th UTC
> in execution of devstack.
>
> The error occurs at "openstack project create admin -f value -c id"
> ---
> ERROR: openstack The plugin token_endpoint could not be found
> ---
does your CI clean $DEST for each runs?
i guess you
OK, as promised I created a Wiki page to keep track of our work items. It’s
linked to from the Gantt meeting page and is also available here:
https://wiki.openstack.org/wiki/Gantt/kilo
The important column in the Tasks table is the Patches column, that shows the
specific patch
On Sat, Nov 1, 2014 at 6:45 AM, Everett Toews
wrote:
> Hi All,
>
> Chris Yeoh started the use of an APIImpact flag in commit messages for
> specs in Nova. It adds a requirement for an APIImpact flag in the commit
> message for a proposed spec if it proposes changes to the REST API. This
> will ma
Hi,
My third party CI becomes failed from about 21:00 12th UTC
in execution of devstack.
The error occurs at "openstack project create admin -f value -c id"
---
ERROR: openstack The plugin token_endpoint could not be found
---
I found some CIs have same problem.
Does anyone give me a hint to so
Gabriel has responded saying very much what I would have said, so I won't
repeat that. I would like to note though that bower and npm are two
separate beasts entirely. The dependency trees in bower are very limited
indeed (only two additional components are installed beyond the list below)
which is
Reminder that the L3 subteam meeting will be tomorrow at 1500 UTC.
Remember that daylight savings time may have ended since the last
meeting and the meeting will come an hour earlier.
I'd like to talk about the subjects discussed at the summit.
Specifically, we had design sessions about paying dow
On Thu, Nov 13, 2014 at 12:09:18PM +0900,
Isaku Yamahata wrote:
> Hello. As we discussed at the summit and following irc meeting,
> the time slot/channel is changed from Nov 19, 2014.
>
> - Weekly 17:00AM UTC(Wednesday) 30min
Oops.
- Weekly 17:00 UTC(Wednesday) 30min
(time is correct. AM is wro
> Hello. As we discussed at the summit and following irc meeting,
> the time slot/channel is changed from Nov 19, 2014.
>
> - Weekly 17:00AM UTC(Wednesday) 30min
17:00AM ???
> - IRC channel: #openstack-meeting-4
> - Next: Nov 19, 2014
>
> see https://wiki.openstack.org/wiki/Meetings/ServiceVM f
Hello. As we discussed at the summit and following irc meeting,
the time slot/channel is changed from Nov 19, 2014.
- Weekly 17:00AM UTC(Wednesday) 30min
- IRC channel: #openstack-meeting-4
- Next: Nov 19, 2014
see https://wiki.openstack.org/wiki/Meetings/ServiceVM for details
and Kilo planning.
Armando, Carl:
During the Summit, Armando and I had a very quick conversation concern a
blue print that I submitted,
https://blueprints.launchpad.net/neutron/+spec/dhcp-cpnr-integration and
Armando had mention the possibility of getting together a sub-group tasked
with DHCP Neutron concerns. I have
Two things of note, having been doing heavy javascript development over the
past couple years:
1) NPM actually resolves conflicts in a dependency tree. Unlike Python, it can
ensure that if different packages declare conflicting versions, each one gets
the version it requested. And conflicting d
> I’m not sure if I’m seeing the second SELECT here either but I’m less
> familiar with what I’m looking at. compute_node_update() does the
> one SELECT as we said, then it doesn’t look like
> self._from_db_object() would emit any further SQL specific to that
> row.
I don't think you're missin
> On Nov 12, 2014, at 8:29 PM, Thomas Goirand wrote:
>
> On 11/12/2014 09:31 PM, Monty Taylor wrote:
>>> jshint is NOT free software.
https://github.com/jshint/jshint/blob/master/src/jshint.js#L19
>> Reasonable people disagree on this point.
>
> Feel free to have this debate with the
On 11/12/2014 11:12 PM, Jiri Tomasek wrote:
> As Monty Taylor said, nodejs itself is not a blocker as multiple
> versions of it should not be needed by our tools. (That's also what npm
> and bower are taking care of, right?) Only thing that is required is
> that all tools/js libs we want to use wou
Hello Doug et all,
I would like to get the ball rolling on graduating oslo-incubator/reports into
oslo.reports. What do I have to do on my end to move forward with the
graduation
process?
Best Regards,
Solly Ross
___
OpenStack-dev mailing list
OpenSta
On Tue, Nov 11, 2014 at 7:04 AM, Kyle Mestery wrote:
> Hi folks:
>
> Apologies for the delay in announcing the Neutron mid-cycle, but I was
> confirming the details up until last night. I've captured the details
> on an etherpad here [1]. The dates are December 8-10
> (Monday-Wednesday), and it wi
On 13 November 2014 09:35, Adam Young wrote:
> On 11/12/2014 03:03 AM, Matthias Runge wrote:
>
>> On 12/11/14 08:40, Richard Jones wrote:
>>
>> I believe the nodeenv method of installing node solves this, as it's
>>> entirely local to the development environment.
>>>
>> See below, this touches p
Hi Chuck,
I should probably chime in since I made the initial comment in the
first place. I hate to derail the progress you've made with the
blueprint you have up now but this is worth some discussion.
On Wed, Nov 12, 2014 at 3:38 PM, Chuck Carlino wrote:
> It has been proposed that both issues
> On Nov 12, 2014, at 6:23 PM, Mike Bayer wrote:
>
>
> If I may inquire as to the irrelevant complexity, I’m trying to pinpoint
> where you see this happening.
>
> When we talk about updating a ComputeNode, because I’m only slightly familiar
> with Nova’s codebase, I assume we are looking at
> On Nov 12, 2014, at 10:56 AM, Matthew Booth wrote:
>
> For brevity, I have conflated what happens in object.save() with what
> happens in db.api. Where the code lives isn't relevant here: I'm only
> looking at what happens.
>
> Specifically, the following objects refresh themselves on save:
>
Hi,
In an attempt to expedite the merging of changes with positive feedback
that need minor changes (rebases, typo fixes, etc.) before merging, the
TripleO projects are going to adopt a slightly modified review standard
where such changes can be merged without 2 +2's on the latest patch set
if the
> I am proposing Wednesday as the meeting day since it's more open than
> Tues/Thurs so finding a meeting room at almost any time should be
> feasible. My opening bid is alternating between 1700 and 2200 UTC.
> That should provide options that aren't too early or too late for most
> people. Is t
Hi, Tomasz,
Gee, that sentence seemed just fine until I saw how foss geek interpreted
it ;-)
So I reworded that sentence, then I added a second sentence to try to
capture
what you wrote.
I'm not sure about that second sentence -- what do you think? I don't want
to
write a manual about how to depl
Hi,
I'm working on the neutron side of a couple of ironic issues, and I need
some help. Here are the issues.
1. If a nic on an ironic server fails and is replaced by a nic with a
different mac address, neutron's dhcp service will not serve it the
same ip address. This can be worked aro
Here’s the agenda [1] for our upcoming meeting.
Everett
[1] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 11/12/2014 03:03 AM, Matthias Runge wrote:
On 12/11/14 08:40, Richard Jones wrote:
I believe the nodeenv method of installing node solves this, as it's
entirely local to the development environment.
See below, this touches package build as well.
I will have to go through all dependen
Each summit since we created "preserve ephemeral" mode in Nova, I have
some conversations where at least one person's brain breaks for a
second. There isn't always alcohol involved before, there almost
certainly is always a drink needed after. The very term is vexing, and I
think we have done ourse
On 11/12/2014 06:21 AM, Darren Kenny wrote:
Chris Dent wrote:
On Tue, 11 Nov 2014, Adam Young wrote:
My suggestion, from a while ago, was to have a naming scheme that
deconflicts putting all of the services onto a single server, on
port 443.
+1
The current state of affairs is indeed weird.
On Nov 12, 2014, at 4:40 PM, Adam Young wrote:
> On 11/12/2014 02:06 PM, Doug Hellmann wrote:
>> During our “Graduation Schedule” summit session we worked through the list
>> of modules remaining the in the incubator. Our notes are in the etherpad
>> [1], but as part of the "Write it Down” the
Just for reference, the spec is this one:
https://review.openstack.org/#/c/133828/
That's a good point, I think it's important to have this distinction
of a new node being discovered and a registered node being
introspected/interrogated. So I'm +1 for the idea.
On Wed, Nov 12, 2014 at 9:47 PM, Vi
Hmmm... with this thread in mind, anyone think that changing DISCOVERING to
INTROSPECTING in the new state machine spec is a good idea?
On Mon, Nov 3, 2014 at 4:29 AM, Ganapathy, Sandhya wrote:
> Hi all,
>
> Following the mail thread on disambiguating the term 'discovery' -
>
> In the lines of w
On 11/12/2014 02:06 PM, Doug Hellmann wrote:
During our “Graduation Schedule” summit session we worked through the list of
modules remaining the in the incubator. Our notes are in the etherpad [1], but as
part of the "Write it Down” theme for Oslo this cycle I am also posting a
summary of the
Thanks Sean and Amrith - for getting the patches lined up to unblock the
gate and
keep things moving.
I missed the action (just got off a plane). I'll follow up on IRC to get
the tests up and
running on python-troveclient, and on the next steps to rework the patch.
Thanks,
Nikhil
On Wed, Nov 12
On Nov 12, 2014, at 4:16 PM, Doug Hellmann wrote:
>
> On Nov 12, 2014, at 2:06 PM, Doug Hellmann wrote:
>
>> During our “Graduation Schedule” summit session we worked through the list
>> of modules remaining the in the incubator. Our notes are in the etherpad
>> [1], but as part of the "Wri
On Nov 12, 2014, at 2:06 PM, Doug Hellmann wrote:
> During our “Graduation Schedule” summit session we worked through the list of
> modules remaining the in the incubator. Our notes are in the etherpad [1],
> but as part of the "Write it Down” theme for Oslo this cycle I am also
> posting a s
Hi all
Dougwig set up an etherpad for RSVP/general info @
https://etherpad.openstack.org/p/octavia-kilo-meetup
Dates – 15-19 Dec, HP Seattle – 701 Pike St, Suite 900, Seattle WA 98101
More details in the etherpad.
See you all soon
Thx
Alex
From: Stephen Balukoff [mailto:sbaluk...@bluebox.n
To clarify - I created the doodle in UTC (so the times in there are UTC
00:00 Monday to 23:59 Friday) but they will be shifted to your local
timezone - scroll all the way to the right to double-check that it's set
correctly for you.
Sorry for the confusion.
Richard
On 12 November 2014 12:4
On 11/12/2014 02:11 PM, Steve Gordon wrote:
> NUMA
>
>
> We still need to identify some hardware to run third party CI for the
> NUMA-related work, and no doubt other things that will come up. It's
> expected that this will be an interim solution until OPNFV resources
> can be used (note cdub
> On Nov 12, 2014, at 3:32 PM, Doug Hellmann wrote:
>
> We rather quickly came to consensus at the summit that we should drop the use
> of namespace packages in Oslo libraries [1]. As far as I could tell, everyone
> was happy with my proposed approach [2] of moving the code from oslo.foo to
>
On Nov 12, 2014, at 3:29 PM, Andreas Jaeger wrote:
> On 11/12/2014 08:06 PM, Doug Hellmann wrote:
>> During our “Graduation Schedule” summit session we worked through the list
>> of modules remaining the in the incubator. Our notes are in the etherpad
>> [1], but as part of the "Write it Down”
We rather quickly came to consensus at the summit that we should drop the use
of namespace packages in Oslo libraries [1]. As far as I could tell, everyone
was happy with my proposed approach [2] of moving the code from oslo.foo to
oslo_foo and then creating a backwards-compatibility shim in osl
On 11/12/2014 08:06 PM, Doug Hellmann wrote:
> During our “Graduation Schedule” summit session we worked through the list of
> modules remaining the in the incubator. Our notes are in the etherpad [1],
> but as part of the "Write it Down” theme for Oslo this cycle I am also
> posting a summary o
The oslo.messaging session at the summit [1] resulted in some plans to evolve
how oslo.messaging works, but probably not during this cycle.
First, we talked about what to do about the various drivers like ZeroMQ and the
new AMQP 1.0 driver. We decided that rather than moving those out of the mai
The outcome of the “Should Oslo continue to use alpha versions” session at the
summit [1] was unclear, so I would like to continue the discussion here.
As we discussed at the summit, the primary reason for marking Oslo library
releases as alphas was to indicate that the library is under developm
> On Nov 12, 2014, at 12:45 PM, Dan Smith wrote:
>
>> I personally favour having consistent behaviour across the board. How
>> about updating them all to auto-refresh by default for consistency,
>> but adding an additional option to save() to disable it for particular
>> calls?
>
> I think thes
On Nov 12, 2014, at 1:30 PM, David Kranz wrote:
> Code has started going into tempest for several projects
> (nova,neutron,keystone) to allow removal of xml support in kilo. There have
> been many (heated) off and on threads on this list over the years. I'm sure
> many projects would like to
+1!
2014-11-12 9:31 GMT-03:00 Flavio Percoco :
> Greetings,
>
> Zaqar team will pick up its regular meetings next Monday at 15 UTC.
> We'll keep alternating time, therefore the meeting after the next one
> will be at 21 UTC.
>
> The team meets in the #openstack-meeting-3 channel and we keep the
>
Hi all,
We had some discussions last week - particularly in the Nova NFV design session
[1] - on the subject of ensuring that telecommunications and NFV-related
functionality has adequate continuous integration testing. In particular the
focus here is on functionality that can't easily be teste
During our “Graduation Schedule” summit session we worked through the list of
modules remaining the in the incubator. Our notes are in the etherpad [1], but
as part of the "Write it Down” theme for Oslo this cycle I am also posting a
summary of the outcome here on the mailing list for wider dist
Code has started going into tempest for several projects
(nova,neutron,keystone) to allow removal of xml support in kilo. There
have been many (heated) off and on threads on this list over the years.
I'm sure many projects would like to do this, but there is evidence that
not all have an unders
Hi,
As for the Devstack it requires some rebasing work (not necessarily
straightforward) in order to push the changes upstream. As for the neutron,
it should not be difficult to port FreeBSD networking support (we have some
code in our forked repos) from nova-network to neutron plugin.
Regards,
M
Excerpts from Zane Bitter's message of 2014-11-12 08:42:44 -0800:
> On 12/11/14 10:10, Clint Byrum wrote:
> > Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:
> >> On 11/11/14 13:34, Ryan Brown wrote:
> >>> I am strongly against allowing arbitrary Javascript functions for
> >>> com
On Nov 12, 2014, at 10:42 AM, Zane Bitter
wrote:
> On 12/11/14 10:10, Clint Byrum wrote:
>> Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:
>>> On 11/11/14 13:34, Ryan Brown wrote:
I am strongly against allowing arbitrary Javascript functions for
complexity reasons. I
> I personally favour having consistent behaviour across the board. How
> about updating them all to auto-refresh by default for consistency,
> but adding an additional option to save() to disable it for particular
> calls?
I think these should be two patches: one to make them all auto-refresh,
an
Hi James,
This is awesome. I seem to have misplaced my 540-node cluster. ;-)
Is it possible for you to also patch in
https://review.openstack.org/#/c/132372/ ? In my rally testing of port
retrieval, this one probably made the most significant improvement.
On Nov 12, 2014 9:26 AM, "James Page"
On 11/12/2014 05:18 PM, Julie Pichon wrote:
On 12/11/14 15:12, Jiri Tomasek wrote:
Approach on using Xstatic packages vs Js tooling:
As only problem with using js tooling should be just actual packaging of
it, I think it makes sense to use these tools and make development
simpler then going oth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Ihar
On 11/11/14 19:39, Ihar Hrachyshka wrote:
>> there is a series of Neutron backports in the Juno queue that are
>>
>>> intended to significantly improve service performance when
>>> handling security groups (one of the issues that are main p
neophy,
This is a requirement of the fuel deployment with vCenter selected as
the compute hyper-visor. In this case the nova-compute service would
be configured on the controller nodes and the fuel ui would not allow
you to deploy kvm computes.
You can post configure additional services on the no
On 12 Nov 2014, at 17:56, foss geek wrote:
>
> I am reading Fuel reference-architecture documentation in the below link:
>
> http://docs.mirantis.com/openstack/fuel/fuel-5.1/reference-architecture.html#openstack-environment-architecture
>
> In the page no 2 note says:
>
> Note
>
> In enviro
I am reading Fuel reference-architecture documentation in the below link:
http://docs.mirantis.com/openstack/fuel/fuel-5.1/reference-architecture.html#openstack-environment-architecture
In the page no 2 note says:
*Note*
*In environments that use vCenter as the hypervisor, the Nova-compute
serv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/11/14 16:22, Dan Smith wrote:
>> An initial inconsistency I have noticed is that some objects
>> refresh themselves from the database when calling save(), but
>> others don't.
>
> I agree that it would be ideal for all objects to behave the same
On 12/11/14 10:10, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:
On 11/11/14 13:34, Ryan Brown wrote:
I am strongly against allowing arbitrary Javascript functions for
complexity reasons. It's already difficult enough to get meaningful
errors when you
The Oslo team is pleased to announce the release of oslo.vmware 0.7.0.
This release includes several bug fixes
(https://launchpad.net/oslo.vmware/+milestone/0.7.0) as well as many other
changes:
1661a0a Updated from global requirements
33f6002 Imported Translations from Transifex
8b1f97b Do no
> An initial inconsistency I have noticed is that some objects refresh
> themselves from the database when calling save(), but others don't.
I agree that it would be ideal for all objects to behave the same in
this regard. I expect that in practice, it's not necessary for all
objects to do this,
Nikolay,
You're right. We will need to store the events in order to re-publish.
How about a separate Event model? The events are written to the DB by the
same worker that publishes the event. The retention policy for these
events is then managed by a config option.
Winson
_
On 12/11/14 15:12, Jiri Tomasek wrote:
> Approach on using Xstatic packages vs Js tooling:
>
> As only problem with using js tooling should be just actual packaging of
> it, I think it makes sense to use these tools and make development
> simpler then going other way around and using Xstatic packa
I'm currently investigating the feasibility of a generic
compare-and-swap feature for NovaObject.save(). This post isn't about
that, but that's the larger context.
As a preliminary step towards that goal, I've started by investigating
how Nova objects are saved today. Ideally there would be some
c
My point is that quoting problem do exists probably but it exists even
without YAQL being used anywhere.
For example consider Mistral workbook containing value: { get_attr:
[my_instance, first_address] }. get_attr in Mistral may have nothing to to
with Heat's get_attr and even if it is it may be ju
On Wed, Nov 12, 2014 at 4:11 AM, Chris Dent wrote:
> The current state of affairs is indeed weird.
>
> Is this something that ought to be considered in the api-wg's
> discussions?
It does and I think that is where the proposed mapping of URL-to-API should
reside. Proposed at least until it is
On Nov 12, 2014, at 5:12 AM, Victor Sergeyev wrote:
> Great job, Mike, thanks!
>
> Doug, as for migration from sqlalchemy-migrate to Alembic - at the moment
> it's hard to realize this because we suppose to keep backward compatibility
> with available migrations. I'd like to re-review existin
Hello fuelers,
I would like to request you merging CR [1] which implements blueprint [2].
It is a nice UX feature we really would like to have in 6.0. On the other
side, the implementation is really small: it is a small piece of puppet
which runs a shell script. The script always exits with 0, so
Andrew,
That just shifts the error into Nailgun which is forced to examine NTP
settings of the host. With docker containerization, it makes detecting
this much more difficult. Erroring during fuelmenu is the only chance
where a user can effectively set the NTP parameters correctly. We
could write a
I have filled out the form and very much look forward to attending!!!
Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet: bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680
From: Morgan Fainberg
To: "OpenStack Development Mailing List (not for us
Should we just block the deployment until the NTP is fixed so they
know they need to fix it?
On Wed, Nov 12, 2014 at 6:06 PM, Stanislaw Bogatkin
wrote:
> Hi all,
> Today we have a next workflow about NTP in Fuel:
>
> 1. When someone deploy a master node, we need to somehow operate with NTP
> and
On 11/11/2014 08:02 AM, Richard Jones wrote:
Hi all,
At the summit last week, we developed a plan for moving forward with
modernising Horizon's UI using AngularJS. If you weren't at that
meeting and are interested in helping out with this effort please let
me know!
The relevant etherpad fro
Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:
> On 11/11/14 13:34, Ryan Brown wrote:
> > I am strongly against allowing arbitrary Javascript functions for
> > complexity reasons. It's already difficult enough to get meaningful
> > errors when you up your YAML syntax.
>
> A
Hi all,
Today we have a next workflow about NTP in Fuel:
1. When someone deploy a master node, we need to somehow operate with NTP
and set upstream NTP servers to Fuel NTP daemon on master node.
2. NTP will enabled by default and set to default upstream values (from
ntp.org pool).
3. If user will
Sean, I'm looking into this and have proposed
https://review.openstack.org/#/c/133958/ as an interim measure. As soon as the
trove gate passes I'll try and get a couple of other votes and have that change
merged.
Dims and I had a short chat on IRC and weren't able to come up with a quick
solut
Hello Salvatore,
thanks for the response. Rest of the responses inline:
El 12/11/14 a las 10:49, Salvatore Orlando escribió:
> Hi Jaume,
>
> The concept of provider router is useful as it maps what actually already
> happens in several infrastructures. I am not entirely sure that this
> however
On 12/11/14 08:24, Stan Lagun wrote:
On Wed, Nov 12, 2014 at 3:50 PM, Zane Bitter mailto:zbit...@redhat.com>> wrote:
It's actually potentially horrible, because you introduce potential
quoting issues when you embed mistral workbooks in Heat templates or
pass Heat templates to Murano
Let's skip the ML2 IRC meeting this week, while some people are still
traveling and/or recovering. Next week I hope to have good discussions
regarding a common ML2 driver repo vs. separate repos per vendor, as
well as the ML2 BPs for Kilo.
-Bob
___
On 11/12/2014 09:17 AM, Sean Dague wrote:
> https://review.openstack.org/#/c/102315/ was merged yesterday, it
> creates a non functional trove python client. (There are currently no
> tests in python trove client to see if the commands even run after a
> code change).
>
> This means the trove devs
For the REST API to be visible from browser it should either be on the same
domain and port or it should implement CORS spec (Cross-site HTTP requests,
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS).
If REST API implements CORS, then every HTTP request will be preceded with
https://review.openstack.org/#/c/102315/ was merged yesterday, it
creates a non functional trove python client. (There are currently no
tests in python trove client to see if the commands even run after a
code change).
This means the trove devstack exercise can't work.
Which means everything test
If you have tempest running in the third party CI with every commit,
you don't need a cert test result. The CI is very much the preferred
method.
To post a result, open a bug with 'Huawei XXX driver cert result; and
the logs attached.
Other than, that, it is just a matter of waiting for reviews.
On 11/12/2014 02:35 PM, Monty Taylor wrote:
On 11/12/2014 02:40 AM, Richard Jones wrote:
On 12 November 2014 18:17, Matthias Runge wrote:
On 11/11/14 10:53, Jiri Tomasek wrote:
Hey,
Thanks for writing this up!
The Storyboard project has successfully integrated these tools into
the OpenStac
Hi Gary,
I posted the patch-set addressing ML2 plugin
https://review.openstack.org/#/c/130992/ .
I feel it is becoming long chain. It would be great we should first start
approving those patch-sets first rather than approving other bug-fix
related patch-set and ensure that all fulfills i18n trans
Hello
I am working on an api for a new feature in nova, but I am wondering
what is the correct way to add a new extension: should it be supported
by v2, v3 or both?
BR
--
Pasquale Porreca
DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)
Mobile +39 3394823805
Skype paskporr
Hi Liu,
3rd party CI isn't for driver cert test, it is for checking driver with
every review request to Cinder. Every driver vendor should setup own 3rd
party CI.
To get Cinder Driver Cert results you need to run cinder_driver_cert.sh
script from devstack repo (
https://github.com/openstack-dev/d
On 11/12/2014 02:40 AM, Richard Jones wrote:
> On 12 November 2014 18:17, Matthias Runge wrote:
>
>> On 11/11/14 10:53, Jiri Tomasek wrote:
>>> Hey,
>>>
>>> Thanks for writing this up!
>>
The Storyboard project has successfully integrated these tools into
the OpenStack CI environment.
>
Hi Steve,
We are hammering out the details right now, and will send it out to the
community,like real soon :) Thanks for the comment!
On Wed, Nov 12, 2014 at 1:53 PM, Steve Gordon wrote:
> - Original Message -
> > From: "Zhipeng Huang"
> > To: "OpenStack Development Mailing List (not f
On 11/12/2014 02:17 AM, Matthias Runge wrote:
> On 11/11/14 10:53, Jiri Tomasek wrote:
>> Hey,
>>
>> Thanks for writing this up!
>
>>> The Storyboard project has successfully integrated these tools into
>>> the OpenStack CI environment.
>
> OpenStack CI and distributors are different, because Ope
1 - 100 of 146 matches
Mail list logo
