Team,
I have published a top level blueprint for a magnum-horizon-plugin:
https://blueprints.launchpad.net/magnum/+spec/magnum-horizon-plugin
My suggestion is that any contributor interested in contributing to this
feature should subscribe to that blueprint, and record their intent to
You have better chances of getting an answer if you asked the -dev list and
add [Neutron] to the subject (done here).
That said, can you tell us a bit more about your deployment? You can also
hop on #openstack-neutron on Freenode to look for neutron developers who
can help you more interactively.
On 4 June 2015 at 14:17, Cathy Zhang cathy.h.zh...@huawei.com wrote:
Thanks for joining the service chaining meeting today! Sorry for the
time confusion. We will correct the weekly meeting time to 1700UTC (10am
pacific time) Thursday #openstack-meeting-4 on the OpenStack meeting
page.
Same here, I’m interested in helping out with reviews from Horizon standpoint.
Regards
Zhenguo Niu
From: David Lyle [mailto:dkly...@gmail.com]
Sent: Friday, June 05, 2015 3:42 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][horizon]
I have filed a bp for this
https://blueprints.launchpad.net/magnum/+spec/auto-generate-name Thanks
2015-06-04 14:14 GMT+08:00 Jay Lau jay.lau@gmail.com:
Thanks Adrian, I see. Clear now.
2015-06-04 11:17 GMT+08:00 Adrian Otto adrian.o...@rackspace.com:
Jay,
On Jun 3, 2015, at 6:42 PM,
On Jun 4, 2015, at 11:03 AM, Devananda van der Veen
devananda@gmail.commailto:devananda@gmail.com wrote:
On Jun 4, 2015 12:00 AM, Xu, Hejie
hejie...@intel.commailto:hejie...@intel.com wrote:
Hi, guys,
I’m working on adding Microversion into the API-WG’s guideline which make
sure
Hi Cathy,
Thanks for heading up this meeting. No worries about the timing, time zones
are really difficult to handle ;)
I do agree with Armando that finalization of the API is important and must
be done at the earliest. As discussed over the last meeting I will start
working on this and hope by
Hello folks,
Regarding option C, if group IDs are unique within a given cloud/context, and
these are discoverable by clients that can then set the ACL on a secret in
Barbican, then that seems like a viable option to me. As it is now, the user
information provided to the ACL is the user ID
On 06/04/2015 07:16 PM, Joshua Harlow wrote:
Perhaps someone needs to use (or forgot to use) contextlib.closing?
https://docs.python.org/2/library/contextlib.html#contextlib.closing
Or contextlib2 also may be useful:
http://contextlib2.readthedocs.org/en/latest/#contextlib2.ExitStack
The
Thanks Jay. I have approved the direction for this, and have marked it as under
discussion. I also added it to our next team meeting agenda so we can consider
any alternate viewpoints before approving the specification as worded.
Adrian
On Jun 4, 2015, at 9:12 PM, Jay Lau
As we could generate data dynamically, it is possible to develop a web UI
for it which shows real-time and readable scheduler table, provides
download link of custom meetings group, etc.
On Sat, May 30, 2015 at 2:51 PM yatin kumbhare yatinkumbh...@gmail.com
wrote:
Thank you, Thierry Tony
- Original Message -
From: Adam Young ayo...@redhat.com
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Sent: Thursday, 4 June, 2015 2:25:52 PM
Subject: [openstack-dev] [Keystone] Domain and Project naming
With Hierarchical Multitenantcy, we have the issue
On 06/04/2015 05:23 PM, Zane Bitter wrote:
Ever since we established[1] a format for including metadata about bugs in Git
commit messages that included a 'Partial-Bug' tag, people have been looking for
a way to do the equivalent for partial blueprint implementations.
snip
I have personally
On Fri, Jun 05, 2015 at 01:18:57AM +, Gareth wrote:
As we could generate data dynamically, it is possible to develop a web UI
for it which shows real-time and readable scheduler table, provides
download link of custom meetings group, etc.
Sure I'm working on the second part (albeit
Thanks folks, Its fixed via https://bugs.launchpad.net/mos/+bug/1409661 :-0
2015-06-04 20:29 GMT+08:00 张扬 w90p...@gmail.com:
Hi Guys,
I am a newbie on openstack, I deployed my first openstack env via Fuel
6.0, but unfortunately I always could not access the vm's vnc console, it
hints the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
With our Kilo branch now cut, we're running headlong into the Liberty
development cycle! And don't forget to have your say on what the M
release should be called:
https://wiki.openstack.org/wiki/Release_Naming/M_Proposals
If you have
On Wed, Jun 3, 2015 at 11:25 PM, Adam Young ayo...@redhat.com wrote:
With Hierarchical Multitenantcy, we have the issue that a project is
currentl restricted in its naming further than it should be. The domain
entity enforces that all project namess under the domain domain be unique,
but
On 4 June 2015 at 19:32, Vikram Choudhary viks...@gmail.com wrote:
Hi Cathy,
Thanks for heading up this meeting. No worries about the timing, time
zones are really difficult to handle ;)
I do agree with Armando that finalization of the API is important and must
be done at the earliest. As
Perhaps someone needs to use (or forgot to use) contextlib.closing?
https://docs.python.org/2/library/contextlib.html#contextlib.closing
Or contextlib2 also may be useful:
http://contextlib2.readthedocs.org/en/latest/#contextlib2.ExitStack
-Josh
Chris Friesen wrote:
On 06/04/2015 03:01 AM,
On 06/04/2015 05:49 PM, Morgan Fainberg wrote:
Hi Everyone!
I've been reading through this thread and have had some conversations
along the side and wanted to jump in to distill out what I think are
the key points we are trying to address here. I'm going to outline
about 4 items that seem to
I think this is perfectly fine, as long as it's reasonably large and
the algorithm is sufficiently intelligent. The UUID algorithm is good at
this, for instance, although it fails at readability. Docker's is not
terribly great and could be limiting if you were looking to run several
Hongbin,
I hadn’t thought of that, even though it seems obvious ;) We can absolutely do
that. I almost like this option better then #1 but I don’t want the ui folks
to feel like second class citizens. This goes back to the trust the ui
developers to not review things they know not about :)
Thanks for joining the service chaining meeting today! Sorry for the time
confusion. We will correct the weekly meeting time to 1700UTC (10am pacific
time) Thursday #openstack-meeting-4 on the OpenStack meeting page.
Meeting Minutes:
Hey everyone!
I have cut a new release of the knife-openstack[1] gem today. We have a couple
new features[2] which has been asked for a while.
If you would like to give it a shot and report back any issues you might
find[3].
gem install knife-openstack --pre
I’m hoping to give this a week or
The API working group has three new guidelines that are entering the 1
week freeze period. We would like to ask all PTLs and CPLs, and other
interested parties, to take a look at these reviews. We will use lazy
consensus at the end of the freeze to merge them if there are no objections.
Hello everyone,
The Keystone patch passed staging tests, we are now building the ISO
with this patch and other merged fixes. Test results for this ISO will
be available tonight/early morning tomorrow PDT. If they are good, this
will be our RC. So, our plan to declare HCF tomorrow
On Jun 4, 2015 11:11 AM, Chris Friesen chris.frie...@windriver.com
wrote:
On 06/04/2015 10:14 AM, Devananda van der Veen wrote:
On Jun 4, 2015 8:57 AM, Monty Taylor mord...@inaugust.com
So, seriously - let's grow up and start telling people that they do
not
get to pick and choose
Hi Everyone!
I've been reading through this thread and have had some conversations along
the side and wanted to jump in to distill out what I think are the key
points we are trying to address here. I'm going to outline about 4 items
that seem to make sense to me regarding the evolution of policy.
I will get a spec out for review by end of day tomorrow.
Thanks,
Brad Jones
On 4 Jun 2015, at 22:30, Adrian Otto
adrian.o...@rackspace.commailto:adrian.o...@rackspace.com wrote:
Team,
I have published a top level blueprint for a magnum-horizon-plugin:
Problem! In writing a spec for this (
https://review.openstack.org/#/c/188564/ ), I remembered that groups are
domain-specific entities, which complicates the problem of providing
X-Group-Names via middleware.
The problem is that we can't simply expose X-Group-Names to underlying
services without
Hi,
After trying to reproduce this, I'm suspecting that the issue is actually
on the server side from failing to drain the agent report state queue in
time.
I have seen before.
I thought the senario at that time as follows.
* a lot of create/update resource API issued
* rpc_conn_pool_size
On Thu, Jun 4, 2015 at 3:20 PM, Kevin Benton blak...@gmail.com wrote:
After trying to reproduce this, I'm suspecting that the issue is actually on
the server side from failing to drain the agent report state queue in time.
I set the report_interval to 1 second on the agent and added a logging
On Wed, Jun 03, 2015 at 04:30:17PM -0400, Sean Dague wrote:
The closer we can get logic about what a service should look like on
disk back into that service itself, the less work duplicated by any of
the installers, and the more common OpenStack envs would be. The fact
that every installer /
Sounds like the community would like CI's regardless, and I agree.
Just because the driver code works for one backend solution, doesn't
mean it's going to work with some other.
Lets continue with code reviews with these patches only if they have a
CI reporting, unless someone has a compelling
Agreed, I'd also like to mention that rebranded arrays may differ slightly
in functionality as well so the CIs would need to run against a physical
rebranded device. These differences also justify the need for letting
rebranded drivers in.
-Alex
On Thu, Jun 4, 2015 at 4:41 PM, Mike Perez
Jason,
I will definitely weigh all feedback on this. I’m interested in guidance from
anyone taking an interest in this subject.
Thanks,
Adrian
On Jun 4, 2015, at 1:55 PM, Jason Rist jr...@redhat.com wrote:
On 06/04/2015 11:58 AM, Steven Dake (stdake) wrote:
Hey folks,
I think it is
After trying to reproduce this, I'm suspecting that the issue is actually
on the server side from failing to drain the agent report state queue in
time.
I set the report_interval to 1 second on the agent and added a logging
statement and I see a report every 1 second even when sync_routers is
Ever since we established[1] a format for including metadata about bugs
in Git commit messages that included a 'Partial-Bug' tag, people have
been looking for a way to do the equivalent for partial blueprint
implementations. A non-exhaustive search of a small number of projects
reveals at
Thanks for the details Brad! I would also be interested in helping out with
the work.
From: Bradley Jones (bradjone) bradj...@cisco.commailto:bradj...@cisco.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
Steve,
Thanks for raising this. I am definitely looking forward to a UI effort for
Magnum, and will be happy to decide based on community input about how best to
organize this. I’d also like direct input from those contributors who plan to
work on this to take those individual preferences into
Hi Clint,
Thanks for your contribution to this thread.
On 06/04/2015 10:35 PM, Clint Adams wrote:
On Wed, Jun 03, 2015 at 04:30:17PM -0400, Sean Dague wrote:
The closer we can get logic about what a service should look like on
disk back into that service itself, the less work duplicated by
From a quick look around there doesn’t seem to be a consensus on how to deal
with UI teams, some projects seem to use just the main projects core team
(group based policy ui), others use a mix of the project core team and the
Horizon core team (monasca-ui) and in the case of tuskar-ui they use
In Juno I tried adding a user in Domain A to group in Domain B. That currently
is not supported. Would be very handy though.
We're getting a ways from the original part of the thread, so I may have lost
some context, but I think the original question was, if barbarian can add group
names to
I doubt it's a server side issue.
Usually there are plenty of rpc workers to drain much higher amount of rpc
messages going from agents.
So the issue could be in 'fairness' on L3 agent side. But from my
observations it was more an issue of DHCP agent than L3 agent due to
difference in resource
Since the meeting was closed prior to having a discussion for this topic, I
will post my notes here as well.
I will start updating some of the BP's that have landed in 6.1 to reflect
their current status
There are a number of specs open for BP's that have code landed. We will
merge the current
On 06/04/2015 01:03 PM, Adam Young wrote:
On 06/04/2015 09:40 AM, Sean Dague wrote:
So I feel like I understand the high level dynamic policy end game. I
feel like what I'm proposing for policy engine with encoded defaults
doesn't negatively impact that. I feel there is a middle chunk where
I’m really keen to take on this effort, to echo what Steve said I think adding
a dashboard component to Magnum is critical in adoption and delivering good
usability to all.
Thanks,
Brad Jones
On 4 Jun 2015, at 18:58, Steven Dake (stdake)
std...@cisco.commailto:std...@cisco.com wrote:
Hey
I am confused about the goal. Are we saying we should allow operators to modify
the access policies but then warn them if they do? But if operators *intend* to
modify the policies in order to fit their compliance/security needs, which is
likely the case, aren't the warning messages confusing
Hey folks,
I think it is critical for self-service needs that we have a Horizon dashboard
to represent Magnum. I know the entire Magnum team has no experience in UI
development, but I have found atleast one volunteer Bradley Jones to tackle the
work.
I am looking for more volunteers to
I am interested but not sure how much time I have this release cycle. I can take on a more hands-off approach and help review to make sure that magnum-ui is align with future horizon directions.-"Steven Dake (stdake)" std...@cisco.com wrote: -To: "OpenStack Development Mailing List (not
+1 to single team
-- dims
On Thu, Jun 4, 2015 at 2:02 PM, Steven Dake (stdake) std...@cisco.com wrote:
My vote is +1 for a unified core team for all Magnum development which in
the future will include the magnum-ui repo, the python-magnumclient repo,
the magnum repo, and the python-k8sclient
Same here. I’m definitely interested in helping out but not sure how much time
I can commit to. Will most definitely help out with reviews and other decision
making process to help ensure magnum-ui is implemented and in the correct
direction relating to Horizon.
From: Thai Q Tran
On 06/04/2015 03:01 AM, Flavio Percoco wrote:
On 03/06/15 16:46 -0600, Chris Friesen wrote:
We recently ran into an issue where nova couldn't write an image file due to
lack of space and so just quit reading from glance.
This caused glance to be stuck with an open file descriptor, which meant
Hi folks,I know a lot of people are tackling the JSCS stuff, and thats really great. But it would be extra nice to see JSCS stuff along with JP's guidelines in your patches. Furthermore, if the file you are working on doesn't have an accompanying spec file, please make sure that the tests for it
- Original Message -
One reason for not sending the heartbeat from a separate greenthread could be
that the agent is already doing it [1].
The current proposed patch addresses the issue blindly - that is to say
before declaring an agent dead let's wait for some more time because it
My vote is +1 for a unified core team for all Magnum development which in the
future will include the magnum-ui repo, the python-magnumclient repo, the
magnum repo, and the python-k8sclient repo.
Regards
-steve
From: Steven Dake std...@cisco.commailto:std...@cisco.com
Reply-To: OpenStack
On 06/04/2015 10:14 AM, Devananda van der Veen wrote:
On Jun 4, 2015 8:57 AM, Monty Taylor mord...@inaugust.com
So, seriously - let's grow up and start telling people that they do not
get to pick and choose user-visible feature sets. If they have an unholy
obsession with a particular
On 06/03/2015 02:53 PM, Eric Harney wrote:
On 06/03/2015 01:59 PM, John Griffith wrote:
On Wed, Jun 3, 2015 at 11:32 AM, Mike Perez thin...@gmail.com wrote:
There are a couple of cases [1][2] I'm seeing where new Cinder volume
drivers for Liberty are rebranding other volume drivers. This
Could we have a new group magnum-ui-core and include magnum-core as a subgroup,
like the heat-coe-tempalte-core group.
Thanks,
Hongbin
From: Steven Dake (stdake) [mailto:std...@cisco.com]
Sent: June-04-15 1:58 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject:
undefined
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
undefined
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi all,
Does any one know which middleware does Openstack use to authenticate users
in Keystone in Kilo release? I saw two middleware, one is in Keystone
client, the other is an independent directory. I know the previous version,
the middleware in keystone client is used, but in Kilo, I am not
Is there a way to parallelize the period tasks? I wanted to go this route
because I encountered cases where a bunch of routers would get scheduled to
l3 agents and they would all hit the server nearly simultaneously with a
sync routers task.
This could result in thousands of routers and their
Summary - In puppet module spec tests, do not use stubs, which means
the method will be called 0 or more times. Instead, use expects,
which means the method must be called exactly 1 time, or some other more
fine grained expectation method stubber.
Our puppet unit tests mostly use rspec, but
We can do the opposite to avoid more and more ACLs:
ALLOW push on some specific stable branches
[access refs/heads/stable/kilo]
push = allow group ***-stable-maint
[access refs/heads/stable/juno]
push = allow group ***-stable-maint
BLOCK push on others stable branches
[access
On 06/04/2015 09:40 AM, Sean Dague wrote:
So I feel like I understand the high level dynamic policy end game. I
feel like what I'm proposing for policy engine with encoded defaults
doesn't negatively impact that. I feel there is a middle chunk where
perhaps we've got different concerns or
Congrats! Well deserved
On Thu, Jun 4, 2015 at 8:50 AM, Assaf Muller amul...@redhat.com wrote:
Thank you.
We have a lot of work ahead of us :)
- Original Message -
It's a been a week since I proposed this, with no objections. Welcome to
the
Neutron core reviewer team as the
On 06/04/2015 11:27 AM, Dmitry Tantsur wrote:
On 06/04/2015 05:03 PM, Sean Dague wrote:
On 06/04/2015 10:50 AM, Dmitry Tantsur wrote:
On 06/04/2015 04:40 PM, Ruby Loo wrote:
Hi,
In Kilo, we introduced microversions but it seems to be a
work-in-progress. There is an effort now to add
Congrats Assaf ;)
On Thu, Jun 4, 2015 at 9:35 PM, Somanchi Trinath
trinath.soman...@freescale.com wrote:
Congratulations Assaf J
*From:* Jaume Devesa [mailto:devv...@gmail.com]
*Sent:* Thursday, June 04, 2015 9:25 PM
*To:* OpenStack Development Mailing List (not for usage questions)
Hi,
It was nice to meet many of you at the Vancouver Infra Working Session. Quite a
bit of progress was made finding owners for some of the common-ci refactoring
work [1] and puppet testing work. A few patches were proposed, reviewed, and
some merged!
As we continue the effort over the coming
On 06/04/2015 09:40 AM, Sean Dague wrote:
Is there some secret dragon I'm missing here?
No. But it is a significant bit of coding to do; you would need to
crawl every API and make sure you hit every code path that could enforce
policy.
Um, I don't understand that.
I'm saying that you'd
Hi Gosha,
Sorry, not sure why my last message was delivered as undefined.
Anyways, thanks for pointing me to those materials.
I have a feeling though that due to the nature of Heat-Translator we would need
to deal with HOT based templates and not MuranoPL.
Regards,
undefined
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 06/04/2015 11:27 AM, Dmitry Tantsur wrote:
On 06/04/2015 05:03 PM, Sean Dague wrote:
On 06/04/2015 10:50 AM, Dmitry Tantsur wrote:
On 06/04/2015 04:40 PM, Ruby Loo wrote:
Hi,
In Kilo, we introduced microversions but it seems to be a
work-in-progress. There is an effort now to add
Congratulations Assaf ☺
From: Jaume Devesa [mailto:devv...@gmail.com]
Sent: Thursday, June 04, 2015 9:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Proposing Assaf Muller for the Neutron
Core Reviewer Team
Congratulations Assaf!!
You are referring to keystonemiddleware (
https://github.com/openstack/keystonemiddleware) - the Keystone team
switched over many OpenStack services to use this new library in Kilo. It
was originally a copy of the code in keystoneclient, the driving factor
for the change was to decouple the
+100 Great addition! Congratulations Assaf!
On Thu, Jun 4, 2015 at 11:41 AM Miguel Lavalle mig...@mlavalle.com wrote:
Congrats! Well deserved
On Thu, Jun 4, 2015 at 8:50 AM, Assaf Muller amul...@redhat.com wrote:
Thank you.
We have a lot of work ahead of us :)
- Original Message
The problem is in your test case. There is no such methods as
remotefs.db.snapshot_get or remotefs.db.snapshot_admin_metadata_get.
You need to use with mock.patch('cinder.db.snapshot_get') as snapshot_get,
mock.patch('cinder.db.snapshot_admin_metadata_get')
as snapshot_admin_metadata_get. These
On Jun 4, 2015 12:00 AM, Xu, Hejie hejie...@intel.com wrote:
Hi, guys,
I’m working on adding Microversion into the API-WG’s guideline which make
sure we have consistent Microversion behavior in the API for user.
The Nova and Ironic already have Microversion implementation, and as I
know
Inline.
On Thu, Jun 4, 2015 at 6:40 AM, Sean Dague s...@dague.net wrote:
On 06/04/2015 08:52 AM, Adam Young wrote:
On 06/04/2015 06:32 AM, Sean Dague wrote:
On 06/03/2015 08:40 PM, Tim Hinrichs wrote:
As long as there's some way to get the *declarative* policy from the
system (as a data
Hi Serg,Sorry, I seem to be having issues sending messages to the mailing list.Thanks for your message. I can work on the blueprint spec. Just trying to get a good picture of related Murano processes and where the connection points to Heat-Translator should be.And I agreed with your comment on
undefined
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Congratulations Assaf!!
On 4 June 2015 at 17:45, Paul Michali p...@michali.net wrote:
+100 Great addition! Congratulations Assaf!
On Thu, Jun 4, 2015 at 11:41 AM Miguel Lavalle mig...@mlavalle.com
wrote:
Congrats! Well deserved
On Thu, Jun 4, 2015 at 8:50 AM, Assaf Muller
Hi Serg,
Sorry, I seem to be having issues sending messages to the mailing list.
Thanks for your message. I can work on the blueprint spec. Just trying to get a
good picture of related Murano processes and where the connection points to
Heat-Translator should be.
And I agreed with your comment
On 06/04/2015 05:43 PM, Sean Dague wrote:
On 06/04/2015 11:27 AM, Dmitry Tantsur wrote:
On 06/04/2015 05:03 PM, Sean Dague wrote:
On 06/04/2015 10:50 AM, Dmitry Tantsur wrote:
On 06/04/2015 04:40 PM, Ruby Loo wrote:
Hi,
In Kilo, we introduced microversions but it seems to be a
On Jun 4, 2015 8:57 AM, Monty Taylor mord...@inaugust.com wrote:
On 06/04/2015 11:27 AM, Dmitry Tantsur wrote:
On 06/04/2015 05:03 PM, Sean Dague wrote:
On 06/04/2015 10:50 AM, Dmitry Tantsur wrote:
On 06/04/2015 04:40 PM, Ruby Loo wrote:
Hi,
In Kilo, we introduced microversions but
On 2015-06-04 16:23:12 +0200 (+0200), Ihar Hrachyshka wrote:
Why do we even drop stable branches? If anything, it introduces
unneeded problems to those who have their scripts/cookbooks set to
chase those branches. They would need to switch to eol tag. Why not
just leaving them sitting there,
So we should have told the folks to so developing agent? (Not sure why you
all think I'm talking about us) Maybe.
But anyway anyone deliberately ignores my points, so I'm done with this
discussion.
04 июня 2015 г. 18:17 пользователь Devananda van der Veen
devananda@gmail.com написал:
On
On 06/04/2015 12:12 PM, Tim Hinrichs wrote:
Inline.
On Thu, Jun 4, 2015 at 6:40 AM, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:
On 06/04/2015 08:52 AM, Adam Young wrote:
On 06/04/2015 06:32 AM, Sean Dague wrote:
On 06/03/2015 08:40 PM, Tim Hinrichs wrote:
+1. I had setup a CI for a third-party plugin and the easiest thing to do
to make sure it was running tests with the latest copy of the corresponding
neutron branch was to put the git URL in requirements.txt.
We wanted to always test the latest code so we had early detection of
failures. What's
On Jun 4, 2015 5:53 AM, Dmitry Tantsur dtant...@redhat.com wrote:
Hi!
While working on the enroll spec [1], I got a thinking: within the new
state machine, when should we allow to change a node driver?
My initial idea was to only allow driver change in ENROLL. Which sounds
good to me, but
argh
BLOCK push on others stable branches
[access refs/heads/stable/*]
push = block group Anonymous Users
On Thu, Jun 4, 2015 at 6:34 PM, ZZelle zze...@gmail.com wrote:
We can do the opposite to avoid more and more ACLs:
ALLOW push on some specific stable branches
[access
Hi,
In Kilo, we introduced microversions but it seems to be a work-in-progress.
There is an effort now to add microversion into the API-WG's guidelines, to
provide a consistent way of using microversions across OpenStack projects
[1]. Specifically, in the context of this email, there is a
One reason for not sending the heartbeat from a separate greenthread could
be that the agent is already doing it [1].
The current proposed patch addresses the issue blindly - that is to say
before declaring an agent dead let's wait for some more time because it
could be stuck doing stuff. In that
First I have some questions: if we are going to add a delimiter, how can we
handle OpenStack API Stability guidelines [1]? If we add this delimiter in
keystone.conf (and having the default value being . or /), do we fall
into the same API stability problems?
Personally, I'm in favor of having a
On 4 June 2015 at 02:58, Xu, Hejie hejie...@intel.com wrote:
...
And another guideline for when we should bump Mircoversion
*https://review.openstack.org/#/c/187896/*
https://review.openstack.org/#/c/187896/
This is timely because just this very minute I was going to send out email
to the
On 06/04/2015 04:40 PM, Ruby Loo wrote:
Hi,
In Kilo, we introduced microversions but it seems to be a
work-in-progress. There is an effort now to add microversion into the
API-WG's guidelines, to provide a consistent way of using microversions
across OpenStack projects [1]. Specifically, in the
On 4 June 2015 at 09:29, Dmitry Tantsur dtant...@redhat.com wrote:
On the summit we were discussing things like chassis discovery, and arrived
at rough conclusion that we want it to be somewhere in a separate repo.
More precisely, we wanted some place for vendor to contribute code (aka
On 06/04/2015 05:03 PM, Sean Dague wrote:
On 06/04/2015 10:50 AM, Dmitry Tantsur wrote:
On 06/04/2015 04:40 PM, Ruby Loo wrote:
Hi,
In Kilo, we introduced microversions but it seems to be a
work-in-progress. There is an effort now to add microversion into the
API-WG's guidelines, to provide a
Hi Ruby,
Thanks for starting this thread, just like you I've been always
confused about when and when not bump the microversioning of the API.
Backwards compatible API adds with no user signaling is a fallacy
because it assumes the arrow of time flows only one way.
If at version 1.5 you have
1 - 100 of 170 matches
Mail list logo
