[openstack-dev] [ironic] Goodbye ironic o/

with the project, and thanks for everything! Best wishes, Mario Villaplana __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http

Re: [openstack-dev] [ironic] Ironic review party invitation

the etherpad at https://etherpad.openstack.org/p/ironic-review-party to reflect this new time. I am now back from vacation and will be around for this week's review party. Thanks to whoever led last week's review party. Mario On Tue, Feb 28, 2017 at 2:14 PM, Mario Villaplana <mario.vill

Re: [openstack-dev] [ironic] New mascot design

+1, this looks like a nicely stylized version of PXE Boots. Thanks! Mario On Mon, Mar 13, 2017 at 3:25 PM, Jim Rollenhagen wrote: > > On Fri, Mar 10, 2017 at 11:28 AM, Heidi Joy Tretheway > wrote: >> >> Hi Ironic team, >> Here’s an update on

Re: [openstack-dev] [ironic] Hardware console processes in multi-conductor environment

Hi Yuriy, I like idea #4 (building task management functionality into a separate console driver). I think this was suggested at the PTG, and it's good because it fits into the existing model ironic has for handling console. Thanks, Mario On Fri, Mar 10, 2017 at 10:42 AM, Yuriy Zveryanskyy

Re: [openstack-dev] [ironic] OpenStack client default ironic API version

t;ruby@intel.com> wrote: > On 2017-03-06, 3:46 PM, "Mario Villaplana" <mario.villapl...@gmail.com> wrote: > > Hi ironic, > > At the PTG, an issue regarding the default version of the ironic API > used in our python-openstackclient plugin w

[openstack-dev] [ironic] OpenStack client default ironic API version

Hi ironic, At the PTG, an issue regarding the default version of the ironic API used in our python-openstackclient plugin was discussed. [0] In short, the issue is that we default to a very old API version when the user doesn't otherwise specify it. This limits discoverability of new features and

[openstack-dev] [ironic] Ironic review party invitation

Hi ironic team, Last cycle, I started holding some informal "review parties" for new members of OSIC [0] to come together with other OSIC people who had been working on OpenStack for a while and have group discussions about technical topics related to ironic and generally how to be more effective

Re: [openstack-dev] [ironic] End-of-Ocata core team updates

butor >> > activity. >> > >> > I have two candidates that look very good and pass the formal barrier of >> > 3 reviews a day on average [1]. >> > >> > First, Vasyl Saienko (vsaienk0). I'm pretty confident in him, his stats >> > [2]

Re: [openstack-dev] [ironic] Policy for deprecating metric names

/418589 Thanks, Mario [0] http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-3/%23openstack-meeting-3.2017-01-09.log.html#t2017-01-09T17:26:33 On Tue, Jan 3, 2017 at 5:11 PM, Mario Villaplana <mario.villapl...@gmail.com> wrote: > Hi all, > > Recently, Ruby found a patc

Re: [openstack-dev] [ironic] User survey question

Hi, Here are some questions I've thought of: TESTING / INTERESTED - What is your use case for ironic? - What, if anything, is preventing you from using ironic in a production environment? - What alternatives to ironic have you considered? USING - What new features would you like to see added

[openstack-dev] [ironic] Policy for deprecating metric names

Hi all, Recently, Ruby found a patch that modifies the name of a metric emitted by ironic. [0] After some IRC discussion, we realized that there is no real deprecation policy regarding changing metric names. [1] For anyone not familiar with this feature, ironic has the capability to emit various

Re: [openstack-dev] [ironic] [inspector] RFC: deprecating "set IPMI credentials" feature in ironic-inspector

Given that this seems to be a special case outside of what ironic-inspector normally handles, I'd be +1 to removing it. Perhaps this feature, if needed, is best implemented as a vendor passthru in ironic itself. Mario On Tue, Dec 13, 2016 at 7:40 AM, Dmitry Tantsur wrote:

Re: [openstack-dev] [openstack][ironic] Event processing for async task improvement

I agree with the strategy Yuriy outlined. This has the added benefit of mitigating potential future bugs related to callbacks in the task manager since state "rollback" behavior will be implicitly built into the task manager. Details on the potential race condition with provision state change

[openstack-dev] [ironic] OneView CI results not publicly viewable

Hi all, I discovered today that the OneView CI result links currently point to internal (10.*) IP addresses. See here for an example: https://review.openstack.org/#/c/372762/14 According to OpenStack's third-party testing requirements [0], third-party test artifacts should be public and retained

Re: [openstack-dev] [ironic] base node payload for notification

After some IRC discussion (http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2016-09-27.log.html#t2016-09-27T13:31:42), I'm +1 to this base payload, too. I vote we do this, and we can always update later if operators chime in with additional use cases that should be

Re: [openstack-dev] [Nova] notification subteam

Hi, I'll be working on adding notifications to Ironic and would also be interested in chatting about the direction of Nova notifications. I'm on US Central but usually work a little later to stay more in sync with the rest of the team, so 4pm-12am UTC would be best, but a bit earlier or later

Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a dashboard for Ironic‏

Hi! Just as an FYI, we use this for a dashboard: https://github.com/rackerlabs/onmetal-dashboard That might be useful when moving forward with using Horizon or the ironic-dashboard project. Mario On Thu, Jun 18, 2015 at 7:43 PM, niuzhenguo niuzhen...@huawei.com wrote: Hi Thai Q Tran,