Congratulations, Vladimir, that's a huge step in a right direction for Fuel.
--
Best regards,
Oleg Gelbukh
On Wed, Sep 7, 2016 at 6:47 AM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Dear colleagues,
>
> I'm glad to announce that we have working BVT jobs on
+1 here
Sergey's performance and quality of the code he submitted are impressive.
Please, keep going.
--
Best regards,
Oleg Gelbukh
On Thu, Jul 21, 2016 at 10:21 AM, Artur Svechnikov <asvechni...@mirantis.com
> wrote:
> +1
>
> Best regards,
> Svechnikov Artur
>
> On Th
Jeremy, thank you, that's excellent news. The Infra team is doing awesome
work to improve the processes in all possible ways.
Andreas, I will take a closer look, but it seems to be exactly what I had
in mind. Thanks for sharing!
--
Best regards,
Oleg Gelbukh
On Fri, Apr 15, 2016 at 10:29 AM
The thread I'm referring to in the prev message is:
http://lists.openstack.org/pipermail/openstack-infra/2014-January/000624.html
--
Best regards,
Oleg Gelbukh
Mirantis Inc.
On Thu, Apr 14, 2016 at 12:56 PM, Oleg Gelbukh <ogelb...@mirantis.com>
wrote:
> Hi,
>
> I'm sor
to differentiate
pre-release versions from main releases.
Another option here is to publish minor versions of the package, i.e. start
with 9.0.0 early, and then increase to 9.0.1 etc once the development
progresses.
--
Best regards,
Oleg Gelbukh
Mirantis Inc.
On Thu, Jan 21, 2016 at 11:52 AM
consumer role in the deployment data pipeline.
--
Best regards,
Oleg Gelbukh
On Fri, Apr 1, 2016 at 1:37 PM, Bogdan Dobrelya <bdobre...@mirantis.com>
wrote:
> On 04/01/2016 10:41 AM, Oleg Gelbukh wrote:
> > Andrew,
> >
> > This is an excellent idea. It is apparently m
upload of deployment configuration to ConfigDB API
<https://review.openstack.org/286012>
--
Best regards,
Oleg Gelbukh
On Thu, Mar 31, 2016 at 11:19 PM, Andrew Woodward <xar...@gmail.com> wrote:
> One of the problems we've faced with trying to plug-in ConfigDB is trying
> to separate the
to thank the community for the trust you've put in us. Hope we
laid a foundation for more flexible and modular architecture for the future
Fuel versions.
Sorry for the delay with this heads up.
[1] https://git.openstack.org/openstack/tuning-box.git
--
Best regards,
Oleg Gelbukh
On Fri, Mar 4
/stevedore-extensions-discovery
--
Best regards,
Oleg Gelbukh
Mirantis Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
be useful to make separation along
those lines as well.
[1] https://etherpad.openstack.org/p/fuel-release-definition
--
Best regards,
Oleg Gelbukh
On Thu, Feb 11, 2016 at 12:02 PM, Aleksandr Didenko <adide...@mirantis.com>
wrote:
> Hi,
>
> > So what is open? The composition laye
. If no objections, I will
create a corresponding bug/blueprint against fuelclient to be fixed in the
current release cycle.
--
Best regards,
Oleg Gelbukh
Mirantis
__
OpenStack Development Mailing List (not for usage questions
elements of the snapshot and exclude them
based on the priorities or user choice.
This will allow for better and safer UX with the snapshot.
--
Best regards,
Oleg Gelbukh
On Tue, Jan 12, 2016 at 1:47 PM, Maciej Kwiek <mkw...@mirantis.com> wrote:
> Hi!
>
> I need some advice o
Sergii,
Nailgun will still have data of clusters with old releases, should they be
in the database backup. And it still has to be able to manage them.
--
Best regards,
Oleg Gelbukh
On Tue, Dec 22, 2015 at 11:58 AM, Sergii Golovatiuk <
sgolovat...@mirantis.com> wrote:
> Hi,
>
&
their changes through the pipeline. Although this is
pure implementation detail and is not really important ATM.
The point is that for Solar integration, we still need integration points,
and the less of them we have, the more simple the transition is going to
be..
--
Best regards,
Oleg Gelbukh
On Mon
time (i.e. don't require code changes).
Important 'pro' having ConfigDB separate from Solar is that it will
simplify transition from current Fuel architecture by breaking it into more
definite stages and reducing the number of components Solar have to be
integrated with.
--
Best regards,
Oleg
In fact, it seems that 9.2 is in the mix since the introduction of centos7.
Thus, all tests that have been made since then are made against 9.2. So,
upgrading it to 9.3 actually is a change that has to be blocked by FF/SCF.
Just my 2c.
--
Best regards,
Oleg Gelbukh
On Thu, Dec 17, 2015 at 12:13
klin,
>
> I'm not sure what do you mean by "fixing 2 different environments"? With
> environment without
> containers it will simplify debugging process.
>
> Thanks,
>
> On Wed, Dec 16, 2015 at 10:12 PM, Oleg Gelbukh <ogelb...@mirantis.com>
> wrote:
>
>&
done
and submitted for review, so it could be merged fast before any other
significant changes land in 'master' after it is open.
--
Best regards,
Oleg Gelbukh
On Wed, Dec 16, 2015 at 8:56 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Vladimir,
>
> I have other act
] https://bugs.launchpad.net/fuel/+bug/1503663/comments/10
--
Best regards,
Oleg Gelbukh
On Tue, Dec 15, 2015 at 8:58 PM Dmitry Klenov <dkle...@mirantis.com> wrote:
> Hi folks,
>
> I would propose to keep current versioning schema until fuel release
> schedule is fully alig
the
number of packages maintained in-house.
Depending on native packages is also important in the light of the
initiative to separate deployment of Fuel from installation of operating
system [1].
[1]
https://blueprints.launchpad.net/fuel/+spec/separate-fuel-node-provisioning
--
Best regards,
Oleg
Roman,
Changing arbitrary parameters supported by respective Puppet manifests for
OpenStack services is implemented in this blueprint [1]. It is being landed
in release 8.0.
[1] https://blueprints.launchpad.net/fuel/+spec/openstack-config-change
--
Best regards,
Oleg Gelbukh
On Thu, Dec 3
for running
base Fuel as it's dependencies (or dependencies of it's dependencies, as it
could be more complicated with cross-deps between our components).
--
Best regards,
Oleg Gelbukh
On Fri, Dec 11, 2015 at 10:45 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Dear c
behaviours.
--
Best regards,
Oleg Gelbukh
On Mon, Dec 7, 2015 at 9:29 PM, Eugene Korekin <ekore...@mirantis.com>
wrote:
> Stas,
>
> I fear that often even developer of a code cannot verify his own code
> completely, let alone some third-party validation teams. Does the ability
&
Roman,
Thank you. This is great research.
Could we have a conversation to discuss this? I'm especially interested in
idempotency problems of the fuel-library modules and the common way to
provide serialised data to the deployment.
--
Best regards,
Oleg Gelbukh
Mirantis Inc
On Tue, Dec 1, 2015
That's good to know, thank you, Vladimir, Dmitry.
--
Best regards,
Oleg Gelbukh
On Tue, Nov 24, 2015 at 3:10 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> In fact, we (I and Dmitry) are on the same page of how to merge these two
> features (Centos7 and Docker removal
Please, take into account the plan to drop the containerization of Fuel
services:
https://review.openstack.org/#/c/248814/
--
Best regards,
Oleg Gelbukh
On Tue, Nov 24, 2015 at 12:25 AM, Dmitry Teselkin <dtesel...@mirantis.com>
wrote:
> Hello,
>
> We've been working for some t
With CentOS7 we will have python2.7 at Fuel Admin node as a default
version, I believe.
--
Best regards,
Oleg Gelbukh,
Principal Engineer
Mirantis
On Fri, Nov 20, 2015 at 6:27 AM, Timur Nurlygayanov <
tnurlygaya...@mirantis.com> wrote:
> Hi Andrey,
>
> As far as I remember from
It's a good point.
I think it could even be done automatically: once spec freeze is in place,
run an infra script and update all CRs still in review with specs targeted
to current (and previous) releases by moving them to next release's
directory.
-Oleg
On Fri, Nov 20, 2015 at 3:35 PM, Igor
it in the following blueprint:
https://blueprints.launchpad.net/fuel/+spec/upgrade-master-node-centos7
--
Best regards,
Oleg Gelbukh
On Tue, Nov 10, 2015 at 8:52 AM, Vladimir Kuklin <vkuk...@mirantis.com>
wrote:
> Evgeniy
>
> I am not sure you addressed me, but, anyway, - ye
course, and might change in the
development. Its additional value that backup/restore parts of it could be
used separately to create backups of the Fuel node.
Our current plan is to pursue option #2 in the following 3 weeks. I will
keep this list updated on our progress as soon as we have any.
--
> for
> backup/restore actions.
>
We're working to determine if we need to backup/upgrade containers at all.
My expectation is that we should be OK with just backup of DB, IP addresses
settings from astute.yaml for the master node, and credentials from
configuration files for the services
ng on two problems in one feature:
> backups and upgrades.
>
That will ease development, testing and also reduce feature creep.
>
Alexander, +1 on this.
--
Best regards,
Oleg Gelbukh
>
> P.S.
> It is hard to refer to (2) because You have thee (2)-s.
>
> On Fri, Nov 6, 2015 at
/operations.html#howto-backup-and-restore-fuel-master
--
Best regards,
Oleg Gelbukh
On Fri, Nov 6, 2015 at 6:03 PM, Matthew Mosesohn <mmoses...@mirantis.com>
wrote:
> Oleg,
>
> All the volatile information, including a DB dump, are contained in the
> small Fuel Master ba
oposed shall provide API that must support:
1. CRUD configuration schema (view template) and dynamically create/update
2. CRUD views based on registered templates for the component (ideally
there should be 1 to 1 template/component relation)
3. automatic resolution and update of links between certain par
/openstack/fuel-web/blob/master/nailgun/nailgun/objects/serializers/node.py#L124-L126
--
Best regards,
Oleg Gelbukh
On Mon, Oct 19, 2015 at 6:34 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:
> Oleg,
>
> I think we can remove this function for new releases and keep them
>
it out as a specification in Fuel specs
repository. I will greatly appreciate any feedback on this vision,
including comments, objections, concerns and questions.
--
Best regards,
Oleg Gelbukh
On Tue, Oct 20, 2015 at 2:13 PM, Vladimir Kuklin <vkuk...@mirantis.com>
wrote:
> Folks
&
ta calculations
are lazy, I don't really see how one can introspect into changes that will
be applied by a component at any given run. You just don't have this
information, and you need to calculate it anyways to see which settings
will be passed to a component. Might be I got your point wrong h
After closer look, the only viable option in closer term seems to be
'liberty-8.0' version. It does not to break comparisons that exist in the
code and allows for smooth transition.
--
Best regards,
Oleg Gelbukh
On Fri, Oct 16, 2015 at 5:35 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
.
-Oleg
On Sat, Oct 17, 2015 at 10:24 PM, Sergii Golovatiuk <
sgolovat...@mirantis.com> wrote:
> Why can't we use 'liberty' without 8.0?
>
> On Sat, 17 Oct 2015 at 19:33, Oleg Gelbukh <ogelb...@mirantis.com> wrote:
>
>> After closer look, the only viab
is to move away from using OpenStack version as a
part of Fuel version. Then the path to install the fuel-library will be
'/etc/puppet/8.0.0/'.
--
Best regards,
Oleg Gelbukh
On Fri, Oct 16, 2015 at 12:45 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:
> Hey Oleg,
>
> I've r
Igor,
Got your question now. Coordinated point (maintenance) releases are
dropped. [1] [2]
[1] http://lists.openstack.org/pipermail/openstack-dev/2015-May/065144.html
[2]
https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fliberty_releases
--
Best regards,
Oleg Gelbukh
On Fri
] http://ttx.re/new-versioning.html
[2] https://review.openstack.org/#/c/234296/
--
Best regards,
Oleg Gelbukh
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
/groups/1020,members
--
Best regards,
Oleg Gelbukh
On Sun, Sep 20, 2015 at 11:56 PM, Mike Scherbakov <mscherba...@mirantis.com>
wrote:
> Hi all,
> as of my larger proposal on improvements to code review workflow [1], we
> need to have cores for repositories, not for the whole Fuel. It i
The reason people want offline deployment feature is not because of poor
connection, but rather the enterprise intranets where getting subnet with
external access sometimes is a real pain in various body parts.
--
Best regards,
Oleg Gelbukh
On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky
patching' is actually a bad practice for any environments other than dev
ones. It immediately leads to emergence of unsupportable frankenclouds. I
would greet any modification to the workflow that will discourage people
from doing that.
--
Best regards,
Oleg Gelbukh
On Wed, Sep 9, 2015 at 5:56 PM, Alex
] https://review.openstack.org/#/c/202969/
[3] https://review.openstack.org/#/c/203536/
--
Best regards,
Oleg Gelbukh
On Mon, Aug 3, 2015 at 2:47 PM, Eugene Bogdanov ebogda...@mirantis.com
wrote:
Oleg, thanks for the provided information. As discussed verbally, most
core reviewers are now busy
effectively will move the
due date to Aug 3rd.
[1] https://bugs.launchpad.net/fuel/+bug/1480228
--
Best regards,
Oleg Gelbukh
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
'fuel', or rather switch it to fuel2
syntax, IMO, is the possibility that someone somewhere uses its current
syntax for automation. However, if the function is completely new, the
automation of this function should be implemented with the new version of
syntax.
--
Best regards,
Oleg Gelbukh
On Fri
The problem is that hostnames of nodes appear in /etc/hosts files, and
entries in those files have to be unique to make any sense. Thus, we either
need to provide a user with ability to create their own generators of node
names (not sure that's makes sense), require a user to provide a name for
like 'node reinstallation'
feautre [1].
[1] https://blueprints.launchpad.net/fuel/+spec/mos-node-reinstallation
--
Best regards,
Oleg Gelbukh
On Fri, Jul 24, 2015 at 12:07 PM, Evgeniy L e...@mirantis.com wrote:
Hi Andrew,
I don't agree with you, user should be able to name the node any way he
/203537/
[3] https://review.openstack.org/#/c/203536/
--
Best regards,
Oleg Gelbukh
On Fri, Jul 24, 2015 at 3:26 PM, Aleksey Kasatkin akasat...@mirantis.com
wrote:
+1 for an exception. Do we have time estimate though?
Aleksey Kasatkin
On Fri, Jul 24, 2015 at 2:46 PM, Sebastian Kalinowski
Unless I am mistaken, it is possible to set most of the parameters
supported by Fuel menu as kernel boot parameters. Isn't it sufficient
replacement for fuelmenu for dev's purposes?
-Oleg
On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn mmoses...@mirantis.com
wrote:
How much effort are we
anticipate with this kind of approach?
Another question that is still unclear to me is if someone really needs
support for a hybrid use case when the new and existing unmounted OSD
devices are mixed in one OSD node?
--
Best regards,
Oleg Gelbukh
://review.openstack.org/#/q/topic:bp/volume-manager-refactoring,n,z
--
Best regards,
Oleg Gelbukh
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
Nicely put, Doug, you gave me laughs :)
I can't see how a CR could hang for a month without anyone paying attention
if it worths merging. If this really happens (which I'm not aware of),
auto-abandon definitely won't make things any worse.
--
Best regards,
Oleg Gelbukh
On Fri, Jul 17, 2015 at 6
the upgrade?
--
Best regards,
Oleg Gelbukh
On Thu, Jul 16, 2015 at 11:46 AM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
By the way, first step for this to happen is to move
stackforge/fuel-web/fuel_upgrade_system into a separate repository.
Fortunately, this directory is not the place where
Vladimir,
Thank you, now it sounds concieving.
My understanding that at the moment all Docker images used by Fuel are
packaged in single RPM? Do you plan to split individual images into
separate RPMs?
Did you think about publishing those images to Dockerhub?
--
Best regards,
Oleg Gelbukh
Vladimir,
Good, thank you for extended answer.
--
Best regards,
Oleg Gelbukh
On Thu, Jul 16, 2015 at 3:30 PM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
Oleg,
Yes, you are right. At the moment all docker containers are packaged into
a single rpm package. Yes, it would be great
Nice work, Vladimir. Thank you for pushing this, it's really important step
to decouple things from consolidated repository.
--
Best regards,
Oleg Gelbukh
On Wed, Jul 15, 2015 at 6:47 PM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
I'm glad to announce that everything about this task
with explicitly frozen mirror which
is created by one 'pip install ' run than to play with implicit transitive
dependencies.
On Mon, Jul 13, 2015 at 11:58 AM, Oleg Gelbukh ogelb...@mirantis.com
wrote:
Some comments inline.
On Mon, Jul 13, 2015 at 9:24 AM, Bartlomiej Piotrowski
bpiotrow
the test
requirements failure, and it should pinned in 'test-requirements.txt' or in
requirements of our test suits.
--
Best regards,
Oleg Gelbukh
BP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
And I realized all of a sudden that even more interesting than unittest
framework itself would be some analog of Python mock for shell scripts.
Though I doubt that anyone ever really gone that far.
--
Best regards,
Oleg Gelbukh
On Thu, Jul 9, 2015 at 5:12 PM, Jeremy Stanley fu...@yuggoth.org
regards,
Oleg Gelbukh
On Wed, Jun 17, 2015 at 1:03 PM, Oleg Gelbukh ogelb...@mirantis.com wrote:
As this topic is getting some traction, I will register corresponding
blueprint in Fuel and try to decompose the work based on what Andrew
proposed.
--
Best regards,
Oleg Gelbukh
On Tue, Jun 16
As this topic is getting some traction, I will register corresponding
blueprint in Fuel and try to decompose the work based on what Andrew
proposed.
--
Best regards,
Oleg Gelbukh
On Tue, Jun 16, 2015 at 3:54 PM, Oleg Gelbukh ogelb...@mirantis.com wrote:
Andrew,
I've also noticed
to
understand justifications for them.
--
Best regards,
Oleg Gelbukh
On Mon, Jun 15, 2015 at 4:21 PM, Andrew Woodward awoodw...@mirantis.com
wrote:
I think there is some desire to see more documentation around here as
there are some odd interactions with parts of the data payload, and perhaps
as a tribal
knowledge.
I would like to understand if there is a need in such a document among
developers and deployers who consume Fuel API? Or might be there is already
such document or effort to create it going on?
--
Best regards,
Oleg Gelbukh
Excellent, nice to know that we're on the same page about this.
Thank you!
--
Best regards,
Oleg Gelbukh
On Wed, May 27, 2015 at 12:22 PM, Roman Prykhodchenko m...@romcheg.me wrote:
Oleg,
Thanks for the feedback. I have the following as a response:
1. This spec is just an excerpt
= SELECT status,count(status) FROM nodes GROUP BY status;
discover|1
ready|5
What do you think about making it a method rather then an element of data
model? Or that's exactly the complexity you want to get rid of?
--
Best regards,
Oleg Gelbukh
On Tue, May 26, 2015 at 4:16 PM, Roman Prykhodchenko m
to
'operational' when all nodes in it become 'ready', no matter how they were
deployed (i.e. via Web UI or CLI).
--
Best regards,
Oleg Gelbukh
On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko m...@romcheg.me wrote:
Hi folks!
Recently I encountered an issue [1] that the Deploy Changes button
?
--
Best regards,
Oleg Gelbukh
On Fri, May 15, 2015 at 5:39 PM, Roman Prykhodchenko m...@romcheg.me wrote:
Hi folks!
I’m glad to announce that the first independent release of Fuel Client was
published to PyPi: https://pypi.python.org/pypi/python-fuelclient
You can either download it from the web
Aleksey,
Thank you for clarification. Personally, I'm more interested in IP-based
display/grouping/filtering of deployed nodes.
And yes, it would be super-useful to have filtering in back-end and API,
not only in UI.
--
Best regards,
Oleg
On Fri, Feb 20, 2015 at 12:30 PM, Aleksey Kasatkin
(including Management and Public addresses) in the UI
and group/sort by those addresses.
--
Best regards,
Oleg Gelbukh
Mirantis Labs
On Sat, Feb 14, 2015 at 11:27 AM, Julia Aranovich jkirnos...@mirantis.com
wrote:
Hi All,
Currently we [Fuel UI team] are planning the features of *sorting
,
--
Best regards,
Oleg Gelbukh
Mirantis Labs
On Tue, Jan 27, 2015 at 10:55 PM, Andrew Woodward xar...@gmail.com wrote:
I don't see this as crazy, it's not a feature of the cloud, its a
mechanism to get us there. It's not even something that most of the
time anyone sees. Continuing to waste time
cleanup the
Master node.
--
Best regards,
Oleg Gelbukh
On Tue, Nov 4, 2014 at 3:26 PM, Przemyslaw Kaminski pkamin...@mirantis.com
wrote:
Hello,
In extension to my comment in this bug [1] I'd like to discuss the
possibility of adding Fuel master node monitoring. As I wrote in the
comment, when
with this?
And in the case of something like Nova, what about the many other nodes
behind the API server?
A query for configuration could be a part of /hypervisors API extension. It
doesn't solve multiple API servers issue though.
--
Best regards,
Oleg Gelbukh
Hi,
To proceed with this, I have sent (presumably) appropriate change to
review: https://review.openstack.org/#/c/103516/
--
Best regards,
Oleg Gelbukh
On Fri, Jun 27, 2014 at 6:40 PM, Jay Pipes jaypi...@gmail.com wrote:
Sure, why not? :)
On 06/27/2014 06:25 AM, Oleg Gelbukh wrote
Renat,
As far as I can tell, it is de-facto standard to not place anything at all
to __init__.py across the majority of OpenStack projects.
--
Best regards,
Oleg Gelbukh
On Mon, Jun 30, 2014 at 3:50 PM, Renat Akhmerov rakhme...@mirantis.com
wrote:
Hi,
What would be your opinion
Hello,
As our commits consistently pass py33 tests for last month (although not so
many changes were made), I propose to enable py33 job voting on
stackforge/rubick repository.
What do you think?
--
Best regards,
Oleg Gelbukh
___
OpenStack-dev mailing
will make their way into Scheduler service eventually.
--
Best regards,
Oleg Gelbukh
On Wed, Apr 9, 2014 at 7:47 PM, Jay Lau jay.lau@gmail.com wrote:
@Oleg, Till now, I'm not sure the target of Gantt, is it for initial
placement policy or run time policy or both, can you help clarify
be considered another facet of this
'runtime monitoring' functionality? Now it is a combination of Heat and
Ceilometer. Does it worth moving to hypothetical runtime mobility service
as well?
--
Best regards,
Oleg Gelbukh
--
Best regards,
Oleg Gelbukh
On Wed, Apr 9, 2014 at 7:47 PM, Jay Lau
Henrique,
You should check out Gantt project [1], it could be exactly the place to
implement such features. It is a generic cross-project Scheduler as a
Service forked from Nova recently.
[1] https://github.com/openstack/gantt
--
Best regards,
Oleg Gelbukh
Mirantis Labs
On Wed, Apr 9, 2014
What does PL stand for, anyway?
--
Best regards,
Oleg Gelbukh
On Mon, Mar 24, 2014 at 11:39 AM, Serg Melikyan smelik...@mirantis.comwrote:
because 'dsl'/'language' terms are too broad.
Too broad in general, but we choose name for sub-package, and in murano
term 'language' mean Murano PL
Sergey,
What do you think about adoption of/integration with other types of
resource definition languages used in OpenStack, for example, Heat
Orchestration Templates?
--
Best regards,
Oleg Gelbukh
On Thu, Feb 27, 2014 at 6:31 PM, Sergey Skripnick
sskripn...@mirantis.comwrote:
Hello
+1 for Hugh, he's doing excellent job moving the project forward.
--
Best regards,
Oleg Gelbukh
On Wed, Feb 5, 2014 at 2:22 PM, Sergey Skripnick sskripn...@mirantis.comwrote:
+1 for Hugh, but IMO no need to rush with Alexei's removal
Hi stackers,
I would like to:
1) Nominate Hugh
2c.
--
Best regards,
Oleg Gelbukh
* Deployment Role
... and if we are in the context of undercloud, people can shorten it to
just Roles. But 'Resource Category' seems to me that it doesn't solve
anything.
-- Jarda
___
OpenStack-dev mailing list
I've finished the v0.1 spec of Rally API: http://docs.rallyapi.apiary.io/
The only thing that spec is missing at the moment is resource for Workloads
(/deployments/workloads). I will add this resource shortly.
Please, send your comments and suggestions.
--
Best regards,
Oleg Gelbukh
On Sun
Yuriy, the idea is to choose something more or less general. 'Overcloud'
would be very specific to my taste. It could also create confusion for
users who want to depoy tests targets with other tools, like Fuel or
Devstack.
--
Best regards,
Oleg Gelbukh
On Sun, Jan 19, 2014 at 1:17 AM, Yuriy
. It means that different sets of operations
are applicable to those entities. What do you think?
--
Best regards,
Oleg Gelbukh
++
Best,
-jay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
.
--
Best regards,
Oleg Gelbukh
/Alan
*From:* Oleg Gelbukh [mailto:ogelb...@mirantis.com]
*Sent:* January-15-14 10:30 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [ironic] Disk Eraser
On Wed, Jan 15, 2014 at 6:42 PM, Alexei
On Wed, Jan 15, 2014 at 6:42 PM, Alexei Kornienko
alexei.kornie...@gmail.com wrote:
If you are working on linux system following can help you:
dd if=/dev/urandom of=/dev/sda bs=4k
I would not recommend that as /dev/urandom is real slow (10-15 MB/s).
--
Best regards,
Oleg Gelbukh
that such service could have more then one
application.
The first step to this could be abstracting a back-end in oslo.config and
implementing some simplistic driver, SQL or k-v storage. This could help to
outline requirements to future configuraiton service.
--
Best regards,
Oleg Gelbukh
On Thu, Jan 9
solve the use case you describe, as overcloud nodes probably won't have an
access to undercloud Heat server. But that counts as a centralized storage
of confguration information, from my standpoint.
--
Best regards,
Oleg Gelbukh
___
OpenStack-dev mailing
. allow one server to query
certain configuration parameter(s) from the other via RPC? I believe I've
seen such proposal quite some time ago in Nova blueprints, but with no
actual implementation.
--
Best regards,
Oleg Gelbukh
Also, I know that I run what is probably a more complicated cluster
for
OpenStack-on-OpenStack use case you're describing.
Baiscally, Heat has all orchestration functions in OpenStack. I see it as a
natural place for other interesting things like auto-migration of workloads
and so on.
--
Best regards,
Oleg Gelbukh
On Sun, Dec 29, 2013 at 8:03 AM, LeslieWang wqyu
I'd +1 Clint on this. I believe that the only right way to handle SIGHUP
for process running in foreground is to terminate.
--
Best regards,
Oleg Gelbukh
On Fri, Dec 20, 2013 at 10:54 AM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Sean Dague's message of 2013-12-19 16:33:12 -0800:
So
Hi everyone,
I'm sorry for being late to the thread, but what about baremetal driver?
Should it support the get_diagnostics() as well?
--
Best regards,
Oleg Gelbukh
On Thu, Dec 19, 2013 at 8:21 PM, Vladik Romanovsky
vladik.romanov...@enovance.com wrote:
Ah, I think I've responded too fast
.
--
Best regards,
Oleg Gelbukh
On Fri, Dec 20, 2013 at 7:12 PM, Matt Riedemann
mrie...@linux.vnet.ibm.comwrote:
On Friday, December 20, 2013 3:57:15 AM, Daniel P. Berrange wrote:
On Fri, Dec 20, 2013 at 12:56:47PM +0400, Oleg Gelbukh wrote:
Hi everyone,
I'm sorry for being late
Ray,
Actually, you can. There is an ESX driver in OpenStack as well as vCenter.
However, it does not have benefits of vSphere/vCenter, like DRS.
It would probably help if you described your use case and specify why you
want to identify every ESXi host.
--
Best regards,
Oleg Gelbukh
Mirantis Inc
I would copy that question. Looks like integration plan didn't work out,
and healthnmon development either stalled or gone shadow..
Anyone have information on that?
--
Best regards,
Oleg Gelbukh
Mirnatis Inc.
On Tue, Dec 17, 2013 at 11:29 PM, David S Taylor da...@bluesunrise.comwrote:
Could
Re this particular change, we plan to reuse this API extension code, but
extended to support domain-level quota as well.
--
Best regards,
Oleg Gelbukh
Mirantis Labs
On Mon, Dec 2, 2013 at 5:39 PM, Chmouel Boudjnah chmo...@enovance.comwrote:
Hello,
I was wondering what was the status
1 - 100 of 111 matches
Mail list logo
