What will the availability zones API tell the user about the zones? Are
they just opaque strings that the user doesn't really understand?
What I'm a little worried about is that it seems like we are having the
user doing the work of the scheduler.
Is this is for getting affinity or anti-affinity
To anyone who cares,
I made a try to use kombu 2.5 (specifically its reconnecting logic), with
oslo.messaging (which uses kombu's reconnecting logic after kilo). No
matter whether heartbeat is enabled or not, there are truly many problems.
NoneType Error [1], eg.
I have to manually backport severa
On 2015-12-16 08:23, Mike Scherbakov wrote:
> We could consider downgrading in Fuel 9.0, but I'd very carefully
> consider that. As Vladimir Kuklin said, there are may be other users who
> already rely on 9.3 for some of their enhancements.
That will be way too late for that, as it will make upgra
On 2015-12-16 10:14, Bartłomiej Piotrowski wrote:
> On 2015-12-16 08:23, Mike Scherbakov wrote:
>> We could consider downgrading in Fuel 9.0, but I'd very carefully
>> consider that. As Vladimir Kuklin said, there are may be other users who
>> already rely on 9.3 for some of their enhancements.
>
On 2015-12-15 18:16, Roman Prykhodchenko wrote:
> Aleksandra,
>
> thank you for the clarification, it makes sense to me now.
>
> In my opinion our current approach is not flexible at all and very outdated.
After splitting fuel-web to smaller components we realized that some of
them may be actual
Hi,
Minutes of today's Vitrage IRC meeting:
http://eavesdrop.openstack.org/meetings/vitrage/2015/vitrage.2015-12-16-09.00.html
See you next week,
Ifat.
__
OpenStack Development Mailing List (not for usage questions)
Unsub
Actually, its gloval problem :
UI accessible for user *earlier* then deployment has been done. I think we
should also handle this somehow - otherwise user can start doing "some
things" like spawning HW - and fail .
What about add some check or some message "Fuel-master Deployment in
progress, plea
joehuang wrote:
Hi, Ihar,
Is there any sub-project under Neutron stadium dealing with cross Neutron
L2/L3 networking? If there is no one, why not introduce a new one.
I believe I was misled by the suggestion of having a 'neutron-ovn like
agent’. If you merely meant you will have anothe
Fuelers,
with the switch to CentOS 7, we also started using Puppet 3.8 in place
of 3.4. Is there any reason to run entire range of
gate-fuel-library-puppet-unit-3.*-dsvm-centos7 tests?
I suppose we could leave only 3.8 and 4.0 there (at least for master).
For stable branches we could keep just 3.
Hi Ghanshyam,
Thanks for your response.
It seems that I'm headed in the right direction.
One more question. - Should we migrate from 'service_client' to 'rest_client'
in tempest-lib?
Best regards,
Ryota
> -Original Message-
> From: GHANSHYAM MANN [mailto:[email protected]]
>
Hi Dima,
On Wed, Dec 16, 2015 at 12:03 AM, Dmitriy Shulyak wrote:
> Hello folks,
>
> This topic is about configuration storage which will connect data sources
> (nailgun/bareon/others) and orchestration. And right now we are developing
> two projects that will overlap a bit.
What 2 projects?
>
>
Hi,
Just a quick note to let you know that we are changing CloudKitty
release type. We used independent one which forbids us of having stable
branches and being part of the OpenStack release. We already discussed
it during the OpenStack summit in Tokyo and it was pretty clear that we
needed to cha
Hi all,
As you may know, support of Python 2.6 was dropped this month from most of
OpenStack projects. Also infrastructure team dropped Centos 6.x jobs.
I'm ok with dropping Python 2.6 support from the master(Mitaka), but what
about stable/kilo and stable/liberty ? Kilo and Liberty were released w
+1 for Lukasz concerns.
But if we really need operate with "solar resources database" as a kv
store, then we could implement service on top of it, It could be then
separate project, which would work as separate service. Would it fulfill
the requirements ? (we could implement it using some already
On 16.12.2015 00:03, Dmitriy Shulyak wrote:
> Hello folks,
>
> This topic is about configuration storage which will connect data
> sources (nailgun/bareon/others) and orchestration. And right now we are
> developing two projects that will overlap a bit.
>
> I understand there is not enough contex
On 2015-12-16 12:33, Andrey Kurilin wrote:
Hi all,
As you may know, support of Python 2.6 was dropped this month from most
of OpenStack projects. Also infrastructure team dropped Centos 6.x jobs.
I'm ok with dropping Python 2.6 support from the master(Mitaka), but
what about stable/kilo and stab
It sounds great that you guys completely move to OpenStack. Sorry for
late reply, I'm in a business trip for more than half a month which is
really exhausted.
OK, I know that you guys have some plan. I do need such a tool in the
near future. It's really important for operation.
Thanks, Ryu.
On T
We are happy to introduce Bareon [0], which is a fork of fuel_agent [1]
project which have been developed under Fuel’s umbrella.
Bareon provides flexible and data driven interface to perform actions
which are related to operating system installation. In contrary to standard
kickstart and preseed w
Hi Midoers,
I have a platform running Midonet 2015 (I think it is the last release
when you switch to 5.0).
I cannot ping from VM to external gateway IP (which is set up at the
physical router side).
VM inter-connectivity is OK.
When I tcpdump packets on the physical interface located in the gat
Updated:
Lots of ARP requests from external physical router to VM are catched
on the physical NIC binded to provider router port.
It seems that external physical router doesn't get answers to these
ARP requests.
On Wed, Dec 16, 2015 at 8:08 PM, Li Ma wrote:
> Hi Midoers,
>
> I have a platform r
Hi -
When I try to install devstack+ovn, I get this error with OVS.
make[2]: Leaving directory `/usr/src/linux-headers-3.13.0-32-generic'
depmod `sed -n 's/#define UTS_RELEASE "\([^"]*\)"/\1/p'
/lib/modules/3.13.0-32-generic/build/include/generated/utsrelease.h`
make[1]: Leaving directory `/opt/
> From what I understand, we are using 9.2 since the CentOS 7 switch. Can
> anyone point me to a bug caused by that?
AFAIK, there's no such bugs. Some folks have just *concerns*. Anyway,
it's up to packaging team to decide whether to package or not.
From Nailgun POV, I'd like to see classical RDB
Perfect, thank you Alex.
I'll depend the update review on it.
Best regards,
Alex Levine
On 12/15/15 4:03 PM, Alex Xu wrote:
Hi, Alexandre,
we discussed this on api meeting
http://eavesdrop.openstack.org/meetings/nova_api/2015/nova_api.2015-12-15-12.00.log.html
Finally people agreement o
> I really don't like setting the error message as the default one in
> the DB schema and consider it as a last resort solution. If
> possible update the message to error one just before you start
> to build the image.
+1.
> What about add some check or some message
> "Fuel-master Deployment in p
+1 to Vladimir Kozhukalov,
Entire point of moving branches creation to SCF was to perform such changes
as
early as possible in the release, I see no reasons to wait for HCF.
Thanks,
On Wed, Dec 16, 2015 at 10:19 AM, Vladimir Kozhukalov <
[email protected]> wrote:
> -1
>
> We already disc
On Wed, Dec 16, 2015 at 12:40 PM, Bogdan Dobrelya
wrote:
> Data resources shall fill the configdb by results of the fetched data
> shaped by data processors aka serializers. The shaping process assumes
> applying of all versioning and schema transformations knowledge required
> to convert data fro
Hi, Ihar,
Thank you very much. You are correct, it's a new Neutron plugin but not
"Neutron-ovn like agent" :)
Best Regards
Chaoyi Huang ( joehuang )
From: Ihar Hrachyshka [[email protected]]
Sent: 16 December 2015 18:28
To: OpenStack Development Mailing
I have been noticing a fair amount of redundant work going on in magnum,
python-magnumclient and magnum-ui with regards to APIs we have been intending
to drop support for. During the Tokyo summit it was decided that we should
support for only COE APIs that all COEs can support which means droppi
>If it had py26 classifiers, that was an error.
The list of libraries with py26 classifiers is too huge:
astara - stable/kilo, stable/liberty
astara-appliance - stable/kilo, stable/liberty
astara-horizon - stable/kilo, stable/liberty
astara-neutron - stable/kilo, stable/liberty
bifrost - stable/li
Hi,
Sorry that the network connection problem stopped me attending the meeting.
Hope that we can arrive at the phase 1 milestone in the todo-list by the end of
this week.
Best Regards
Chaoyi Huang ( joehuang )
From: joehuang
Sent: 16 December 2015 14:05
To
> We keep it As Is, and say "user should not use Fuel until Fuel
> Master deployment is finished".
Yep deployment can be finished, but was it successful? As I already told
deployment was finished, but bootstrap wasn't built. Command for building
bootstrap wasn't called because of some reason.
> W
Hi Dmitry,
I also don't think that we should duplicate the data in configdb,
because in this case there will be +2 additional interfaces which
will require to covert the data into configdb and after that from
configdb to Solar, which seems redundant overhead.
But we should be able to put the data
> As I already told deployment was finished, but bootstrap wasn't built.
Bootstrap building *is* a part of master node deployment. If you guys
show "deployment is successful" before running building bootstrap,
then it's something you have to fix.
> Fuel deploying => WebUI blocked => deployment
On 12/16/2015 07:43 AM, Somanchi Trinath wrote:
> Hi –
>
>
>
> When I try to install devstack+ovn, I get this error with OVS.
>
>
>
> make[2]: Leaving directory `/usr/src/linux-headers-3.13.0-32-generic'
>
> depmod `sed -n 's/#define UTS_RELEASE "\([^"]*\)"/\1/p'
> /lib/modules/3.13.0-32-g
Hi,
We're having more and more contributors to the CloudKitty project, which
is really nice. But sadly we hardly see new faces at the meetings.
This mail is just to make a quick check to find out what's the reason
behind that.
Is this because the meeting hours are hard to attend? I know that most
oslo.db test_migrations is using methods for alembic, which changed in
the 0.8.4 release. This ends up causing a unit test failure (at least in
the Nova case) that looks like this -
http://logs.openstack.org/44/258444/1/check/gate-nova-python27/2ed0401/console.html#_2015-12-16_12_20_17_404
There i
Le 16/12/2015 14:59, Sean Dague a écrit :
oslo.db test_migrations is using methods for alembic, which changed in
the 0.8.4 release. This ends up causing a unit test failure (at least in
the Nova case) that looks like this -
http://logs.openstack.org/44/258444/1/check/gate-nova-python27/2ed0401/
On 12/16/2015 02:22 PM, Andrey Kurilin wrote:
>>If it had py26 classifiers, that was an error.
>
> The list of libraries with py26 classifiers is too huge:
> astara - stable/kilo, stable/liberty
> astara-appliance - stable/kilo, stable/liberty
> astara-horizon - stable/kilo, stable/liberty
> astar
> Bootstrap building *is* a part of master node deployment.
Not always, user can set flag `skip_default_img_build` then building
bootstrap will not executed.
> If you guys show "deployment is successful" before running building
bootstrap,
> then it's something you have to fix.
fuel-bootstrap-cli
On Wed, Dec 16, 2015 at 3:33 AM, Bartłomiej Piotrowski
wrote:
> Fuelers,
>
> with the switch to CentOS 7, we also started using Puppet 3.8 in place
> of 3.4. Is there any reason to run entire range of
> gate-fuel-library-puppet-unit-3.*-dsvm-centos7 tests?
>
> I suppose we could leave only 3.8 and
On 12/16/2015 8:28 AM, Thomas Goirand wrote:
On 12/16/2015 02:22 PM, Andrey Kurilin wrote:
If it had py26 classifiers, that was an error.
The list of libraries with py26 classifiers is too huge:
astara - stable/kilo, stable/liberty
astara-appliance - stable/kilo, stable/liberty
astara-horizo
Very useful information. Thanks, Assaf.
Fawad Khaliq
On Thu, Dec 10, 2015 at 6:26 AM, Assaf Muller wrote:
> Today we merged [1] which adds content to the Neutron testing guidelines:
>
> http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron
>
> The docu
On 15.12.2015 19:12, Emilien Macchi wrote:
On 12/15/2015 12:23 PM, Jiří Stránský wrote:
On 15.12.2015 17:46, Emilien Macchi wrote:
For information, Puppet OpenStack CI is consistent for unit & functional
tests, we use a single (versionned) Puppetfile:
https://github.com/openstack/puppet-opens
Hi Tom,
If I remember correctly, the decision is to drop the COE-specific API (Pod,
Service, Replication Controller) in the next API version. I think a good way to
do that is to put a deprecated warning in current API version (v1) for the
removed resources, and remove them in the next API versi
Hi, I'm following [1] to configure static route for uplink. I'm not
sure whether I'm getting it.
(1) Floating-IP subnet (gateway?) configuration in the guide?
(2) eth0 configuration in the guide?
(3) Do I need to configure uplink physical router? back route to eth0?
(4) What if I just bind router0
Great job, especially considering complexity of the problem and late arrival.
This proves that magic still can happen :)
Regards,
> On 12 Dec 2015, at 00:25, Vladimir Kuklin wrote:
>
> Fuelers
>
> I am thrilled to announce that task based deployment engine [0] has been just
> merged into F
Hi all,
I'd like to start discussion on how Ironic is using Neutron when Keystone
is involved.
Recently the patch [0] was merged in Ironic to fix a bug when the token
with which to create the neutronclient is expired. For that Ironic now
passes both username/password of its own service user and t
On Tue, Dec 15, 2015 at 05:19:19PM -0800, James Penick wrote:
> > getting rid of the raciness of ClusteredComputeManager in my
> >current deployment. And I'm willing to help other operators do the same.
>
> You do alleviate race, but at the cost of complexity and
> unpredictability. Breaking tha
On 12/16/2015 09:10 AM, Sylvain Bauza wrote:
>
>
> Le 16/12/2015 14:59, Sean Dague a écrit :
>> oslo.db test_migrations is using methods for alembic, which changed in
>> the 0.8.4 release. This ends up causing a unit test failure (at least in
>> the Nova case) that looks like this -
>> http://l
On 12/15/2015 11:39 AM, Igor Kalnitsky wrote:
> Hey Mike,
>
> Thanks for your input.
>
>> actually not. if you replace your ARRAY columns with JSON entirely,
>
> It still needs to fix the code, i.e. change ARRAY-specific queries
> with JSON ones around the code. ;)
>
>> there's already a mos
On 12/15/2015 02:53 PM, Andrew Maksimov wrote:
> +1 to Igor suggestion to downgrade Postgres to 9.2. Our users don't work
> directly with Postgres, so there is no any deprecation of Fuel features.
> Maintaining our own custom Postgres package just because we want "JSON
> column" is not a rational
On 12/16/2015 11:22 AM, Mike Bayer wrote:
>
>
> On 12/16/2015 09:10 AM, Sylvain Bauza wrote:
>>
>>
>> Le 16/12/2015 14:59, Sean Dague a écrit :
>>> oslo.db test_migrations is using methods for alembic, which changed in
>>> the 0.8.4 release. This ends up causing a unit test failure (at least in
>
Hi all,
We discussed in today's meeting and confirmed that we will skip our schedule
meetings for:
* December 23rd
* December 30th
* January 6th
We will reconvene on January 13th, I will send a reminder close to that date.
Thanks,
Steve
___
On 12/16/2015 11:37 AM, Sean Dague wrote:
> On 12/16/2015 11:22 AM, Mike Bayer wrote:
>>
>>
>> On 12/16/2015 09:10 AM, Sylvain Bauza wrote:
>>>
>>>
>>> Le 16/12/2015 14:59, Sean Dague a écrit :
oslo.db test_migrations is using methods for alembic, which changed in
the 0.8.4 release. This
On Tue, Dec 15, 2015 at 10:08 PM, darren wang
wrote:
> Hi Dolph,
>
>
>
> We are doing something on “domain” now, but I saw bp-reseller which will
> integrate domain with project and remove domain finally, I’m pretty
> concerned that will domain be removed in Mitaka?
>
No, the API-facing concept
On 12/16/2015 11:37 AM, Sean Dague wrote:
> On 12/16/2015 11:22 AM, Mike Bayer wrote:
>>
>>
>> On 12/16/2015 09:10 AM, Sylvain Bauza wrote:
>>>
>>>
>>> Le 16/12/2015 14:59, Sean Dague a écrit :
oslo.db test_migrations is using methods for alembic, which changed in
the 0.8.4 release. Thi
On Wed, Dec 16, 2015 at 9:59 AM, Pavlo Shchelokovskyy <
[email protected]> wrote:
> Hi all,
>
> I'd like to start discussion on how Ironic is using Neutron when Keystone
> is involved.
>
> Recently the patch [0] was merged in Ironic to fix a bug when the token
> with which to create the
Hi all,
Renat and I had an action item to think about "Mistral HA and multi-regional
support".
No big surprises. These are the meeting minutes:
Mistral Multi-Region:
* A blueprint already exists [1]
* Most topics were already discussed in Mitaka OpenStack summit and are
described in the bluepri
> It was in the queue for 11 days, Dan Smith took a look, he added Jay
> Pipes, and I also added Matt Riedemann, there were also a bunch of
> neutron folks on it since this fix originated from their end.
Yeah, and both of those other people have had serious other commitments
in the last two weeks.
On 12/16/2015 11:53 AM, Sean Dague wrote:
> On 12/16/2015 11:37 AM, Sean Dague wrote:
>> On 12/16/2015 11:22 AM, Mike Bayer wrote:
>>>
>>>
>>> On 12/16/2015 09:10 AM, Sylvain Bauza wrote:
Le 16/12/2015 14:59, Sean Dague a écrit :
> oslo.db test_migrations is using methods for a
I'd like to propose moving oslo.policy from the oslo program to the
keystone program. Keystone developers know what's going on with oslo.policy
and I think are more interested in what's going on with it so that reviews
will get proper vetting, and it's not like oslo doesn't have enough going
on wit
Hi,
As you might already know we are using the independent release which
means that we can release whenever we want.
Like we discussed during the Tokyo summit our goal is to release a
couple versions before the Mitaka release which should correspond to the
1.0 version.
Every version will impleme
Hello all,
I described use case and simple tool that I'd like to implement as a
first step in this topic - would you please
review it and provide me with feedback before I start coding?
Is the use-case realistic? Is this tool going to be useful given the
features I described? Any other comment
Yeah. The twisted take-away from this thread is to not test your changes
against openstack so you have plausible deniability. :)
On Wed, Dec 16, 2015 at 9:04 AM, Mike Bayer wrote:
>
>
> On 12/16/2015 11:53 AM, Sean Dague wrote:
> > On 12/16/2015 11:37 AM, Sean Dague wrote:
> >> On 12/16/2015 11:
On Wed, Dec 16, 2015 at 11:13 AM, Brant Knudson wrote:
>
> I'd like to propose moving oslo.policy from the oslo program to the
> keystone program. Keystone developers know what's going on with oslo.policy
> and I think are more interested in what's going on with it so that reviews
> will get prop
Hi,
I am sure oslo.policy would be good under Keystone's governance. But I am
not sure I understood what's wrong in having oslo.policy under the oslo
program ?
Jordan
On Wed, Dec 16, 2015 at 6:13 PM, Brant Knudson wrote:
>
> I'd like to propose moving oslo.policy from the oslo program to the
>
Vladimir
I am pretty much for removing docker, but I do not think that we should
startle our developers/QA folks with additional efforts on fixing 2
different environments. Let's just think from the point of development
velocity here and at delay such changes for at least after NY. Because if
we d
I don’t see a benefit from supporting the old API through a microversion
when the same functionality will be available through the native API. We
are still early enough in Magnum to make significant API changes, no one
is using Magnum as a whole in production.
Have we had any discussion on addi
On 16/12/15 11:53 -0500, Sean Dague wrote:
On 12/16/2015 11:37 AM, Sean Dague wrote:
On 12/16/2015 11:22 AM, Mike Bayer wrote:
On 12/16/2015 09:10 AM, Sylvain Bauza wrote:
Le 16/12/2015 14:59, Sean Dague a écrit :
oslo.db test_migrations is using methods for alembic, which changed in
the
Hi TripleO,
I recently sent an email about my progress on adding monitoring in TripleO.
I've made more progress this week on logging and I would like to present
you the work.
If you're interested, please look this 12 min presentation:
https://youtu.be/SJWA_vwc4wI
Summary:
* About operational too
On Wed, Dec 16, 2015 at 10:04 AM, Mike Bayer wrote:
>> Instead of just breaking the world, and burning 10s to 100 engineer
>> hours in redo tests and investigating and addressing the break after the
>> fact.
We shouldn't let this happen in the first place. I think this is our fault.
We need to
Vladimir,
I have other activities planned for the time immediately after SCF
(separating UI from fuel-web, maybe it is even more invasive :-)) and it is
not a big deal to postpone this feature or another. I am against the
approach itself of postponing something because it is too invasive. If we
cr
>
> > What if user choose CentOS bootstrap? We ship it on ISO, so why do
> > we need to show error message?
>
> CentOS bootstrap still is not activated
>
Its pretty simple case-flow:
If selected ubuntu:
- Try build
-- Notify if build and activate fail
-- Notify if build and activate ok
If sel
On 2015-12-16 11:03:38 -0700 (-0700), Carl Baldwin wrote:
[...]
> We need to vet new package releases before they wreak havoc. We need
> to accept new package releases by proposing a patch to update the
> version and take it through the gate. Weren't we working on this at
> one point? I understa
Carl Baldwin wrote:
On Wed, Dec 16, 2015 at 10:04 AM, Mike Bayer wrote:
Instead of just breaking the world, and burning 10s to 100 engineer
hours in redo tests and investigating and addressing the break after the
fact.
We shouldn't let this happen in the first place. I think this is our faul
Excerpts from Jim Rollenhagen's message of 2015-12-16 08:03:22 -0800:
> Nobody is talking about running a compute per flavor or capability. All
> compute hosts will be able to handle all ironic nodes. We *do* still
> need to figure out how to handle availability zones or host aggregates,
> but I ex
Are the gateway nodes virtualized? If so, are you allowing promiscuous mode /
MAC spoofing?
> On Dec 16, 2015, at 4:19 AM, Li Ma wrote:
>
> Updated:
>
> Lots of ARP requests from external physical router to VM are catched
> on the physical NIC binded to provider router port.
>
> It seems that
Mike,
I for one whole heartedly thank you for everything you do including extra nova
review in this case.
-- dims
> On Dec 16, 2015, at 12:04 PM, Mike Bayer wrote:
>
>
>
>> On 12/16/2015 11:53 AM, Sean Dague wrote:
>>> On 12/16/2015 11:37 AM, Sean Dague wrote:
On 12/16/2015 11:22 AM,
>>> I cannot ping from VM to external gateway IP (which is set up at the
>>> physical router side).
This is a known issue. We have it in the backlog to fix but noone has
gotten to it yet.
-Ivan
__
OpenStack Development Mailin
Excerpts from Pavlo Shchelokovskyy's message of 2015-12-16 07:59:42 -0800:
> Hi all,
>
> I'd like to start discussion on how Ironic is using Neutron when Keystone
> is involved.
>
> Recently the patch [0] was merged in Ironic to fix a bug when the token
> with which to create the neutronclient is
[adding openstack-dev mailing list for public discussion]
Hi Andy,
I was wondering if you would be interested to move puppet-rally [1] to
OpenStack?
We have some documentation about the process [2] but feel free to ping
us on IRC #puppet-openstack or by this thread if you're interested to
contrib
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hey everyone!
I just released 2.2.0[1] of the kitchen-openstack driver. If your
curious the CHANGELOG is located here[2].
We're doing great work with kitchen-openstack, and would love to see
some more feedback on things the community would support
I just noticed we have a second module written by Cody:
https://github.com/ody/puppet-rally
We might want to collaborate on that.
On 12/16/2015 02:03 PM, Emilien Macchi wrote:
> [adding openstack-dev mailing list for public discussion]
>
> Hi Andy,
>
> I was wondering if you would be interested
On Fri, 2015-12-04 at 08:46 -0500, Sean Dague wrote:
> On 12/04/2015 08:34 AM, Daniel P. Berrange wrote:
> > On Fri, Dec 04, 2015 at 07:43:41AM -0500, Sean Dague wrote:
> > > That seems weird enough that I'd rather push back on our Platinum
> > > Board
> > > member to fix the licensing before we le
I'm not entirely sure what the geo distribution is for everyone that
works on stable, but I know we have people in Europe and some people in
Australia. So I was thinking alternating weekly meetings:
Mondays at 2100 UTC
Tuesdays at 1500 UTC
Does that at least sort of work for people that woul
Hi
Although I agree that it should be done, the removal of Docker doesn't seem
an urgent feature to me. It is not blocking anything besides moving to full
package-based deployment of Fuel, as far as I understand. So it could be
easily delayed for one milestone, especially if it is already almost d
On Wed, Dec 16, 2015 at 01:12:13PM -0600, Matt Riedemann wrote:
> I'm not entirely sure what the geo distribution is for everyone that works
> on stable, but I know we have people in Europe and some people in Australia.
> So I was thinking alternating weekly meetings:
>
> Mondays at 2100 UTC
>
>
On Wed, Dec 16 2015, Carl Baldwin wrote:
> We need to vet new package releases before they wreak havoc. We need
> to accept new package releases by proposing a patch to update the
> version and take it through the gate. Weren't we working on this at
> one point? I understand if it isn't quite p
Assaf,
We can as well add Rally testing for scale/performance/regression testing.
Best regards,
Boris Pavlovic
On Wed, Dec 16, 2015 at 7:00 AM, Fawad Khaliq wrote:
> Very useful information. Thanks, Assaf.
>
> Fawad Khaliq
>
>
> On Thu, Dec 10, 2015 at 6:26 AM, Assaf Muller wrote:
>
>> Today
Brant,
I am ok either way, guess the alternative was to add keystone-core
directly to the oslo.policy core group (can't check right now).
The name is very possibly going to create confusion
-- Dims
On Wed, Dec 16, 2015 at 7:22 PM, Jordan Pittier
wrote:
> Hi,
> I am sure oslo.policy would be go
On Wed, Dec 16, 2015 at 12:20 PM Li Ma wrote:
> Updated:
>
> Lots of ARP requests from external physical router to VM are catched
> on the physical NIC binded to provider router port.
>
> It seems that external physical router doesn't get answers to these
> ARP requests.
>
Just in case, could yo
Emilien Macchi wrote:
> I just noticed we have a second module written by Cody:
> https://github.com/ody/puppet-rally
>
> We might want to collaborate on that.
>
Yeah...I'd actually completely forgotten that existed until Emilien
mentioned it to me in IRC.
It was my responsibility to deploy ral
Hey everybody!
The naming polls for N and O have started. You should have received an
email for each of them. They'll be open until the end of Dec 22 UTC.
Once there are presumptive winners in each, please remember that we will
then have the names vetted by the OpenStack Foundation's lawyers,
> -Original Message-
> From: Clint Byrum [mailto:[email protected]]
> Sent: 15 December 2015 22:40
> To: openstack-dev
> Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum
> Resources
>
> Hi! Can I offer a counter point?
>
> Quotas are for _real_ resources.
>
The CERN cont
Hi stackers,
In ceilometer, some metrics(e.g. network.incoming.bytes for VM net interface,
hardware.network.incoming.bytes for host net interface,
compute.node.cpu.percentage for nova compute node host cpu utilization, etc.)
don't have their resource_id in UUID format(which is required by gnocc
We are skipping the next two weekly meetings,
- Dec 22
- Dec 29
We will reconvene Jan 5th at our usual 1700 UTC slot.
BTW, though we skipping these meetings, tacker core team is available to
continue to review and merge patchsets over next two weeks, so keep them
coming!
- Sridhar
___
Food for thought - there is a cost to FIPs (in the case of public IP
addresses), security groups (to a lesser extent, but in terms of the
computation of many hundreds of them), etc. Administrators may wish to enforce
quotas on a variety of resources that are direct costs or indirect costs (e.g.
On Wed, 16 Dec 2015, Lu, Lianhao wrote:
In ceilometer, some metrics(e.g. network.incoming.bytes for VM net
interface, hardware.network.incoming.bytes for host net interface,
compute.node.cpu.percentage for nova compute node host cpu
utilization, etc.) don't have their resource_id in UUID format(
On Wed, Dec 16, 2015 at 2:32 PM, Boris Pavlovic wrote:
> Assaf,
>
> We can as well add Rally testing for scale/performance/regression testing.
There's mention of it in the doc but not the rationale of using it like for the
other testing frameworks. I'd appreciate it if a Rally dev could send the
Greetings! Our next OpenStack Community App Catalog meeting will take
place this ThursdayDecember 17th at 17:00 UTC in #openstack-meeting-3
The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog
Please add agenda items if there's anything specific you would like to
dis
1 - 100 of 176 matches
Mail list logo
