Guys,
we are about to enable image based provisioning in our master by default.
I'm trying to figure out requirement for this change. As far as I know, it
was not tested on scale lab. Is it true? Have we ever run full system tests
cycle with this option?
Do we have any other pre-requirements?
Guys,
we've done a good job in 6.0. Most of the features were merged before
feature freeze. Our QA were involved in testing even earlier. It was much
better than before.
We had a discussion with Anastasia. There were several bug reports for
features yesterday, far beyond HCF. So we still have a
We have a high priority bug in 6.0:
https://bugs.launchpad.net/fuel/+bug/1401852. Here is the story.
Our openstack services use to send logs in strange format with extra copy
of timestamp and loglevel:
== ./neutron-metadata-agent.log ==
2014-12-12T11:00:30.098105+00:00 info: 2014-12-12
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.
Why we filter out some fields from keeper object in create and list
operations?
in module nova.api.openstack.compute.plugins.v3.keypairs
class KeypairController(wsgi.Controller):
# ...
def _filter_keypair(self, keypair, **attrs):
clean = {
'name': keypair.name,
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
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
, November 25, 2014, Dmitry Pyzhov dpyz...@mirantis.com wrote:
Thank you all for your feedback. Request postponed to the next release.
We will compare available solutions.
On Mon, Nov 24, 2014 at 2:36 PM, Vladimir Kuklin vkuk...@mirantis.com
wrote:
guys, there is already pxz utility in ubuntu repos
Just FYI. We have updated versions of nailgun-related packages in 6.0:
https://review.openstack.org/#/c/137886/
https://review.openstack.org/#/c/137887/
https://review.openstack.org/#/c/137888/
https://review.openstack.org/#/c/137889/
We need it in order to support packages updates both in
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
Vitaly,
It's there a document or spec or a wiki page that describes the current
status of this discussion in the context of the whole pluggable
architecture design?
Jumping into this thread without having the whole picture is hard. Knowing
what is already agreed, what is implemented so far, and
Evgeniy,
Thanks a lot!
On Mon, Nov 24, 2014 at 5:15 PM, Evgeniy L e...@mirantis.com wrote:
Hi Dmitry,
Our current validation implementation is based on jsonschema,
we will figure out how to hack/configure it to provide more human
readable message
Thanks,
On Mon, Nov 24, 2014 at 2:34 PM
:
1. It's not management. We're not changing anything.
2. I'm aware that some folks want to use discoverd-based discovery [2] even
for DRAC and ILO (e.g. for vendor-specific additions that can't be
implemented OOB).
Any ideas?
Dmitry.
[1] https://review.openstack.org/#/c/100951/
[2] https
Thank you all for your feedback. Request postponed to the next release. We
will compare available solutions.
On Mon, Nov 24, 2014 at 2:36 PM, Vladimir Kuklin vkuk...@mirantis.com
wrote:
guys, there is already pxz utility in ubuntu repos. let's test it
On Mon, Nov 24, 2014 at 2:32 PM,
:modulepath2
This will allow to add /etc/puppet/modules as module path and use resources
and functions form fuel-library.
P.S.:
puppet_modules: puppet/:/etc/puppet/moules/: - is not allowed by yaml
parser (and yaml format I believe)
Any suggestions here?
--
Kind regards
Dmitry Ukov
IT Engineer
Mirantis
://github.com/stackforge/fuel-web/blob/master/tasklib/tasklib/actions/puppet.py#L61-L62
Regards
--
Alex
On Mon, Nov 24, 2014 at 12:07 PM, Dmitry Ukov du...@mirantis.com wrote:
Hello All,
Current implementation of plugins in Fuel unpacks plugin tarball
into /var/www/nailgun/plugins/.
If we
invoke other manifests
Best,
Tatyana
On Mon, Nov 24, 2014 at 12:49 PM, Dmitry Ukov du...@mirantis.com wrote:
Unfortunately this does not work
cat tasks.yaml
# This tasks will be applied on controller nodes,
# here you can also specify several roles, for example
# ['cinder', 'compute
1. We discussed splitting fuel-web, I think we should do that before
relaxing code freeze rules for it.
2. If there are high or critical priority bugs in a component during soft
code freeze, all developers of that component should be writing, reviewing,
or testing fixes for these bugs.
3. If we
We have a request https://bugs.launchpad.net/fuel/+bug/1394487 for change
compression from gz to xz. This simple change halfs our snapshots. Does
anyone has any objections? Otherwise we will include this change in 6.0
release.
___
OpenStack-dev mailing
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
unrelated bugs has been an anti-pattern in our Launchpad bugs lately,
please take above into consideration when reporting bugs.
Thank you,
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
://blueprints.launchpad.net/fuel/+spec/pacemaker-improvements
Regards,
Aleksandr Didenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Dmitry Borodaenko
-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Dmitry Borodaenko
___
OpenStack
Oops, the last line should be read as
On the other side, it is a nice UX feature we really want to have 6.0
Dmitry
2014-11-15 3:50 GMT+03:00 Dmitry Mescheryakov dmescherya...@mirantis.com:
Dmitry,
Lets review the CR from the point of danger to current deployment process:
in the essence
Dmitry,
Lets review the CR from the point of danger to current deployment process:
in the essence it is 43 lines of change in puppet module. The module calls
a shell script which always returns 0. So whatever happens inside, the
deployment will not fail.
The only changes (non-get requests
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
On 11/12/2014 08:06 PM, Doug Hellmann wrote:
During our “Graduation Schedule” summit session we worked through the list of
modules remaining the in the incubator. Our notes are in the etherpad [1], but as
part of the Write it Down” theme for Oslo this cycle I am also posting a
summary of the
: Dmitry Tantsur [mailto:dtant...@redhat.com]
Sent: Thursday, November 13, 2014 2:20 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ironic] disambiguating the term discovery
On 11/12/2014 10:47 PM, Victor Lowther wrote:
Hmmm... with this thread in mind, anyone think
On 11/13/2014 01:15 PM, Lucas Alvares Gomes wrote:
This was discussed in the Contributor Meetup on Friday at the Summit
but I think it's important to share on the mail list too so we can get
more opnions/suggestions/comments about it.
In the Ironic weekly meeting we dedicate a good time of the
the change
should not be dangerous. Other files in the change are used in the shell
script only. Please consider reviewing and merging this though we've
already reached FF.
Thanks,
Dmitry
[1] https://review.openstack.org/#/c/132196/
[2]
https://blueprints.launchpad.net/mos/+spec/sahara-create
/openstack-dev
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
On 10/21/2014 02:11 AM, Devananda van der Veen wrote:
Hi all,
I was reminded in the Ironic meeting today that the words hardware
discovery are overloaded and used in different ways by different
people. Since this is something we are going to talk about at the
summit (again), I'd like to start
I'm agree with Dmitry. We can change version text. Use '2014.2-6.0-pre' in
openstack.yaml and '6.0-pre' in PRODUCT_VERSION. Yep, we need to test it
first. Also think about sorting on ui and other places where we can compare
versions.
On Mon, Oct 20, 2014 at 2:36 PM, Aleksandra Fedorova afedor
Hi Jim,
On 10/16/2014 07:23 PM, Jim Mankovich wrote:
All,
I would like to get some feedback on a proposal to change to the
current sensor naming implemented in ironic and ceilometer.
I would like to provide vendor specific sensors within the current
structure for IPMI sensors in ironic and
, Russia,
www.mirantis.com http://www.mirantis.ru/
www.mirantis.ru
vkuk...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Dmitry Borodaenko
as the plugin can contain mixins for the
wizard.
What do you think?
2014-10-09 11:04 GMT+07:00 Dmitry Borodaenko dborodae...@mirantis.com:
I don't like how this discussion is framed. The initial premise that we
have
only two controversial options to choose from is lazy
...@mirantis.com
wrote:
Hi,
Dima, that's really good approach.
Mike, technical writer may ask developer and assign bug to him/her if bug
impacts developer documentation only.
Best Regards,
Sergii Golovatiuk
On 08 Oct 2014, at 21:08, Mike Scherbakov mscherba...@mirantis.com
wrote:
Thanks Dmitry
Filtering bugs by tags works fine in advanced search, the only problem is
that you can't combine it with filtering by releases (since that's broken
in advanced search and you have to use milestone page for that).
On Thu, Oct 9, 2014 at 12:18 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote:
We
/
www.mirantis.ru
vkuk...@mirantis.com
--
Mike Scherbakov
#mihgen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Dmitry Borodaenko
At the moment OpenStack infrastructure doesn't allow to customize the
bugs it creates, we should propose a patch at some point to implement
that. When we do, I think we should assign such bugs automatically to
fuel-docs team.
I don't think we should separate user and dev docs bugs, we're working
On 10/02/2014 01:30 PM, Lucas Alvares Gomes wrote:
Hi,
I don't know if it's a known issue, but we have this patch in Ironic
here https://review.openstack.org/#/c/124610/ and the gate jobs for
python26 and python27 are failing because of some import error[1] and
it doesn't show me what is the
On 09/30/2014 02:03 PM, Soren Hansen wrote:
2014-09-12 1:05 GMT+02:00 Jay Pipes jaypi...@gmail.com:
If Nova was to take Soren's advice and implement its data-access layer
on top of Cassandra or Riak, we would just end up re-inventing SQL
Joins in Python-land.
I may very well be wrong(!), but
understanding that Ceph exposing Swift API is not affected though,
as it is strongly consistent.
Thanks,
Dmitry
2014-09-29 20:12 GMT+04:00 Jay Pipes jaypi...@gmail.com:
Hey Stackers,
So, I had a thought this morning (uh-oh, I know...).
What if we wrote a token driver in Keystone that uses Swift
On 09/25/2014 06:23 PM, Lucas Alvares Gomes wrote:
Hi,
Today we have hit the problem of having an outdated sample
configuration file again[1]. The problem of the sample generation is
that it picks up configuration from other projects/libs
(keystoneclient in that case) and this break the Ironic
Hello,
I used google docs to create the initial image. If you want to edit that
one, copy the doc[1] to your drive and edit it. It is not the latest
version of the image, but the only difference is that this one has the very
first project name EHO in place of Sahara.
Thanks,
Dmitry
[1]
https
On Tue, 2014-09-16 at 15:42 -0400, Zane Bitter wrote:
On 16/09/14 15:24, Devananda van der Veen wrote:
On Tue, Sep 16, 2014 at 11:44 AM, Zane Bitter zbit...@redhat.com wrote:
On 16/09/14 13:56, Devananda van der Veen wrote:
On Mon, Sep 15, 2014 at 9:00 AM, Steven Hardy sha...@redhat.com
On Wed, 2014-09-17 at 10:36 +0100, Steven Hardy wrote:
On Tue, Sep 16, 2014 at 02:06:59PM -0700, Devananda van der Veen wrote:
On Tue, Sep 16, 2014 at 12:42 PM, Zane Bitter zbit...@redhat.com wrote:
On 16/09/14 15:24, Devananda van der Veen wrote:
On Tue, Sep 16, 2014 at 11:44 AM, Zane
On Mon, 2014-09-15 at 11:04 -0700, Jim Rollenhagen wrote:
On Mon, Sep 15, 2014 at 12:44:24PM +0100, Steven Hardy wrote:
All,
Starting this thread as a follow-up to a strongly negative reaction by the
Ironic PTL to my patches[1] adding initial Heat-Ironic integration, and
subsequent
point of view it changes almost nothing, it just adds
a bit more discussion items on the management side and slight
modifications
to our checklists.
On Tue, Sep 9, 2014 at 5:55 AM, Dmitry Borodaenko
dborodae...@mirantis.com wrote:
TL;DR: Yes, our work on 6.0 features is currently blocked
this as a bug or this blueprint will be implemented in
the nearest future?
--
Kind regards
Dmitry Ukov
IT Engineer
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
a separate decision on
branching without enforcing all HCF criteria.
From the DevOps point of view it changes almost nothing, it just adds a
bit more discussion items on the management side and slight modifications to
our checklists.
On Tue, Sep 9, 2014 at 5:55 AM, Dmitry Borodaenko
dborodae
at 5:55 AM, Dmitry Borodaenko
dborodae...@mirantis.com wrote:
TL;DR: Yes, our work on 6.0 features is currently blocked and it is
becoming a major problem. No, I don't think we should create
pre-release or feature branches. Instead, we should create stable/5.1
branches and open master for 6.0
a separate series 'docs' in launchpad (it is
the thing like '5.0.x', '5.1.x'). If bug affects several series, a
different engineer could be assigned on each of them. So doc team will
be free to assign bugs to themselves within this new series.
Mike Scherbakov and Dmitry Borodaenko objected creating
?
Thanks,
Dmitry
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
) instead of just one (master). This
will require additional effort, but I think that it is significantly
smaller than the cost of spinning our wheels on 6.0 efforts.
-DmitryB
On Mon, Sep 8, 2014 at 10:10 AM, Dmitry Mescheryakov
dmescherya...@mirantis.com wrote:
Hello Fuelers,
Right now we have
Dmitry,
I totally agree that we should support nightly builds in upgrades. I've
created a blueprint for this:
https://blueprints.launchpad.net/fuel/+spec/upgrade-nightly
On Tue, Sep 2, 2014 at 3:24 AM, Dmitry Borodaenko dborodae...@mirantis.com
wrote:
We should not confuse beta and rc builds
Feature blockers:
Versioning https://blueprints.launchpad.net/fuel/+spec/nailgun-versioning
for REST API
https://blueprints.launchpad.net/fuel/+spec/nailgun-versioning-api, UI,
serialization
https://blueprints.launchpad.net/fuel/+spec/nailgun-versioning-rpc
Ongoing activities:
Nailgun plugins
backlog.
Image based provisioning should make it much easier to support.
My 2c,
-Dmitry
I would not use beta word anywhere at all. These are nightly builds,
pre-5.1. So it will become 5.1 eventually, but for the moment - it is just
master branch. We've not even reached HCF.
After we reach HCF, we
-specs with
detailed feature description.
According to this feature, we are going to switch our CI system to
lrzipped tarballs.
[1] https://review.openstack.org/#/c/116874/
On Thu, Aug 21, 2014 at 5:50 PM, Dmitry Pyzhov dpyz...@mirantis.com
wrote:
Fuelers,
Our upgrade tarball for 5.1
All,
I'm not sure if it deserves to be mentioned in our documentation, this
seems to be a common practice. If an administrator wants to patch his
environment, he should be prepared for a temporary downtime of OpenStack
services. And he should plan to perform patching in advance: choose a time
It is not enough, you need to review requirements in the code of nailgun,
ostf and astute.
I'll be happy to have our requirements files and specs as close to
global-requirements as possible. It will ruin our current solid structure,
where we have same versions of dependencies on production, on
Fuelers,
Our upgrade tarball for 5.1 is more than 4.5Gb. We can reduce it size by
2Gb with lrzip tool (ticket
https://bugs.launchpad.net/fuel/+bug/1356813, change
in build system https://review.openstack.org/#/c/114201/, change in docs
https://review.openstack.org/#/c/115331/), but it will
possible solutions to this issue?
On Thu, Aug 21, 2014 at 5:50 PM, Dmitry Pyzhov dpyz...@mirantis.com
wrote:
Fuelers,
Our upgrade tarball for 5.1 is more than 4.5Gb. We can reduce it size by
2Gb with lrzip tool (ticket
https://bugs.launchpad.net/fuel/+bug/1356813, change in build system
, which is good especially for new users.
Thanks,
Dmitry
2014-08-15 18:04 GMT+04:00 mike mccune mimcc...@redhat.com:
thanks for the thoughts Trevor,
On 08/15/2014 09:32 AM, Trevor McKay wrote:
I think backward compatibility is a good idea. We can make the
user/pass inputs for data objects
Hello!
I've published parallels-sdk:
https://github.com/Parallels/parallels-sdk
--
Dmitry Guryanov
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Monday 18 August 2014 22:45:17 Dmitry Guryanov wrote:
Hello!
I've published parallels-sdk:
https://github.com/Parallels/parallels-sdk
Sorry, I've sent this mail to the wrong list :(, please, ignore.
--
Dmitry Guryanov
___
OpenStack-dev
We've moved all blueprints from 6.0 to 'next' milestone. It has been done
in order to better view of stuff that we really want to implement in 6.0.
Feature freeze for 6.0 release is planned to 18th of September. If you are
going to merge your blueprint before that date, you can move it to 6.0
assignees are confirmed.
On Mon, Aug 11, 2014 at 8:30 AM, Dmitry Pyzhov dpyz...@mirantis.com wrote:
We've moved all blueprints from 6.0 to 'next' milestone. It has been done in
order to better view of stuff that we really want to implement in 6.0.
Feature freeze for 6.0 release is planned to 18th
on making exception for power driver, but -0 on the
others, until I see a separate spec for them.
Dmitry.
On Thu, 2014-08-07 at 09:30 +0530, GopiKrishna Saripuri wrote:
Hi,
I've submitted Ironic Cisco driver blueprint post proposal freeze
date. This driver is critical for Cisco and few
Hi!
On Tue, 2014-08-05 at 12:33 -0700, Devananda van der Veen wrote:
Hi all!
The following idea came out of last week's midcycle for how to improve
our spec process and tracking on launchpad. I think most of us liked
it, but of course, not everyone was there, so I'll attempt to write
out
in OpenStack's zuul which triggers each time it sees
'recheck' word, so the only fast way to fix it is to get rid of that
ambiguous keyword.
--
Thanks,
Dmitry Teselkin
Deployment Engineer
Mirantis
http://www.mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev
on these bugs, but nobody replied. How is it
possible, to close them?
--
Dmitry Guryanov
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Monday 04 August 2014 17:53:11 Tom Fifield wrote:
On 04/08/14 17:46, Dmitry Guryanov wrote:
Hello!
I looked through launchpad bugs and it seems there are a lot of bugs,
which are fixed already, but still open, here are 3 ones:
https://bugs.launchpad.net/nova/+bug/909096
Hi!
On Thu, 2014-07-31 at 10:45 +0100, Chris Dent wrote:
One of the things I like to be able to do when in the middle of making
changes is sometimes run all the tests to make sure I haven't accidentally
caused some unexpected damage in the neighborhood. If I have I don't
want the tests to all
Hi!
This list is not for usage question, it's for OpenStack developers. The
best way to get a quick help should be using
https://ask.openstack.org/en/questions/ or joining #openstack on
Freenode and asking there.
Good luck!
On Thu, 2014-07-31 at 15:59 +0530, shailendra acharya wrote:
hello
)
---
Primary assignee:
dguryanov
Work Items
--
To be filled
Dependencies
None
Testing
===
To be filled
Documentation Impact
None
References
==
Parallels Cloud Server: http://www.parallels.com/products/pcs/.
--
Dmitry
-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
need to clean out related .pyc
files from /usr/lib/python2.7/dist-packages/nova/.
On Wed, Jul 16, 2014 at 11:22 PM, Dennis Kramer (DT) den...@holmes.nl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Dmitry,
I've been using Ubuntu 14.04LTS + Icehouse /w CEPH as a storage
backend
The meeting is in 2 hours, so you still have a chance to particilate
or at least lurk :)
On Wed, Jul 16, 2014 at 11:55 PM, Somhegyi Benjamin
somhegyi.benja...@wigner.mta.hu wrote:
Hi Dmitry,
Will you please share with us how things went on the meeting?
Many thanks,
Benjamin
on ceph-users ML:
http://lists.ceph.com/pipermail/ceph-users-ceph.com/2014-March/028097.html
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
+1, much awaited!
On Fri, 2014-07-11 at 15:50 -0700, Devananda van der Veen wrote:
Hi all!
It's time to grow the team :)
Jim (jroll) started working with Ironic at the last mid-cycle, when
teeth became ironic-python-agent. In the time since then, he's
jumped into Ironic to help
+1
On Fri, 2014-07-11 at 15:50 -0700, Devananda van der Veen wrote:
Hi all!
While David (Shrews) only began working on Ironic in earnest four
months ago, he has been working on some of the tougher problems with
our Tempest coverage and the Nova-Ironic interactions. He's also
become
On Monday 07 July 2014 16:11:21 Joe Gordon wrote:
On Jul 3, 2014 11:43 AM, Dmitry Guryanov dgurya...@parallels.com wrote:
Hi, All!
As far as I know, there are some requirements, which virt driver must
meet to
use Openstack 'label'. For example, it's not allowed to mount cinder
On Thursday 10 July 2014 14:47:11 Daniel P. Berrange wrote:
On Thu, Jul 10, 2014 at 05:36:59PM +0400, Dmitry Guryanov wrote:
I have a question about mounts - in OpenVZ project each container has its
own filesystem in an image file. So to start a container we mount this
filesystem in host OS
mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
environments of the same version. So we should check and warn user about
it, or simply not allow to delete releases if there are live envs with the
same version.
On Thu, Jul 3, 2014 at 3:45 PM, Dmitry Pyzhov dpyz...@mirantis.com
wrote:
So, our releases will have following versions
.
On Tue, Jun 24, 2014 at 5:14 PM, Dmitry Pyzhov dpyz...@mirantis.com
wrote:
Guys,
We have a beautiful contribution guide:
https://wiki.openstack.org/wiki/Fuel/How_to_contribute
However, I would like to address several issues in our blueprints/bugs
processes. Let's discuss and vote on my
@DmitryB, it have to be 2014.1-5.0.1. Am I right?
Thanks,
Igor
On Tue, Jul 1, 2014 at 8:47 PM, Aleksandr Didenko adide...@mirantis.com
wrote:
Hi,
my 2 cents:
1) Fuel version (+1 to Dmitry)
2) Could you please clarify what exactly you mean by our patches / our
first patch?
On Tue
(developed outside of nova mainline) works
correctly and meet nova's security requirements?
--
Dmitry Guryanov
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Again, thanks everyone who have joined Sahara meeting. Below are the
logs from the meeting.
Minutes:
http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-07-03-18.06.html
Logs:
http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-07-03-18.06.log.html
Thanks,
Dmitry
On Thu, Jul 3, 2014 at 7:05 AM, Aleksandr Didenko adide...@mirantis.com wrote:
I think we should allow user to delete unneeded releases.
In this case user won't be able to add new nodes to the existing
environments of the same version. So we should check and warn user about it,
or simply not
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
is not high enough to do
a backport), mark it Won't Fix for that series.
If there are no objections to this approach, I'll put it in Fuel wiki.
Thanks,
-DmitryB
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
Guys,
We are going to merge feature groups
https://blueprints.launchpad.net/fuel/+spec/feature-groups, it will cause
small changes in iso build parameters.
MIRANTIS parameter is deprecated, please use FEATURE_GROUPS=mirantis
instead.
Another available feature group is 'experimental'. Without it
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thanks,
Dmitry Teselkin
Deployment Engineer
Mirantis
http://www.mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
901 - 1000 of 1117 matches
Mail list logo
