Dear PTLs, cross-project liaisons and anyone else interested,
We'll have a cross-project meeting Tuesday at 21:00 UTC, with the
following agenda:
* Convergence on specs process (johnthetubaguy)
* Approval process differences
* Path structure differences
* specs.o.o aspect differences (toc)
Hey,
I think it’s a question of what the final goal is. For just creating security
groups as a resource I think Georgy and Zane are right, just use Heat. If the
goal is to try Mistral or have this simple workflow as part of more complex
then it’s totally fine to use Mistral. Sorry, I’m probably
No problem, let us know if you have any other questions.
Renat Akhmerov
@ Mirantis Inc.
> On 09 Dec 2014, at 11:57, Sushma Korati wrote:
>
>
> Hi,
>
> Thank you guys.
>
> Yes I am able to do this with heat, but I faced issues while trying the same
> with mistral.
> As suggested will try w
Ok, got it.
So my general suggestion here is: let's keep it as simple as possible for now,
create something that works and then let’s see how to improve it. And yes,
consumers may be and mostly will be 3rd parties.
Thanks
Renat Akhmerov
@ Mirantis Inc.
> On 09 Dec 2014, at 08:25, W Chan wr
Hi Winson,
I think it makes perfect sense. The reason I think is mostly historical and
this can be reviewed now. Can you pls file a BP and describe your suggested
design on that? I mean how we need to alter interface Action etc.
Thanks
Renat Akhmerov
@ Mirantis Inc.
> On 09 Dec 2014, at 13:
Hi,
If time is available, how about adding one agenda to guide the direction for
cascading to move forward? Thanks in advance.
The topic is : " Need cross-program decision to run cascading as an incubated
project mode or register BP separately in each involved project. CI for
cascading is qui
No to questions 1, 3, and 4. Yes to 2, but very minimally.
From: xianchaobo
Sent: Monday, December 08, 2014 10:29:50 PM
To: openstack-dev@lists.openstack.org
Cc: Luohao (brian)
Subject: [openstack-dev] [Ironic] Some questions about Ironic service
Hello, all
I’m t
Hi there.
I would like some clarification regarding support of out-of-tree
plugin in nova and in neutron.
First, on neutron side, there are mechanisms to support out-of-tree
plugin for L2 plugin (core_plugin) and ML2 mech driver
(stevedore/entrypoint).
Most of ML2/L2 plugins need to have a speci
You probably want to use the agent driver, not the pxe one. It lets you use
bootloaders from the image.
From: Peeyush Gupta
Sent: Monday, December 08, 2014 10:55:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Ironi
It is true that IPA and FuelAgent share a lot of functionality in common.
However there is a major difference between them which is that they are
intended to be used to solve a different problem.
IPA is a solution for provision-use-destroy-use_by_different_user use-case and
is really great for
So, basically if I am using pxe driver, I would "have to" provide
pxelinux.0?
On 12/09/2014 03:24 PM, Fox, Kevin M wrote:
> You probably want to use the agent driver, not the pxe one. It lets you use
> bootloaders from the image.
>
>
> From: Peeyush Gupta
> Sent:
joehuang wrote:
> If time is available, how about adding one agenda to guide the direction for
> cascading to move forward? Thanks in advance.
>
> The topic is : " Need cross-program decision to run cascading as an incubated
> project mode or register BP separately in each involved project. CI f
Hi all!
It would be great if you could use this thread to post hot reviews on stuff
that it’s being worked out during the mid-cycle, where others from different
timezones could participate.
I know posting reviews to the list is not permitted, but I think an exception
in this case would
Sorry for the late reply, just few thoughts on the matter.
IMO the REST middleware should be as thin as possible. And I mean thin in
terms of processing - it should not do pre/post processing of the requests,
but just unpack/pack. So here is an example:
instead of making AJAX calls that contain i
Sometimes, I want to ask the author of a patch about it on IRC.
However, there doesn't seem to be a reliable way to find out someone's
IRC handle. The potential for useful conversation is sometimes
missed. Unless there's a better alternative which I didn't find,
https://wiki.openstack.org/wiki/Pe
On Tue, 2014-12-09 at 10:46 +, Matthew Gilliard wrote:
> can we autogenerate it somehow?
Maybe some 'irc_nick' field in Stackalytic's default_data.json could be
added and used to populate such page?
Nicolas
___
OpenStack-dev mailing list
OpenStack
Hi Eduard,
I would check the trigger settings in the job, particularly which "type"
of pattern matching is being used for the branches. Found it tends to be
the spot that catches most people out when configuring jobs with the
Gerrit Trigger plugin. If you're looking to trigger against all branche
I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
1 - the entire H8* group. This doesn't function on python code, it
functions on git commit message, which makes it tough to run locally. It
also would be a reason to prevent us from not rerunning tests on commit
message c
Hi Darragh, thanks for your input
I double checked the job settings and fixed it:
- build triggers is set to Gerrit event
- Gerrit trigger server is "Gerrit" (configured from Gerrit Trigger Plugin
and tested separately)
- Trigger on: Patchset Created
- Gerrit Project: Type: Path, Pattern openstack
Hello API WG,
It is nice to see such warm welcoming!
We have started using the flag in order to join the API WG initiative
and get feedback about our current API and the guidance for future
improvements.
Current API is described at RTD [1] as a text, but structured form is
always better for
Just a short explanation of Fuel use case.
Fuel use case is not a cloud. Fuel is a deployment tool. We install OS on
bare metal servers and on VMs
and then configure this OS using Puppet. We have been using Cobbler as our
OS provisioning tool since the beginning of Fuel.
However, Cobbler assumes u
Good day Ironicers.
I do not want to discuss questions like "Is feature X good for release
Y?" or "Is feature Z in Ironic scope or not?".
I want to get an answer for this: Is Ironic a flexible, easy extendable
and user-oriented solution for deployment?
Yes, it is I think. IPA is the great softw
On Tue, Dec 09, 2014 at 06:39:43AM -0500, Sean Dague wrote:
> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>
> 1 - the entire H8* group. This doesn't function on python code, it
> functions on git commit message, which makes it tough to run locally. It
> also would
Hi folks,
Thank you for additional explanation, it does clarify things a bit. I'd
like to note, however, that you talk a lot about how _different_ Fuel
Agent is from what Ironic does now. I'd like actually to know how well
it's going to fit into what Ironic does (in additional to your specific
On Tue, Dec 09, 2014 at 10:46:12AM +, Matthew Gilliard wrote:
> Sometimes, I want to ask the author of a patch about it on IRC.
> However, there doesn't seem to be a reliable way to find out someone's
> IRC handle. The potential for useful conversation is sometimes
> missed. Unless there's a
Hello, Thierry,
That sounds great.
Best Regards
Chaoyi Huang ( joehuang )
From: Thierry Carrez [thie...@openstack.org]
Sent: 09 December 2014 18:32
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Cross-Project meeting, Tue December 9t
On 12/09/2014 07:32 AM, Sahid Orentino Ferdjaoui wrote:
> On Tue, Dec 09, 2014 at 06:39:43AM -0500, Sean Dague wrote:
>> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>>
>> 1 - the entire H8* group. This doesn't function on python code, it
>> functions on git commit m
On Tue, Dec 09 2014, Sean Dague wrote:
> 1 - the entire H8* group. This doesn't function on python code, it
> functions on git commit message, which makes it tough to run locally. It
> also would be a reason to prevent us from not rerunning tests on commit
> message changes (something we could do
On 2014-12-09 13:58:28 +0100 (+0100), Sahid Orentino Ferdjaoui wrote:
> We probably don't want to maintain an other page of Wiki.
Yes, the wiki is about low-overhead collaborative documentation. It
is not suitable as a database.
> We can recommend in how to contribute to fill correctly the IRC
>
On Tue, Dec 09, 2014 at 10:53:19AM +0100, Maxime Leroy wrote:
> I have also proposed a blueprint to have a new plugin mechanism in
> nova to load external vif driver. (nova-specs:
> https://review.openstack.org/#/c/136827/ and nova (rfc patch):
> https://review.openstack.org/#/c/136857/)
>
> From
On Dec 8, 2014, at 11:25 PM, Li Ma wrote:
> Hi all, I tried to deploy zeromq by devstack and it definitely failed with
> lots of problems, like dependencies, topics, matchmaker setup, etc. I've
> already registered a blueprint for devstack-zeromq [1].
I added the [devstack] tag to the subject
The neutron-drivers team has started the process of both accepting and
rejecting specs for Kilo now. If you've submitted a spec, you will soon see
the spec either approved or land in either the abandoned or -2 category.
We're doing our best to put helpful messages when we do abandon or -2
specs, bu
On Dec 9, 2014, at 6:39 AM, Sean Dague wrote:
> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>
> 1 - the entire H8* group. This doesn't function on python code, it
> functions on git commit message, which makes it tough to run locally. It
> also would be a reason
Winson,
thanks for filing the blueprint:
https://blueprints.launchpad.net/mistral/+spec/mistral-global-context,
some clarification questions:
1) how exactly would the user describe these global variables syntactically? In
DSL? What can we use as syntax? In the initial workflow input?
2) what
Vladimir Kozhukalov
On Tue, Dec 9, 2014 at 3:51 PM, Dmitry Tantsur wrote:
> Hi folks,
>
> Thank you for additional explanation, it does clarify things a bit. I'd
> like to note, however, that you talk a lot about how _different_ Fuel Agent
> is from what Ironic does now. I'd like actually to kno
s/though/throw/g
Vladimir Kozhukalov
On Tue, Dec 9, 2014 at 5:40 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
>
>
> Vladimir Kozhukalov
>
> On Tue, Dec 9, 2014 at 3:51 PM, Dmitry Tantsur
> wrote:
>
>> Hi folks,
>>
>> Thank you for additional explanation, it does clarify things a b
+1 To wiki page.
I also tried to deploy devstack with zmq, and met the same problems
https://bugs.launchpad.net/devstack/+bug/1397999
https://bugs.launchpad.net/oslo.messaging/+bug/1395721
We also have some unimplemented closures in zmq driver:
one of them: https://bugs.launchpad.net/oslo.messa
So regarding to the 3rd-party CI. There is FuelCI that runs tests for some
stackforge projects. Attaching it to Ironic to run required tests that
detect problems in FuelAgent driver is not a big deal at all and will be
done as soon as it's necessary.
On Tue, Dec 9, 2014 at 3:45 PM, Vladimir Kozhuk
On Tue, Dec 09, 2014 at 08:16:34AM -0500, Sean Dague wrote:
> On 12/09/2014 07:32 AM, Sahid Orentino Ferdjaoui wrote:
> > On Tue, Dec 09, 2014 at 06:39:43AM -0500, Sean Dague wrote:
> >> I'd like to propose that for hacking 1.0 we drop 2 groups of rules
> >> entirely.
> >>
> >> 1 - the entire H8*
On 12/09/2014 03:40 PM, Vladimir Kozhukalov wrote:
Vladimir Kozhukalov
On Tue, Dec 9, 2014 at 3:51 PM, Dmitry Tantsur mailto:dtant...@redhat.com>> wrote:
Hi folks,
Thank you for additional explanation, it does clarify things a bit.
I'd like to note, however, that you talk a lot a
On Tue, Dec 09, 2014 at 04:01:07PM +0400, Vladimir Kozhukalov wrote:
> Just a short explanation of Fuel use case.
>
> Fuel use case is not a cloud. Fuel is a deployment tool. We install OS on
> bare metal servers and on VMs
> and then configure this OS using Puppet. We have been using Cobbler as o
On 12/09/2014 09:11 AM, Doug Hellmann wrote:
>
> On Dec 9, 2014, at 6:39 AM, Sean Dague wrote:
>
>> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>>
>> 1 - the entire H8* group. This doesn't function on python code, it
>> functions on git commit message, which make
On Tue, Dec 9, 2014 at 12:39 PM, Sean Dague wrote:
> 1 - the entire H8* group. This doesn't function on python code, it
> functions on git commit message, which makes it tough to run locally.
>
I do run them locally using git-review custom script features which would
launch a flake8 before sendi
On 12/09/2014 03:39 AM, Sean Dague wrote:
> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>
> 1 - the entire H8* group. This doesn't function on python code, it
> functions on git commit message, which makes it tough to run locally. It
> also would be a reason to pre
All of the feedback so far has supported moving the existing IRC
Third-party CI meeting to better fit a worldwide audience.
The consensus is that we will have only 1 meeting per week at alternating
times. You can see examples of other teams with alternating meeting times
at: https://wiki.openstack
Hello!
There is a feature in HypervisorSupportMatrix
(https://wiki.openstack.org/wiki/HypervisorSupportMatrix) called "Get Guest
Info". Does anybody know, what does it mean? I haven't found anything like
this neither in nova api nor in horizon and nova command line.
--
Thanks,
Dmitry Guryanov
On 12/09/2014 05:00 PM, Jim Rollenhagen wrote:
On Tue, Dec 09, 2014 at 04:01:07PM +0400, Vladimir Kozhukalov wrote:
Just a short explanation of Fuel use case.
Fuel use case is not a cloud. Fuel is a deployment tool. We install OS on
bare metal servers and on VMs
and then configure this OS using
On 22.9.2014 17:24, Ihar Hrachyshka wrote:
> On 22/09/14 17:07, Radomir Dopieralski wrote:
>> Horizon's tests were recently broken by a change in the Ceilometer
>> client that removed a deprecated exception. The exception was
>> deprecated for a while already, but as it often is, nobody did the
>
The Oslo team is pleased to announce the release of oslo.context 0.1.0. This is
the first version of oslo.context, the library containing the base class for
the request context object. This is a relatively small module, but we’ve placed
it in a separate library so oslo.messaging and oslo.log can
Hi All,
I'm canceling the hyper-v meeting today due to a conflicting shedules, we will
resume next week.
Peter J. Pouliot CISSP
Microsoft Enterprise Cloud Solutions
C:\OpenStack
New England Research & Development Center
1 Memorial Drive
Cambridge, MA 02142
P: 1.(857).4536436
E: ppoul...@microsof
+1! Makes sense.
--Brad
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: Adam Young , "OpenStack Development Mailing
List (not for usage questions)"
Date: 12/08
And what about no recovery in case of failure mid-task? I can see that there's
some TaskFlow integration done. This lib seems to address these issues (if used
with taskflow.persistent submodule, which Cinder isn't using). Any plans for
further integration with TaskFlow?
-Original Message---
On Tue, Dec 9, 2014 at 9:05 AM, Sean Dague wrote:
> - [H305 H306 H307] Organize your imports according to the `Import order
> template`_ and `Real-world Import Order Examples`_ below.
>
> I think these remain reasonable guidelines, but H302 is exceptionally
> tricky to get right, and we keep not
We assume next step will be to put provision data (disk partition
> scheme, maybe other data) into driver_info and make Fuel Agent driver
> able to serialize those data (special format) and implement a
> corresponding data driver in Fuel Agent for this format. Again very
> simple. Maybe it is time
On 12/09/2014 11:15 AM, Brian Curtis wrote:
> On Tue, Dec 9, 2014 at 9:05 AM, Sean Dague wrote:
>> - [H305 H306 H307] Organize your imports according to the `Import order
>> template`_ and `Real-world Import Order Examples`_ below.
>>
>> I think these remain reasonable guidelines, but H302 is ex
On 2014-12-09 07:29:31 -0800 (-0800), Monty Taylor wrote:
> I DO like something warning about commit subject length ... but maybe
> that should be a git-review function or something.
[...]
How about a hook in Gerrit to refuse commits based on some simple
(maybe even project-specific) rules?
--
Je
On 12/09/2014 10:57 AM, Brad Topol wrote:
+1! Makes sense.
--Brad
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: Adam Young , "OpenStack Development Mailing
List (no
There are some significant limitations to the pure taskflow approach,
however some combination of atomic micro-state management and taskflow
persistence is being looked at
Duncan Thomas
On Dec 9, 2014 6:24 PM, "Dulko, Michal" wrote:
> And what about no recovery in case of failure mid-task? I can
On Tue, Dec 09, 2014, Sean Dague wrote:
> This check should run on any version of python and give the same
> results. It does not, because it queries python to know what's in stdlib
> vs. not.
Just to underscore that it's difficult to get right, I found out recently
that hacking doesn't do a grea
On Tue, Dec 09, 2014 at 10:15:34AM -0600, Brian Curtin wrote:
> On Tue, Dec 9, 2014 at 9:05 AM, Sean Dague wrote:
> > - [H305 H306 H307] Organize your imports according to the `Import order
> > template`_ and `Real-world Import Order Examples`_ below.
> >
> > I think these remain reasonable guid
I would like to chime into this discussion wearing my plugin developer hat.
We (the VMware team) have looked very carefully at the current proposal for
splitting off drivers and plugins from the main source code tree. Therefore
the concerns you've heard from Gary are not just ramblings but are the
On Tue, Dec 09, 2014, Sean Dague wrote:
> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>
> 1 - the entire H8* group. This doesn't function on python code, it
> functions on git commit message, which makes it tough to run locally. It
> also would be a reason to prev
On Tue, Dec 09, 2014 at 06:33:47PM +0300, Dmitry Guryanov wrote:
> Hello!
>
> There is a feature in HypervisorSupportMatrix
> (https://wiki.openstack.org/wiki/HypervisorSupportMatrix) called "Get Guest
> Info". Does anybody know, what does it mean? I haven't found anything like
> this neither i
On 12/09/2014 08:32 AM, Kurt Taylor wrote:
> All of the feedback so far has supported moving the existing IRC
> Third-party CI meeting to better fit a worldwide audience.
>
> The consensus is that we will have only 1 meeting per week at alternating
> times. You can see examples of other teams with
On 12/09/2014 11:41 AM, Johannes Erdfelt wrote:
> On Tue, Dec 09, 2014, Sean Dague wrote:
>> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>>
>> 1 - the entire H8* group. This doesn't function on python code, it
>> functions on git commit message, which makes it toug
On 12/09/2014 11:28 AM, Jeremy Stanley wrote:
> On 2014-12-09 07:29:31 -0800 (-0800), Monty Taylor wrote:
>> I DO like something warning about commit subject length ... but maybe
>> that should be a git-review function or something.
> [...]
>
> How about a hook in Gerrit to refuse commits based on
On Tue, 2014-12-09 at 10:05 -0500, Sean Dague wrote:
> Sure, the H8* group is git commit messages. It's checking for line
> length in the commit message.
I agree the H8* group should be dropped. It would be appropriate to
create a new gate check job that validated that, but it should not be
part
On December 9, 2014 at 10:43:51 AM, Adam Young (ayo...@redhat.com) wrote:
On 12/09/2014 10:57 AM, Brad Topol wrote:
+1! Makes sense.
--Brad
Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet: bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680
From:
On 2014-12-09 16:50:48 +0100 (+0100), Jakub Ruzicka wrote:
> On 22.9.2014 17:24, Ihar Hrachyshka wrote:
[...]
> > Aren't clients supposed to be backwards compatible? Isn't it the exact
> > reason why we don't maintain stable branches for client modules?
>
> Supposed, yes. However, it's not ensured
On 12/09/2014 11:58 AM, Kevin L. Mitchell wrote:
> On Tue, 2014-12-09 at 10:05 -0500, Sean Dague wrote:
>> Sure, the H8* group is git commit messages. It's checking for line
>> length in the commit message.
>
> I agree the H8* group should be dropped. It would be appropriate to
> create a new gat
On 2014-12-09 11:56:54 -0500 (-0500), Sean Dague wrote:
> Honestly, any hard rejection ends up problematic. For instance, it
> means it's impossible to include actual urls in commit messages to
> reference things without a url shortener much of the time.
Fair enough. I think this makes it a human
> > On Tue, Dec 09, 2014 at 06:33:47PM +0300, Dmitry Guryanov wrote:
> >
> > Hello!
> >
> > There is a feature in HypervisorSupportMatrix
> > (https://wiki.openstack.org/wiki/HypervisorSupportMatrix) called "Get
Guest
> > Info". Does anybody know, what does it mean? I haven't found anything
l
I would like to propose that we keep the policy library under the oslo program.
As with other graduated projects we will maintain a core team (that while
including the oslo-core team) will be comprised of the expected individuals
from the Identity and other security related teams.
The change in
On Tue, 2014-12-09 at 12:05 -0500, Sean Dague wrote:
> > I agree that dropping H302 and the grouping checks makes sense. I
> think
> > we should keep the H301, H303, H304, and the basic ordering checks,
> > however; it doesn't seem to me that these would be that difficult to
> > implement or maint
On 12/09/2014 12:18 PM, Morgan Fainberg wrote:
I would like to propose that we keep the policy library under the oslo
program. As with other graduated projects we will maintain a core team
(that while including the oslo-core team) will be comprised of the
expected individuals from the Identity
On 9 December 2014 at 09:41, Salvatore Orlando wrote:
> I would like to chime into this discussion wearing my plugin developer hat.
>
> We (the VMware team) have looked very carefully at the current proposal
> for splitting off drivers and plugins from the main source code tree.
> Therefore the c
On Dec 9, 2014, at 10:05 AM, Sean Dague wrote:
> On 12/09/2014 09:11 AM, Doug Hellmann wrote:
>>
>> On Dec 9, 2014, at 6:39 AM, Sean Dague wrote:
>>
>>> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>>>
>>> 1 - the entire H8* group. This doesn't function on pyt
Vladimir,
IMO there is more "global" problem. Anyone who wants to use baremetal deploy
service should resolve problems with power management, PXE/iPXE support,
DHCP, etc. Or he/she can use Ironic. User has his own vision of deploy
workflow
and features needed for it. He hears from Ironic people:
We've been interested in Ironic as a replacement for Cobbler for some of our
systems and have been kicking the tires a bit recently.
While initially I thought this thread was probably another "Fuel not playing
well with the community" kind of thing, I'm not thinking that any more. Its
deeper th
On 9 December 2014 at 17:32, Armando M. wrote:
>
>
> On 9 December 2014 at 09:41, Salvatore Orlando
> wrote:
>
>> I would like to chime into this discussion wearing my plugin developer
>> hat.
>>
>> We (the VMware team) have looked very carefully at the current proposal
>> for splitting off driv
Kevin,
Just to make sure everyone understands what Fuel Agent is about. Fuel Agent
is agnostic to image format. There are 3 possibilities for image format
1) DISK IMAGE contains GPT/MBR table and all partitions and metadata in
case of md or lvm. That is just something like what you get when run 'd
This is a quick note that the Keystone team will not be holding a meeting
today. Based upon last week’s meeting the goals for today are to review open
specs[1] and blocking code reviews for the k1 milestone[2] instead.
We will continue with the normal meeting schedule next week.
[1]
https://re
Guys,
May be I misunderstood something here but what is the difference between
this one and
https://blueprints.launchpad.net/mistral/+spec/mistral-execution-environment
?
On Tue, Dec 9, 2014 at 5:35 PM, Dmitri Zimine
wrote:
> Winson,
>
> thanks for filing the blueprint:
> https://blueprints.lau
On 09:36 Sat 06 Dec , Pradip Mukhopadhyay wrote:
> Where this config info is getting parsed out in the cinder code?
https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/netapp/options.py
https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/netapp/common.py#L76
Hi,
The latest version of the Tap-aaS spec is available at:
https://review.openstack.org/#/c/140292/
It was uploaded last night and we are hoping that it will be considered as a
candidate for the Kilo release.
Thanks,
Anil
___
OpenStack-dev mailing l
On Dec 9, 2014, at 7:04 AM, Daniel P. Berrange wrote:
> On Tue, Dec 09, 2014 at 10:53:19AM +0100, Maxime Leroy wrote:
>> I have also proposed a blueprint to have a new plugin mechanism in
>> nova to load external vif driver. (nova-specs:
>> https://review.openstack.org/#/c/136827/ and nova (rfc p
Excerpts from Yuriy Zveryanskyy's message of 2014-12-09 04:05:03 -0800:
> Good day Ironicers.
>
> I do not want to discuss questions like "Is feature X good for release
> Y?" or "Is feature Z in Ironic scope or not?".
> I want to get an answer for this: Is Ironic a flexible, easy extendable
> an
On 12/09/2014 12:20 PM, Kevin L. Mitchell wrote:
> On Tue, 2014-12-09 at 12:05 -0500, Sean Dague wrote:
>>> I agree that dropping H302 and the grouping checks makes sense. I
>> think
>>> we should keep the H301, H303, H304, and the basic ordering checks,
>>> however; it doesn't seem to me that the
On 12/09/2014 12:07 PM, Jeremy Stanley wrote:
> On 2014-12-09 11:56:54 -0500 (-0500), Sean Dague wrote:
>> Honestly, any hard rejection ends up problematic. For instance, it
>> means it's impossible to include actual urls in commit messages to
>> reference things without a url shortener much of the
Hi all,
On a RHEL system, as I upgrade hacking package from 0.8.0 to 0.9.5, I
see flake8 stops working. Upgrading setuptools resolves the issue. But I
do not see a change in version for pep8 or setuptools, with the upgrade
in setuptools.
Any issue in packaging? Any explanation of this behavi
On Tue, Dec 9, 2014 at 3:33 AM, Miguel Ángel Ajo wrote:
>
> Hi all!
>
> It would be great if you could use this thread to post hot reviews on
> stuff
> that it’s being worked out during the mid-cycle, where others from different
> timezones could participate.
I think we've used the etherpad [1]
On 12/09/2014 06:04 AM, Jeremy Stanley wrote:
> We already have a solution for tracking the contributor->IRC
> mapping--add it to your Foundation Member Profile. For example, mine
> is in there already:
>
> http://www.openstack.org/community/members/profile/5479
I recommend updating the opens
On Dec 9, 2014, at 12:18 PM, Morgan Fainberg wrote:
> I would like to propose that we keep the policy library under the oslo
> program. As with other graduated projects we will maintain a core team (that
> while including the oslo-core team) will be comprised of the expected
> individuals fro
On 2014-12-09 13:49:00 -0500 (-0500), Sean Dague wrote:
[...]
> And I also think that if a commit message change doesn't retrigger all
> the tests, people will be a lot happier updating them.
Agreed--though this will need a newer Gerrit plus a new feature in
Zuul so it recognizes the difference in
On 12/09/2014 02:46 PM, Jeremy Stanley wrote:
> On 2014-12-09 13:49:00 -0500 (-0500), Sean Dague wrote:
> [...]
>> And I also think that if a commit message change doesn't retrigger all
>> the tests, people will be a lot happier updating them.
>
> Agreed--though this will need a newer Gerrit plus
Now that the infra manual includes the “Project Creator’s Guide”, I have
updated our wiki page to refer to it. I could use a sanity check to make sure I
don’t have things in a bad order. If you have a few minutes to help with that,
please look over https://wiki.openstack.org/wiki/Oslo/CreatingAN
Thank you for explaining in detail what Fuel's use case is. I was lacking
this information, and taking the FuelAgent proposal in isolation. Allow me
to respond to several points inline...
On Tue Dec 09 2014 at 4:08:45 AM Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Just a short explan
On Tue, Dec 09, 2014 at 06:15:01PM +0100, Markus Zoeller wrote:
> > > On Tue, Dec 09, 2014 at 06:33:47PM +0300, Dmitry Guryanov wrote:
> > >
> > > Hello!
> > >
> > > There is a feature in HypervisorSupportMatrix
> > > (https://wiki.openstack.org/wiki/HypervisorSupportMatrix) called "Get
> Guest
On 09/12/14 03:48, Renat Akhmerov wrote:
Hey,
I think it’s a question of what the final goal is. For just creating security
groups as a resource I think Georgy and Zane are right, just use Heat. If the
goal is to try Mistral or have this simple workflow as part of more complex
then it’s total
On Tue, 2014-12-09 at 13:46 -0500, Sean Dague wrote:
> Yes, the following fails H305 and H306.
>
> nova/tests/fixtures.py
>
> """Fixtures for Nova tests."""
> from __future__ import absolute_import
>
> import gettext
> import logging
> import os
> import uuid
>
> import fixtures
> from oslo.con
1 - 100 of 141 matches
Mail list logo
