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
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
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
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
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
. 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
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
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
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
+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
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
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
regards,
Oleg Gelbukh
Mirantis Labs
On Wed, Oct 9, 2013 at 3:28 PM, Tim Bell tim.b...@cern.ch wrote:
Would the HARestarter approach work for VMs which were not launched by
Heat ?
We expect to have some applications driven by Heat but lots of others
would not be (especially the more 'pet
We're looking forward for your feedback. And if you want to improve it or
integrate it with other tools and initiatives - reach us, we always welcome
new collaborators.
--
Best regards,
Oleg Gelbukh
Mirantis Labs
___
OpenStack-dev mailing list
OpenStack-dev
Hello,
I think that is really great idea.
Do you think extracting bp/bug information (link) from commit message and
adding it to the changelog might also be useful?
--
Best regards,
Oleg Gelbukh
On Mon, Oct 28, 2013 at 5:50 AM, Monty Taylor mord...@inaugust.com wrote:
Hey all!
We're
to discuss pros and cons of contributing parts
of this code to oslo.config.
--
Best regards,
Oleg Gelbukh
Mirantis Labs
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
, and the other is standalone service for
stateful validation of cfg across services. We're working on design for
such service in frame of Rubick project.
I'd really appreciate any help with prioritization of requirements from the
list above.
--
Best regards,
Oleg Gelbukh
Mirantis Labs
To be fair
you'd like to see in such an API? Please, feel free to share your thoughts
in ML, or in the etherpad directly.
--
Best regards,
Oleg Gelbukh
Mirantis Labs
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
Dmitri,
If you intend to make this middleware generic and reusable between
different OpenStack services, your best shot, to my understanding, will be
to propose a new library in oslo-incubator.
--
Best regards,
Oleg Gelbukh
On Fri, Nov 22, 2013 at 4:05 AM, Dmitri Zimin(e) | StackStorm
d
://blueprints.launchpad.net/rubick/+spec/diagnostic-api-spec
[2]
https://blueprints.launchpad.net/rubick/+spec/instumentation-and-diagnostic-rest-api
--
Best regards,
Oleg Gelbukh
Mirantis Labs
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
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
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
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
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
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
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
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
.
--
Best regards,
Oleg Gelbukh
Mirantis Inc
On Wed, Aug 7, 2013 at 4:44 PM, Roman Gorodeckij ho...@holms.lt wrote:
Hi,
I just completely messed up in here.
Was reading a manual about Gerrit workflow:
https://wiki.openstack.org/wiki/Gerrit_Workflow#Committing_Changes
And then there's link
Hello, Alvise
It is possible that the version of dnsmasq and lease time is an issue:
https://bugs.launchpad.net/nova/+bug/887162
http://markmail.org/message/7kjf4hljszpydsrx#query:+page:1+mid:7kjf4hljszpydsrx+state:results
Hope this helps.
--
Best regards,
Oleg Gelbukh
Mirantis Inc.
On Wed
Tomas,
Thanks for very interesting project and this meeting as opportunity to
follow its progress!
Just to clarify, it looks like this time slot already booked for Savanna
meeting on #openstack-meeting-alt channel, isn't it?
--
Best regards,
Oleg Gelbukh
Mirantis, Inc.
On Thu, Sep 5, 2013
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
,
--
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
(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
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
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
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
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
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
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
] 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
'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
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
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
://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
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
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
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
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
/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
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
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
] 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
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
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
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
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
/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
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
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,
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
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
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:
>
>&
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
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
] 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
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
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
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,
>
&
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
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
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
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
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
1 - 100 of 111 matches
Mail list logo