On 08/19/2015 02:05 AM, Ruby Loo wrote:
On 17 August 2015 at 20:20, Robert Collins
robe...@robertcollins.net mailto:robe...@robertcollins.net
wrote:
On 11 August 2015 at 06:13, Ruby Loo rlooya...@gmail.com
mailto:rlooya...@gmail.com wrote:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
--
-- Dmitry Tantsur
--
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
On 07/30/2015 08:59 AM, Kai KH Huang wrote:
Dear Devananda
I'm the development leader of Lenovo Cloud Solution. Lenovo is
planning to contribute its Ironic driver to the OpenStack community. The
Ironic driver developers already registered as OpenStack members and
signed agreement with
On 07/28/2015 10:51 PM, Devananda van der Veen wrote:
On Tue, Jul 28, 2015 at 1:01 AM Dmitry Tantsur dtant...@redhat.com
mailto:dtant...@redhat.com wrote:
On 07/27/2015 10:41 PM, Sean Dague wrote:
On 07/27/2015 04:35 PM, Jim Rollenhagen wrote:
Hi friends.
Ironic
, and if so, they can do that via
python logging config.
Thanks!
As I saw no objections, I went ahead and proposed
https://review.openstack.org/#/c/206437/
On 07/27/2015 06:32 AM, Dmitry Tantsur wrote:
Hi all!
I didn't find the discussion on the ML so I feel like starting one.
What
On 07/27/2015 10:41 PM, Sean Dague wrote:
On 07/27/2015 04:35 PM, Jim Rollenhagen wrote:
Hi friends.
Ironic implemented API micro versions in Kilo. We originally did this
to allow for breaking changes in the API while allowing users to opt in
to the breakage.
Since then, we've had a default
Hi all!
I didn't find the discussion on the ML so I feel like starting one.
What was the reason of setting verbose to false by default? The patch
[1] does not provide any reasoning for it.
We all know that software does fail from time to time. While the default
level of WARN might give some
Jim,
I'm redirecting your question to oslo folks, as I'm afraid my answer can
be wrong.
On 07/23/2015 01:55 PM, Jim Rollenhagen wrote:
On Wed, Jul 22, 2015 at 02:40:47PM +0200, Dmitry Tantsur wrote:
Hi all!
Currently _spawn_worker in the conductor manager raises
NoFreeConductorWorker
On 07/21/2015 09:29 PM, Derek Higgins wrote:
Hi All,
Something we discussed at the summit was to switch the focus of
tripleo's deployment method to deploy using instack using images built
with tripleo-puppet-elements. Up to now all the instack work has been
done downstream of tripleo as part
Hi all!
Currently _spawn_worker in the conductor manager raises
NoFreeConductorWorker if pool is already full. That's not very user
friendly (potential source of retries in client) and does not map well
on common async worker patterns.
My understanding is that it was done to prevent the
Hi folks!
If you're not aware already, I'm working on solving node is locked
problems breaking users (and tracking it at
https://etherpad.openstack.org/p/ironic-locking-reform). We have retries
in place in client, but we all agree that it's not the eventual solution.
One of the things we've
On 07/21/2015 03:26 PM, Lucas Alvares Gomes wrote:
Hi,
So, it looks like the only reason we check the reservation field here is
because we want to return a 409 for node is locked rather than a 400,
right? do_node_deploy and such will raise a NodeLocked, which should do
the same as this check.
On 07/21/2015 03:32 PM, Lucas Alvares Gomes wrote:
Hi,
Another question folks: while the problem above is valid and should be
solved, I was actually keeping in mind another one:
https://github.com/openstack/ironic/blob/master/ironic/api/controllers/v1/node.py#L1052-L1057
This is also not
On 07/21/2015 02:24 PM, Dmitry Tantsur wrote:
Hi folks!
If you're not aware already, I'm working on solving node is locked
problems breaking users (and tracking it at
https://etherpad.openstack.org/p/ironic-locking-reform). We have retries
in place in client, but we all agree that it's
On 07/21/2015 03:01 PM, Jim Rollenhagen wrote:
On Tue, Jul 21, 2015 at 02:24:14PM +0200, Dmitry Tantsur wrote:
Hi folks!
If you're not aware already, I'm working on solving node is locked
problems breaking users (and tracking it at
https://etherpad.openstack.org/p/ironic-locking-reform). We
) new client + new server + user opts in to new behavior: user app must
behave differently
By contrast, your current approach will impact users in case (c) as soon
as we release a client which defaults to any API version = 1.11.
-Deva
On Thu, Jul 16, 2015 at 4:30 AM Dmitry Tantsur dtant
Hi all!
Today we landed a patch [1] that switches (starting with API version
1.11) node creation API to default to ENROLL node state instead of
AVAILABLE. Nothing to worry about right now: we don't default to this
API version (yet?) in our clients. But read on to figure out how not to
get
Hi all,
Recent breakage makes me finally raise the question that bothered me for
some time: are there possible alternatives to mock library we could use?
A couple reasons for that:
1. Devs don't seem to care about semver, backward compatibility and all
this boring stuff. Releasing a minor
On 07/10/2015 02:00 PM, Robert Collins wrote:
On 10 July 2015 at 23:34, Dmitry Tantsur dtant...@redhat.com wrote:
On 07/10/2015 01:13 PM, Robert Collins wrote:
I see that a lot of code started breaking due to
side_effect = Exception()
no longer working. Which was a declared way for some
On 07/10/2015 01:13 PM, Robert Collins wrote:
On 10 July 2015 at 23:04, Dmitry Tantsur dtant...@redhat.com wrote:
Hi all,
Recent breakage makes me finally raise the question that bothered me for
some time: are there possible alternatives to mock library we could use?
There are. Personally
On 07/07/2015 11:21 AM, Yuiko Takada wrote:
Hi folks,
I found the difference between wiki[1] and governance[2].
wiki says Generally the capitalization of the project team names like
swift is lowercase.
But in governance, written as uppercase like Nova, Swift.
It's grammatically incorrect
Hi all!
Please welcome Yuiko Takada to ironic-inspector-core team. Yuiko has
been with the team for some time already. She did substantial work on
porting ironic-inspector to Oslo libraries and on our new devstack gate job.
Thanks Yuiko, it's a pleasure to work with you.
As our core team
Dmitry Tantsur dtant...@redhat.com
wrote:
On 06/16/2015 03:47 PM, Jim Rollenhagen wrote:
On Tue, Jun 16, 2015 at 08:56:37AM +0200, Dmitry Tantsur wrote:
On 06/04/2015 08:58 AM, Xu, Hejie wrote:
Hi, guys,
I’m working on adding Microversion into the API-WG’s guideline
which
make
26 июня 2015 г. 2:48 пользователь GHANSHYAM MANN ghanshyamm...@gmail.com
написал:
On Thu, Jun 25, 2015 at 5:18 PM, Ken'ichi Ohmichi ken1ohmi...@gmail.com
wrote:
Sorry for late response here,
2015-06-20 9:14 GMT+09:00 Devananda van der Veen
devananda@gmail.com:
Long version...
On 06/26/2015 01:14 PM, Sean Dague wrote:
On 06/16/2015 09:51 AM, Dmitry Tantsur wrote:
On 06/16/2015 08:56 AM, Dmitry Tantsur wrote:
To sum this long post up, I'm seeing that hiding new features based on
microversions brings much more problems, than it solves (I'm not aware
of the latter
On 06/26/2015 04:08 PM, Sean Dague wrote:
On 06/26/2015 07:43 AM, Dmitry Tantsur wrote:
On 06/26/2015 01:14 PM, Sean Dague wrote:
On 06/16/2015 09:51 AM, Dmitry Tantsur wrote:
On 06/16/2015 08:56 AM, Dmitry Tantsur wrote:
To sum this long post up, I'm seeing that hiding new features based
On 06/26/2015 04:57 PM, Joe Gordon wrote:
On Fri, Jun 26, 2015 at 7:39 AM, Dmitry Tantsur dtant...@redhat.com
mailto:dtant...@redhat.com wrote:
On 06/26/2015 04:08 PM, Sean Dague wrote:
On 06/26/2015 07:43 AM, Dmitry Tantsur wrote:
On 06/26/2015 01:14 PM, Sean Dague
-- unless we
include a version number along with your feature string? And now we're
right back where we started.
Ok, maybe this idea is just as broken. Still, the current proposal
brings more problems than it solves.
-Deva
On Fri, Jun 26, 2015, 07:41 Dmitry Tantsur dtant...@redhat.com
On 06/25/2015 05:33 PM, Anne Gentle wrote:
On Thu, Jun 25, 2015 at 7:10 AM, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:
On 06/25/2015 04:42 AM, Ken'ichi Ohmichi wrote:
2015-06-25 17:25 GMT+09:00 Lucas Alvares Gomes
lucasago...@gmail.com mailto:lucasago...@gmail.com:
On 06/25/2015 06:04 PM, Anne Gentle wrote:
On Thu, Jun 25, 2015 at 10:55 AM, Dmitry Tantsur dtant...@redhat.com
mailto:dtant...@redhat.com wrote:
On 06/25/2015 05:33 PM, Anne Gentle wrote:
On Thu, Jun 25, 2015 at 7:10 AM, Sean Dague s...@dague.net
mailto:s...@dague.net
On 06/25/2015 10:18 AM, Ken'ichi Ohmichi wrote:
Sorry for late response here,
2015-06-20 9:14 GMT+09:00 Devananda van der Veen devananda@gmail.com:
Long version...
Every HTTP response from Ironic today includes three headers: min, max, and
version. The service can present an older API
On 06/25/2015 11:11 AM, Ken'ichi Ohmichi wrote:
2015-06-25 17:31 GMT+09:00 Dmitry Tantsur dtant...@redhat.com:
On 06/25/2015 10:18 AM, Ken'ichi Ohmichi wrote:
Sorry for late response here,
2015-06-20 9:14 GMT+09:00 Devananda van der Veen
devananda@gmail.com:
Long version...
Every HTTP
On 06/24/2015 09:18 AM, Nanda Devi Sahu wrote:
Hello,
I have downloaded the redfish available code and I want to run the
test_redfish program to understand what happens.
Whenever I set the host name and give the username and password and try
to run the file test_redfish.py I get the below
:08 PM Devananda van der Veen
devananda@gmail.com mailto:devananda@gmail.com wrote:
I'm
On Mon, Jun 22, 2015 at 8:19 AM John Trowbridge tr...@redhat.com
mailto:tr...@redhat.com wrote:
On 06/22/2015 10:40 AM, Dmitry Tantsur wrote:
On 06/22/2015 04:19 PM
On 06/22/2015 04:19 PM, Devananda van der Veen wrote:
Hi John,
Thanks for the excellent summary! I found it very helpful to get caught
up. I'd like to make sure I understand the direction ahc is going. A
couple questions...
Let me add my $0.5 :)
I see that ahc is storing its information in
from us.
Just one clarifying question: shouldn't b) and c) be compatible-with:
1.4, as 1.4 was a breaking change?
Yes -- (b) and (c) are identical responses.
Discuss.
-Devananda
On Tue, Jun 16, 2015 at 7:13 AM Dmitry Tantsur dtant...@redhat.com
mailto:dtant...@redhat.com wrote:
On 06
On 06/16/2015 08:16 PM, Georgy Okrokvertskhov wrote:
In Murano project we do see a positive impact of BigTent model. Since
Murano was accepted as a part of BigTent community we had a lot of
conversations with potential users. They were driven exactly by the fact
that Murano is now officially
On 06/17/2015 06:54 AM, Ken'ichi Ohmichi wrote:
2015-06-17 12:38 GMT+09:00 Yuiko Takada yuikotakada0...@gmail.com:
Then, as you and Matt and Dimitry talked about this on IRC few days ago,
We can add Ironic/Ironic-inspector tests into Tempest still, right?
So that I've started to implement a
On 06/17/2015 03:35 AM, Ken'ichi Ohmichi wrote:
2015-06-16 21:16 GMT+09:00 Jay Pipes jaypi...@gmail.com:
On 06/16/2015 08:00 AM, Dmitry Tantsur wrote:
16 июня 2015 г. 13:52 пользователь Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com написал:
On 06/16/2015 04:36 AM, Alex Xu
On 06/16/2015 03:47 PM, Jim Rollenhagen wrote:
On Tue, Jun 16, 2015 at 08:56:37AM +0200, Dmitry Tantsur wrote:
On 06/04/2015 08:58 AM, Xu, Hejie 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
On 06/16/2015 08:56 AM, Dmitry Tantsur wrote:
On 06/04/2015 08:58 AM, Xu, Hejie 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
16 июня 2015 г. 13:52 пользователь Jay Pipes jaypi...@gmail.com написал:
On 06/16/2015 04:36 AM, Alex Xu wrote:
So if our min_version is 2.1 and the max_version is 2.50. That means
alternative implementations need implement all the 50 versions
api...that sounds pain...
Yes, it's pain, but
On 06/04/2015 08:58 AM, Xu, Hejie 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 Magnum
On 06/15/2015 10:31 PM, Jay Pipes wrote:
On 06/15/2015 02:09 PM, Dmitry Tantsur wrote:
2015-06-15 19:50 GMT+02:00 Clint Byrum cl...@fewbar.com
mailto:cl...@fewbar.com:
Excerpts from Jay Pipes's message of 2015-06-15 10:07:39 -0700:
It has come to my attention in [1
On 06/16/2015 08:58 AM, Ramakrishnan G wrote:
Hi All,
Some time back we created a new repository[1] to move all the reusable
code components of Ironic to a separate library. The branched out code
has changed and there has been a review out to sync it [2]. But
unfortunately, it has got stale
?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
--
-- Dmitry Tantsur
--
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
On 06/15/2015 07:07 PM, Jay Pipes wrote:
It has come to my attention in [1] that the microversion spec for Nova
[2] and Ironic [3] have used the project name -- i.e. Nova and Ironic --
instead of the name of the API -- i.e. OpenStack Compute and
OpenStack Bare Metal -- in the HTTP header that a
GMT+09:00 Dmitry Tantsur dtant...@redhat.com
mailto:dtant...@redhat.com:
On 06/10/2015 09:40 AM, Ken'ichi Ohmichi wrote:
To solve it, we have decided the scope of Tempest as the etherpad
mentioned.
Are there any hints now on where we can start with our integration
tests
?
Best Regards,
Yuiko Takada
2015-06-09 15:59 GMT+09:00 Dmitry Tantsur dtant...@redhat.com
mailto:dtant...@redhat.com:
On 06/09/2015 03:49 AM, Yuiko Takada wrote:
Hi, Dmitry,
Thank you for notifying.
I've updated our summit etherpad [3] with whatever priorities I
On 06/10/2015 09:40 AM, Ken'ichi Ohmichi wrote:
Hi Dmitry,
2015-06-10 16:11 GMT+09:00 Dmitry Tantsur dtant...@redhat.com:
Hi, QA folks!
As ironic-inspector is joining the openstack/* crows, we're faces with
integration testing question. At the summit we discussed with Devananda that
it makes
do it, if we have something to
release by the time Ironic releases, but I suggest deciding it on
case-by-case basis.
Best Regards,
Yuiko Takada(Inspector team member)
2015-06-08 20:38 GMT+09:00 Dmitry Tantsur dtant...@redhat.com
mailto:dtant...@redhat.com:
Hello, Inspector team
Hello, Inspector team!
The renaming process is going pretty well, the last thing we need to do
is to get Infra approval and actual rename [1][2].
I'd like to allow people (e.g. myself) to start packaging inspector
under it's new name, so I'd like to make 2.0.0 release as soon as
possible
On 06/04/2015 05:27 PM, Lucas Alvares Gomes wrote:
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
On 06/04/2015 06:18 PM, Devananda van der Veen wrote:
On Jun 4, 2015 5:53 AM, Dmitry Tantsur dtant...@redhat.com
mailto: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
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
work
:
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
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 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
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 then it will be impossible to change a driver after
moving forward:
Hi again!
~ half an hour has passed since my last email, and now I have one more
question to discuss and decide!
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
On 05/28/2015 06:41 PM, Devananda van der Veen wrote:
Hi all,
tl;dr;
At the summit, the Ironic team discussed the challenges we've had with
the current release model and came up with some ideas to address them.
I had a brief follow-up conversation with Doug and Thierry, but I'd
like this to be
Hi folks!
A bit earlier than expected to to my PTO I'm announcing ironic-discoverd
1.1.0. Download it from PyPI: https://pypi.python.org/pypi/ironic-discoverd
We've spent substantial amount of time polishing existing features and
fixing bugs. Highlights are:
* New config options for tuning
Hi folks.
Recently I got several requests to implement API aborting introspection
in discoverd. This is useful mostly when debugging, when you know that
introspection has failed, and you want to stop it right now. I've put a
blueprint
factored into a reusable thing (eg, ironic/utils or
ironic/driver/utils or such) then it should be.
Cheers,
-Deva
On Tue, Apr 14, 2015 at 1:40 PM, Dmitry Tantsur divius.ins...@gmail.com wrote:
Hi,
actually 2 possibilities here:
1. discoverd itself handles TFTP
2. DiscoverdInspect hanldes TFTP
I
(assuming such integration was desired by the cloud operator)?
-Deva
On Fri, Apr 10, 2015 at 12:31 AM, Dmitry Tantsur dtant...@redhat.com
wrote:
On 04/10/2015 01:43 AM, Jaromir Coufal wrote:
Hey Dmitry,
o/
I wanted to ask you about ironic-discoverd.
At the moment, after build
Hi all!
This time I'm trying to roughly follow OpenStack release procedures, so
ironic-discoverd just got a stable/1.1 branch, which is equivalent to
RC. I'm proud to say that the upcoming 1.1.0 release (which is scheduled
on Apr 30, just like other projects) is mostly about polishing
On 04/08/2015 12:53 PM, Sean Dague wrote:
On 04/08/2015 03:58 AM, Dmitry Tantsur wrote:
On 04/08/2015 06:23 AM, Ken'ichi Ohmichi wrote:
Hi,
Now Nova and Ironic have implemented API microversions in Kilo.
Nova's microversions are v2.1 - v2.3.
Ironic's microversions are v1.1 - v1.6.
Now
On 04/08/2015 06:23 AM, Ken'ichi Ohmichi wrote:
Hi,
Now Nova and Ironic have implemented API microversions in Kilo.
Nova's microversions are v2.1 - v2.3.
Ironic's microversions are v1.1 - v1.6.
Now Tempest is testing the lowest microversion on the gate, and
Ironic's microversions test patch[1]
if version 1.1. So the only way to
avoid it is to default to 1.0, which will make it harder and less
intuitive to access new features.
On Fri, Apr 3, 2015 at 1:59 PM, Dmitry Tantsur dtant...@redhat.com
mailto:dtant...@redhat.com wrote:
Hi all!
Today I got an internal email
is the must IMO. While client
is in 0.x range and we're free to break it occasionally, people still
don't expect us to :) I think we also need to put information about the
header and how it affects people in ironicclient docs introduction.
-Deva
On Fri, Apr 3, 2015 at 1:31 AM Dmitry Tantsur
Hi again, hope you're not tired of this topic :D
I'm seeking for advice on what to do with microversions in discoverd.
Basically I have the following options:
1. Do nothing. Get whatever behavior I can get from installed Ironic and
Ironic client. Though unlikely, may get broken by future
versions or new features. That's what bothered me
a bit with the whole microversioning as we implemented it.
Anyway I think we should have a document laying out stuff like that.
Hope that helps. :)
// jim
On April 7, 2015 at 6:07:57 AM, Dmitry Tantsur (dtant...@redhat.com
mailto:dtant...@redhat.com
Hi all!
Today I got an internal email, stating that new ironicclient brakes
ironic-discoverd. Indeed, after rebase to the latest ironicclient git
master, discoverd started receiving AVAILABLE state instead of None
for newly enrolled nodes. It's not a valid state for introspection,
valid are
This is an informational email about upcoming ironic-discoverd-1.1.0
[1]. If you're not interested in discoverd, you may safely skip it.
Hi all!
Do you know what time is coming? Release time! I'm hoping to align this
ironic-discoverd release with the OpenStack one. Here's proposed plan,
On 03/12/2015 05:05 PM, Devananda van der Veen wrote:
Without further ado, and since everyone (even though some haven't
replied here) has +1'd this, and since we could really use ramesh's +2's
in the run up to Kilo-3 and feature freeze, even without the customary
waiting/voting period being
Hi all!
I've made a bug fix release for ironic-discoverd today, and it's
available on PyPI! Two issues fixed:
* Authentication was too strict, and it wasn't possible to talk to the
API using Ironic service user. Unfortunately fixing it lead to a new
dependency on keystonemiddleware and new
On 02/28/2015 07:28 AM, Ramakrishnan G wrote:
Hello All,
Hi!
This is about adding vendor drivers in Ironic.
In Kilo, we have many vendor drivers getting added in Ironic which is a
very good thing. But something I noticed is that, most of these reviews
have lots of hardware-specific code
2015-02-27 17:27 GMT+01:00 Dolph Mathews dolph.math...@gmail.com:
On Fri, Feb 27, 2015 at 8:39 AM, Dmitry Tantsur dtant...@redhat.com
wrote:
Hi all!
This (presumably) pretty basic question tortures me for several months
already, so I kindly seek for help here.
I'm working on a Flask
Hi all!
This (presumably) pretty basic question tortures me for several months
already, so I kindly seek for help here.
I'm working on a Flask-based service [1] and I'd like to use Keystone
tokens for authentication. This is an admin-only API, so we need to
check for an admin role. We ended
On 02/25/2015 05:26 PM, Ruby Loo wrote:
Hi,
I was wondering what people thought about patches that only fix
grammatical issues or misspellings in comments in our code.
I can't believe I'm sending out this email, but as a group, I'd like it
if we had a similar understanding so that we treat
On 02/20/2015 06:14 AM, Ganapathy, Sandhya wrote:
Hi All,
I would like to discuss the Chassis Discovery Tool Blueprint -
https://review.openstack.org/#/c/134866/
The blueprint suggests Hardware enrollment and introspection for
properties at the Chassis layer. Suitable for micro-servers that
Hi everyone!
On one of our meetings [1] we agreed on keeping *ED states (DELETED,
INSPECTED, CLEANED, etc) as no-ops for now. Since then, however, the
inspection patch [2] got several comments from cores requesting removal
of INSPECTED state. That was done by Nisha.
Today we decided to
Hi!
A bit earlier than expected due to personal circumstances I'm announcing
first stable release of ironic-discoverd: 1.0.0 [1]. It contains
implementations of 6 blueprints and fixes for 17 bugs. Full release
notes can be found at [2], here is the summary:
* Redesigned API, including
Hi all!
That's pure information email about discoverd, feel free to skip it, if
not interested.
For those interested I'm glad to announce that ironic-discoverd 1.0.0 is
feature complete and is scheduled to release on Feb 5 with Kilo-2
milestone. Master branch is under feature freeze now and
On 01/09/2015 08:12 PM, Stefano Maffulli wrote:
Dear all,
if you've tried the topics on this mailing list and haven't received
emails, well... we had a problem on our side: the topics were not setup
correctly.
Luigi Toscano helped isolate the problem and point at the solution[1].
He noticed
new to automate the enrollment of
new nodes:-)
Collecting IPMI info into a csv file is still a trivial job...
BR
Zhou Zhenzan
-Original Message-
From: Dmitry Tantsur [mailto:dtant...@redhat.com
mailto:dtant...@redhat.com]
Sent: Thursday, January 8, 2015 5:19
On 01/09/2015 02:37 PM, Ihar Hrachyshka wrote:
On 01/09/2015 02:33 PM, Andreas Jaeger wrote:
On 01/09/2015 02:25 PM, Ihar Hrachyshka wrote:
Hi all,
I assumed that we still support py26 for clients, but then I saw [1]
that removed corresponding tox environment from ironic client.
What's our
understand from the below mentioned spec is that the Node is registered,
but the spec will help ironic discover other properties of the node.
that's what discoverd does currently.
-Om
-Original Message-
From: Dmitry Tantsur [mailto:dtant...@redhat.com]
Sent: 07 January 2015 20:20
. Please see https://review.openstack.org/#/c/135605/ for
details on future interaction between discoverd and Ironic.
Just a thought, thanks.
BR
Zhou Zhenzan
-Original Message-
From: Dmitry Tantsur [mailto:dtant...@redhat.com]
Sent: Monday, January 5, 2015 4:49 PM
To: openstack-dev
) will be a
driver for discoverd.
No idea what the progress is with regard to implementation within the
Kilo cycle though.
For now we hope to get it merged in K.
cheers
Matt
Just a thought.
-Om
-Original Message-
From: Dmitry Tantsur [mailto:dtant...@redhat.com]
Sent: 07
Zhenzan
-Original Message-
From: Dmitry Tantsur [mailto:dtant...@redhat.com]
Sent: Thursday, December 11, 2014 10:35 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Ironic] ironic-discoverd status update
Hi all!
As you know I actively promote
Hi all!
As you know I actively promote ironic-discoverd project [1] as one of
the means to do hardware inspection for Ironic (see e.g. spec [2]), so I
decided it's worth to give some updates to the community from time to
time. This email is purely informative, you may safely skip it, if
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
On 12/09/2014 03:40 PM, Vladimir Kozhukalov wrote:
Vladimir Kozhukalov
On Tue, Dec 9, 2014 at 3:51 PM, Dmitry Tantsur dtant...@redhat.com
mailto:dtant...@redhat.com wrote:
Hi folks,
Thank you for additional explanation, it does clarify things a bit.
I'd like to note, however
Hi!
On 11/28/2014 11:41 AM, Murray, Paul (HP Cloud) wrote:
Hi All,
Looking at the ironic virt driver code in nova it seems that a Conflict
(409) response from the ironic client results in the driver re-trying
the request. Given the comment below in the ironic code I would imagine
that is not
Hi all!
As our state machine and discovery discussion proceeds, I'd like to ask
your opinion on whether we need an IntrospectionInterface
(DiscoveryInterface?). Current proposal [1] suggests adding a method for
initiating a discovery to the ManagementInterface. IMO it's not 100%
correct, because:
On 11/20/2014 04:38 PM, Ruby Loo wrote:
Hi, we had an interesting discussion on IRC about whether or not we
should be maintaining backwards compatibility within a release cycle. In
this particular case, we introduced a new decorator in this kilo cycle,
and were discussing the renaming of it, and
On 11/18/2014 06:13 PM, Chris K wrote:
Hi all,
In an effort to keep the Ironic specs review queue as up to date as
possible, I have identified several specs that were proposed in the Juno
cycle and have not been updated to reflect the changes to the current
Kilo cycle.
I would like to set a
On 11/18/2014 02:00 AM, Devananda van der Veen wrote:
Hi all,
As discussed in Paris and at today's IRC meeting [1] we are going to be
alternating the time of the weekly IRC meetings to accommodate our
contributors in EMEA better. No time will be perfect for everyone, but
as it stands, we rarely
On 11/12/2014 10:47 PM, Victor Lowther wrote:
Hmmm... with this thread in mind, anyone think that changing DISCOVERING
to INTROSPECTING in the new state machine spec is a good idea?
As before I'm uncertain. Discovery is a troublesome term, but too many
people use and recognize it, while IMO
501 - 600 of 629 matches
Mail list logo
