Hi-
Its nice to have CI operators meetings.
I'm from India, Its okay for me for 05:00AM UTC on Tuesdays.
--
Trinath Somanchi - B39208
trinath.soman...@freescale.com | extn: 4048
-Original Message-
From: Anita Kuno [mailto:ante...@anteaya.info]
Sent: Tuesday, December 02, 2014 1:37 AM
What is the text that should be included in the commit messages to make
sure that it is picked up for release notes?
I'm not sure anyone tracks commit messages to create release notes.
Let's use existing DocImpact tag, I'll add check for this in the
release scripts.
But I prefer if you could
With the change, will existing instances work as before?
Yes, this cuts straight to the heart of the matter: What's the purpose of
these validation checks? Specifically, if someone is using an invalid
hostname that passed the previous check but doesn't pass an improved/updated
check,
HI,
Thanks Anita for pushing it. We will be able to be much more involved if
meetings would be earlier.
We're located in Israel, so Mondays anytime between 8:00 - 16:00, will be ideal
for us.
Nurit
-Original Message-
From: trinath.soman...@freescale.com
Hi all,
I want to confirm that about the examples of the credential api that described
at the following URL.
http://docs.openstack.org/api/openstack-identity-service/3/content/create-credential-post-credentials.html
I tried to request to our keystone server using the request example described
On Tue, Dec 02, 2014 at 09:10:01AM +, Mizutani, Michiyuki wrote:
Hi all,
I want to confirm that about the examples of the credential api that
described at the following URL.
http://docs.openstack.org/api/openstack-identity-service/3/content/create-credential-post-credentials.html
On 02/12/14 12:16 +0800, Zhi Yan Liu wrote:
Why not change other services instead of glance? I see one reason is
glance is the only one service use this option name, but to me one
reason to keep it as-it in glance is that original name makes more
sense due to the option already under profiler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
It's weird: we run python33 job for gate but not checks. Adding Cyril
Roelandt who ported the library to py3 to CC.
On 01/12/14 23:40, Thomas Goirand wrote:
On 12/01/2014 06:19 PM, Ihar Hrachyshka wrote:
Indeed, the review queue is
Hi Steven,
Thank you for your quick response.
The following document is correct as credential API of ec2tokens, isn't it?
http://developer.openstack.org/api-ref-identity-v3.html
So, I was confuse about specifying to request body of credential API.
Thanks again!
-Original Message-
Clint Byrum wrote:
Hello! I've received confirmation that our venue, the HP offices in
downtown Seattle, will be available for the most-often-preferred
least-often-cannot week of Feb 16 - 20.
Our venue has a maximum of 20 participants, but I only have 16 possible
attendees now. Please add
Sahara folks,
we have python-saharaclient version 0.7.6 release. The main changes are:
* support for server-side API filtering added to the client
* client know checks both data-processing and data_processing endpoint types
More info: https://launchpad.net/python-saharaclient/0.7.x/0.7.6
Hi All,
I am new to Murano and trying to integrate with Openstack Juno.
Any build guides or help would be appreciated.
Warm Regards,
Raghavendra Lad
IDC-IC-P-Capability
Infrastructure Consulting,
Infrastructure Services - Accenture Operations
Mobile - +91 9880040919
I totally agreed to make it to be consistent cross all projects, so I
propose to change other projects.
But I think keeping it as-it is clear enough for both developer and
operator/configuration, for example:
[profiler]
enable = True
instead of:
[profiler]
profiler_enable = True
Tbh, the
Hello, Horizoneers and UX-ers!
The default behavior of modals in Horizon (defined in turn by Bootstrap
defaults) regarding their closing is to simply close the modal once user
clicks somewhere outside of it (on the backdrop element below and around
the modal). This is not very convenient for the
On 11/27/2014 02:23 PM, Derek Higgins wrote:
On 27/11/14 10:21, Duncan Thomas wrote:
I'd suggest starting by making it an extra job, so that it can be
monitored for a while for stability without affecting what is there.
we have to be careful here, adding an extra job for this is probably the
1800UTC should generally work for Europe. The only issue is that it falls
right around dinner time.
It is however a good timing since most of the night hours fall over the
pacific ocean.
Therefore I tend to agree with Joshua's proposal since with that time range
most of the night hours would fall
Hi all,
here are exception proposal I have collected when preparing for the
2014.2.1 release,
stable-maint members please have a look!
General: cap Oslo and client library versions - sync from
openstack/requirements stable/juno, would be good to include in the
release.
Hi folks,
today we encountered a problem caused by auto-reload feature and our
code-organisation.
The problem is that web.py tries reloading modules at some point and while it
does that it expects that modules could be reloaded in any order without
raising any errors.
Unfortunately for
I don't even remember if/when autoreloading worked correctly. +1 for
disabling this feature.
2014-12-02 16:23 GMT+03:00 Roman Prykhodchenko rprikhodche...@mirantis.com
:
Hi folks,
today we encountered a problem caused by auto-reload feature and our
code-organisation.
The problem is that
I’ve noticed that in scenario tests only the OfficialClientTest in manager.py
has a tearDownClass and was wondering if there is a reason for that?
In my scenario tests I need to ensure a particular connection gets closed after
the test runs. This connection is setup in setUpClass so it makes
Months ago, I pushed for us to alternate meeting times to something that
was friendlier to me, so we started doing alternate weeks at 0700UTC. That
worked well for me, but wasn't working so well for a few people in Europe,
so we decided to give 0800UTC a try. Then DST changes happened, and wiki
Hi all,
Some time ago we had a discussion about moving Nailgun to new web framework
[1].
There was comparison [2] of two possible options: Pecan [3] and Flask [4].
We came to conclusion that we need to move Nailgun on some alive web
framework
instead of web.py [5] (some of the reasons: [6]) but
Hello Manila Team,
We identified use cases for Manila during an internal workshop
with our operators. I would like to share them with you and
update the wiki [1] since it seems to be outdated.
Before that I would like to gather feedback and you might help me
with identifying things that aren’t
On 02/12/14 16:10, James Polley wrote:
Months ago, I pushed for us to alternate meeting times to something that
was friendlier to me, so we started doing alternate weeks at 0700UTC.
That worked well for me, but wasn't working so well for a few people in
Europe, so we decided to give 0800UTC a
On 02/12/14 14:10, James Polley wrote:
Months ago, I pushed for us to alternate meeting times to something that
was friendlier to me, so we started doing alternate weeks at 0700UTC.
That worked well for me, but wasn't working so well for a few people in
Europe, so we decided to give 0800UTC a
On 12/02/2014 12:39 AM, Richard Jones wrote:
On Mon Dec 01 2014 at 4:18:42 PM Thai Q Tran tqt...@us.ibm.com
mailto:tqt...@us.ibm.com wrote:
I agree that keeping the API layer thin would be ideal. I should
add that having discrete API calls would allow dynamic population
of table.
Hi, Sebastian,
Thank you for raising this topic again.
Yes, indeed, we need to move out from web.py as soon as possible and
there are a lot of reasons why we should do it. But this topic is not
about Why, this topic is about Flask or Pecan.
Well, currently Fuel uses both of this frameworks:
*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/12/14 14:22, Alan Pevec wrote:
Hi all,
here are exception proposal I have collected when preparing for
the 2014.2.1 release, stable-maint members please have a look!
General: cap Oslo and client library versions - sync from
The Oslo team is pleased to announce the release of oslo.rootwrap 1.4.0.
This is primarily a bug fix and test-requirements update release:
$ git log --abbrev-commit --pretty=oneline --no-merges 1.3.0..1.4.0
2c43df7 Updated from global requirements
62d7322 Updated from global requirements
8c39d15
The Oslo team is pleased to announce the release of oslo.utils 1.1.0.
This release includes several bug fixes as well as many other changes.
For more details, please see the git log history below and
https://launchpad.net/oslo.utils/+milestone/1.1.0
Please report issues through launchpad:
On 12/02/2014 03:45 PM, Derek Higgins wrote:
On 02/12/14 14:10, James Polley wrote:
Months ago, I pushed for us to alternate meeting times to something that
was friendlier to me, so we started doing alternate weeks at 0700UTC.
That worked well for me, but wasn't working so well for a few people
On Tue, Dec 2, 2014 at 3:22 PM, marios mar...@redhat.com wrote:
On 02/12/14 16:10, James Polley wrote:
Months ago, I pushed for us to alternate meeting times to something that
was friendlier to me, so we started doing alternate weeks at 0700UTC.
That worked well for me, but wasn't working
Hi!
While working on fixing wrong import in novaclient v3 shell, I have found
that a lot of commands, which are listed in V3 shell(novaclient.v3.shell),
are broken, because appropriate managers are missed from V3
client(novaclient.V3.client.Client).
Template of error is ERROR (AttributeError):
On 02/12/14 15:12, Giulio Fidente wrote:
On 12/02/2014 03:45 PM, Derek Higgins wrote:
On 02/12/14 14:10, James Polley wrote:
Months ago, I pushed for us to alternate meeting times to something that
was friendlier to me, so we started doing alternate weeks at 0700UTC.
That worked well for me,
On Tue, Dec 2, 2014 at 4:12 PM, Giulio Fidente gfide...@redhat.com wrote:
On 12/02/2014 03:45 PM, Derek Higgins wrote:
On 02/12/14 14:10, James Polley wrote:
Months ago, I pushed for us to alternate meeting times to something that
was friendlier to me, so we started doing alternate weeks at
The Oslo team is pleased to announce the release of oslo.i18n 1.1.0.
For more details, please see the git log history below and
https://launchpad.net/oslo.i18n/+milestone/1.1.0
Please report issues through launchpad: https://launchpad.net/oslo.i18n
$ git log --no-color --oneline --no-merges
Hello Marc,
Here, I tried to cover mentioned use cases with implemented or not notes:
1) Implemented, but details of implementation are different for different
share drivers.
2) Not clear for me. If you mean possibility to mount one share to any
amount of VMs, then yes.
3) Nova is used only in
The Oslo team is pleased to announce the release of oslo.vmware 0.8.0.
For more details, please see the git log history below and
https://launchpad.net/oslo.vmware/+milestone/0.8.0
Please report issues through launchpad: https://launchpad.net/oslo.vmware
$ git log --no-color --oneline
Now that we're in the thick of working hard on Kilo deliverables, I'd
like to make some changes to the neutron core team. Reviews are the
most important part of being a core reviewer, so we need to ensure
cores are doing reviews. The stats for the 180 day period [1] indicate
some changes are
On 12/02/2014 02:31 AM, Alan Pevec wrote:
What is the text that should be included in the commit messages to make sure
that it is picked up for release notes?
I'm not sure anyone tracks commit messages to create release notes.
Let's use existing DocImpact tag, I'll add check for this in the
On 12/02/2014 07:22 AM, Alan Pevec wrote:
Hi all,
here are exception proposal I have collected when preparing for the
2014.2.1 release,
stable-maint members please have a look!
General: cap Oslo and client library versions - sync from
openstack/requirements stable/juno, would be good to
On 12/02/2014 09:55 AM, Igor Kalnitsky wrote:
Hi, Sebastian,
Thank you for raising this topic again.
[snip]
Personally, I'd like to use Flask instead of Pecan, because first one
is more production-ready tool and I like its design. But I believe
this should be resolved by voting.
The Oslo team is pleased to announce the release of oslo.concurrency 0.3.0.
This release includes a number of fixes for problems found during the
initial adoptions of the library, as well as some functionality
improvements.
For more details, please see the git log history below and
On Dec 2, 2014, at 10:59 AM, Kyle Mestery mest...@mestery.com wrote:
First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
neutron-core. Bob and Nachi have been core members for a while now.
They have contributed to Neutron over the years in reviews, code and
leading
The Oslo team is pleased to announce release 1.9.0 of cliff.
This is primarily a bug-fix release, but does include a requirements update.
For more details, please see the git log history below and
https://launchpad.net/python-cliff/+milestone/1.9.0
Please report issues through launchpad:
I like David's approach, but having two modals (one for the form, one for
the confirmation) on top of each other is a bit weird and would require
constant checks for input.
We already have three ways to close the dialog today: via the cancel
button, X button, and ESC key. It's more important to
Hi Andrea,
Though both interfaces come up, only one will response to the ping from the
neutron router.
When I disable it, then the second one will response to ping.
So it looks like only one interface is useful at a time.
My question is is there any useful case for this, I.e. Why would you do
I am happy with the proposed change in the core team.
Many thanks to the outgoing members and a warm welcome to hell (err core
team) to Henry and Kevin!
Salvatore
Il 02/dic/2014 17:20 Mark McClain m...@mcclain.xyz ha scritto:
On Dec 2, 2014, at 10:59 AM, Kyle Mestery mest...@mestery.com
Congrats to Henry and Kevin, +1!
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
The Oslo team is pleased to announce release 2.3.0 of oslosphinx.
This release includes bug fixes, new features, and updated requirements.
For more details, please see the git log history below and
http://launchpad.net/oslosphinx/+milestone/2.3.0
Please report issues through launchpad:
Assuming I still have a vote, I vote +1 for adding Henry and Kevin, both
of whom I am confident will do a great job as core reviewer.
I'd ask people to consider voting against dropping me from core (and I
vote -1 on that if I get a vote). During Juno, my plan was to balance my
time between
I see - looks like the repro I¹m based off of hasn¹t keep up with the
latest.
I¹ll have to look at the ScenarioTest.
Thanks
Rich
On 12/2/14, 9:54 AM, Andrea Frittoli andrea.fritt...@gmail.com wrote:
Hello Rich,
in the latest tempest we made two significant changes compared to the
version
The Oslo team is pleased to announce release 1.3.0 of oslotest.
This release is primarily to update the dependencies for the library.
For more details, please see the git log history below and
http://launchpad.net/oslotest/+milestone/1.3.0
Please report issues through launchpad:
The Oslo team is pleased to announce release 1.5.0 of oslo.config.
This is primarily a bug-fix release, but does include requirements changes.
For more details, please see the git log history below and
http://launchpad.net/oslo/+milestone/1.5.0
Please report issues through launchpad:
On 11/27/2014 07:23 AM, Derek Higgins wrote:
On 27/11/14 10:21, Duncan Thomas wrote:
I'd suggest starting by making it an extra job, so that it can be
monitored for a while for stability without affecting what is there.
we have to be careful here, adding an extra job for this is probably the
- Original Message -
From: Alan Pevec ape...@gmail.com
To: Jay Bryant jsbry...@electronicjungle.net, OpenStack Development
Mailing List (not for usage questions)
What is the text that should be included in the commit messages to make
sure that it is picked up for release notes?
- Original Message -
From: Danny Choi (dannchoi) dannc...@cisco.com
To: openstack-dev@lists.openstack.org
Hi Andrea,
Though both interfaces come up, only one will response to the ping from the
neutron router.
When I disable it, then the second one will response to ping.
So it
The Oslo team is pleased to announce release 0.2.0 of oslo.middleware.
This is primarily a bug-fix release, but does include requirements changes.
For more details, please see the git log history below and
https://launchpad.net/oslo.middleware/kilo/0.2.0
Please report issues through
Solum Team,
As agreed in today’s team meeting, we are shifting our meetings to 2100 UTC on
Tuesdays in #openstack-meeting-alt. We are ending our alternating meeting
schedule for now. For scheduling specifics, please see:
https://wiki.openstack.org/wiki/Meetings/Solum
Regards,
Adrian Otto
The Oslo team is pleased to announce the release of oslo.messaging
1.5.0.
This release includes a number of fixes about rabbit driver timeout that
was not always respected, starts using kombu API instead of custom code
when it's possible. It also introduces the first ZMQ unit tests.
And ZMQ
Per the meeting, put together an etherpad here:
https://etherpad.openstack.org/p/lbaas-kilo-meetup
I would like to get the location and dates finalized ASAP (preferrably
the next couple of days).
We'll also try to do the same as the neutron and octava meetups for
remote attendees.
Excerpts from Danny Choi (dannchoi)'s message of 2014-12-02 08:34:07 -0800:
Hi Andrea,
Though both interfaces come up, only one will response to the ping from the
neutron router.
When I disable it, then the second one will response to ping.
So it looks like only one interface is useful at
Renat,
I agree with the two methods you proposed.
On processing the events, I was thinking a separate entity. But you gave
me an idea, how about a system action for publishing the events that the
current executors can run?
Alternately, instead of making HTTP calls, what do you think if mistral
Could you please clarify? Do you mean you want to setup everything behind
a proxy? or do you mean you want to setup just gerrit behind a proxy?
On Mon, Dec 1, 2014 at 6:26 PM, thanh le giang legiangth...@gmail.com
wrote:
Dear all
I have set up a CI system successfully with directly access
On Tue, Dec 2, 2014 at 1:49 AM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Anant Patil's message of 2014-11-30 23:02:29 -0800:
On 27-Nov-14 18:03, Murugan, Visnusaran wrote:
Hi Zane,
At this stage our implementation (as mentioned in wiki
We've discovered a couple of problems as a result of this release. pep8
in most/all of the projects using oslo.concurrency is failing due to the
move out of the oslo namespace package and the fact that hacking doesn't
know how to handle it, and nova unit tests are failing due to a problem
with
Yes, that's the synchronization block for which we use the stack lock.
Currently, a thread spin waits to acquire the lock to enter this critical
section.
I don't really know how to do application level transaction. Is there an
external library for that? AFAIK, we cannot switch from DB transaction
One of the changes in this release was a move from using the “oslo” namespace
to using a non-namespaced package “oslo_concurrency”. We included some shims to
allow imports to work correctly, but the hacking rule to verify whether an
import is actually a module was not recognizing these shims
Hi folks
Congrats! Henry and Kevin.
I'll keep contributing the community, but Thank you for working with
me as core team :)
Best
Nachi
2014-12-03 2:05 GMT+09:00 Carl Baldwin c...@ecbaldwin.net:
+1 from me for all the changes. I appreciate the work from all four
of these excellent
Hi,
I want to setup everything behind proxy, but i am stuck at step configure
zuul connect to gerrit. I can't find any option to set proxy on zuul.conf
file.
Thanks
2014-12-03 1:00 GMT+07:00 Zaro zaro0...@gmail.com:
Could you please clarify? Do you mean you want to setup everything behind
a
Hello all,
I actually tried to use Pecan and even created a couple of PoCs, but
there due to historical reasons of how our API is organized it will
take much more time to implement all workarounds we need to issues
Pecan doesn't solve out of the box, like working with non-RESTful
URLs, reverse
On 12/01/2014 09:09 AM, Doug Hellmann wrote:
On Nov 30, 2014, at 8:51 PM, Jamie Lennox jamielen...@redhat.com wrote:
TL;DR: I think we can handle most of oslo.context with some additions to
auth_token middleware and simplify policy enforcement (from a service
perspective) at the same time.
On 12/02/2014 03:46 PM, Clint Byrum wrote:
1) Conform all o-r-c scripts to the logging standards we have in
OpenStack, or write new standards for diskimage-builder and conform
them to those standards. Abolish non-conditional xtrace in any script
conforming to the standards.
Honestly in the
Hi all
I have submitted a small blueprint to allow filtering of available memory pages
Reported by libvirt.
https://blueprints.launchpad.net/nova/+spec/libvirt-allowed-mempage-sizes
I believe that this change is small enough to not require a spec as per
The hacking project is currently managed by the Oslo team. Normally Joe Gordon
handles all of the release work, and so I haven’t bothered to look at how the
Launchpad project is set up or how the branches are managed before today.
However, today’s issue with oslo.concurrency resulted in a need
Excerpts from Anant Patil's message of 2014-12-02 10:37:31 -0800:
Yes, that's the synchronization block for which we use the stack lock.
Currently, a thread spin waits to acquire the lock to enter this critical
section.
I don't really know how to do application level transaction. Is there an
This sounds more like you need to pay off technical debt and clean up your
API.
Michael
On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov nmar...@mirantis.com
wrote:
Hello all,
I actually tried to use Pecan and even created a couple of PoCs, but
there due to historical reasons of how our API
On Tue, Dec 2, 2014 at 9:48 PM, Doug Hellmann d...@doughellmann.com wrote:
The hacking project is currently managed by the Oslo team. Normally Joe
Gordon handles all of the release work, and so I haven’t bothered to look
at how the Launchpad project is set up or how the branches are managed
Michael, we already solved all issues I described, and I just don't
want to solve them once again after moving to another framework. Also,
I think, nothing of these wishes contradicts with good API design.
On Tue, Dec 2, 2014 at 10:49 PM, Michael Krotscheck
krotsch...@gmail.com wrote:
This
Will the bugs created by this end up in the openstack-manuals project (which
I don't think is the right place for them in this case) or has it been set up
to create them somewhere else (or not at all) when the commits are against
the stable branches?
Docs team, how do you handle DocImpact
Hi,
on Saturday, Dec 6 at 16:00 UTC Gerrit will be unavailable for about 30
minutes while we rename some projects. Existing reviews, project watches,
etc, should all be carried over. So far, we have the following list of
projects to rename:
* stackforge/heat-translator -
On Tue, Dec 2, 2014 at 2:59 PM, Alan Pevec ape...@gmail.com wrote:
Will the bugs created by this end up in the openstack-manuals project
(which I don't think is the right place for them in this case) or has it
been set up to create them somewhere else (or not at all) when the commits
are
- Original Message -
From: Anne Gentle a...@openstack.org
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
On Tue, Dec 2, 2014 at 2:59 PM, Alan Pevec ape...@gmail.com wrote:
Will the bugs created by this end up in the
On Tue, Dec 2, 2014 at 3:44 PM, Steve Gordon sgor...@redhat.com wrote:
- Original Message -
From: Anne Gentle a...@openstack.org
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
On Tue, Dec 2, 2014 at 2:59 PM, Alan Pevec
Hi all,
Based on last week's conversation [1] I have tried to update the use cases page
to remove the emphasis on requirements/solutions and focus on the what and
why and to provide some guidance as to initial scope to help those wishing to
submit use cases in framing them.
Please review and
Excerpts from Ian Wienand's message of 2014-12-02 11:22:31 -0800:
On 12/02/2014 03:46 PM, Clint Byrum wrote:
1) Conform all o-r-c scripts to the logging standards we have in
OpenStack, or write new standards for diskimage-builder and conform
them to those standards. Abolish non-conditional
General: cap Oslo and client library versions - sync from
openstack/requirements stable/juno, would be good to include in
the release.
https://review.openstack.org/#/q/status:open+branch:stable/juno+topic:openstack/requirements,n,z
+2,
let's keep all deps in sync. Those updates do not
On Dec 2, 2014, at 5:41 PM, Alan Pevec ape...@gmail.com wrote:
General: cap Oslo and client library versions - sync from
openstack/requirements stable/juno, would be good to include in
the release.
In this case we're referring to how we handle DocImpact for specific
branches of a project (say stable/juno of Nova, for example). I don't think
we'd want to change the DocImpact handling for the entire project to go
somewhere other than openstack-manuals. As far as I know the current setup
On Tue, Dec 2, 2014 at 5:10 PM, Alan Pevec ape...@gmail.com wrote:
In this case we're referring to how we handle DocImpact for specific
branches of a project (say stable/juno of Nova, for example). I don't
think
we'd want to change the DocImpact handling for the entire project to go
On 01/12/14 18:34, Angus Salkeld wrote:
I'd suggest a combination between A and B.
We may not be as far apart as I thought.
1) Separate some of the autoscaling logic into libraries in Heat
2) Get the separated REST service in place and working (using the above
heat library)
3) Add an
anteaya,
UTC 7:00 AM to UTC9:00, or UTC11:30 to UTC13:00 is ideal time for china.
if there is no time slot there, just pick up any time between UTC 7:00 AM to
UCT 13:00. ( UTC9:00 to UTC 11:30 is on road to home and dinner.)
Yongi He
-Original Message-
From: Anita Kuno
Hi all,
Following is the subteam report for Ironic. As usual, this is pulled
directly from the Ironic whiteboard[0] and formatted.
Testing (adam_g)
- Nova stable merges are being bit by a race in the sideways grenade job:
https://bugs.launchpad.net/devstack/+bug/1398128 /
Hi,
I tried this a while back and it does not work [1]. Last I looked, there was no
config option, and nothing in the code to allow it. I’m not aware of any
patches that change that.
I got mine working by getting port 29418 opened for review.openstack.org ip
address.
Ramy
[1]
On 12/2/2014 12:33 PM, Ben Nemec wrote:
We've discovered a couple of problems as a result of this release. pep8
in most/all of the projects using oslo.concurrency is failing due to the
move out of the oslo namespace package and the fact that hacking doesn't
know how to handle it, and nova
Murano installation options are described at:
http://murano.readthedocs.org/en/latest/
Thanks,
Ruslan
On Tue, Dec 2, 2014 at 1:41 PM, raghavendra@accenture.com wrote:
Hi All,
I am new to Murano and trying to integrate with Openstack Juno.
Any build guides or help would be
I would agree in principle - keeping the user from losing data with accidental
side clicks is important, and having a modal on a modal is not a great
experience. We could make the closing of the modal upon outside click just
contextual on whether or not the user has entered data / modified
On 12/02/2014 06:14 AM, Russell Sim wrote:
Hi,
From what I can see it seems like the developer documentation available
on the OpenStack website is generated from the git repositories.
http://docs.openstack.org/developer/openstack-projects.html
Are older versions of this documentation
Dear all TC PTL,
In the 40 minutes cross-project summit session “Approaches for scaling out”[1],
almost 100 peoples attended the meeting, and the conclusion is that cells can
not cover the use cases and requirements which the OpenStack cascading
solution[2] aim to address, the background is
+1 for Kevin and Henry!
On Tue, Dec 2, 2014 at 10:40 AM, Nati Ueno nati.u...@gmail.com wrote:
Hi folks
Congrats! Henry and Kevin.
I'll keep contributing the community, but Thank you for working with
me as core team :)
Best
Nachi
2014-12-03 2:05 GMT+09:00 Carl Baldwin
1 - 100 of 108 matches
Mail list logo
