issing from there? What information
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.openstac
naming to avoid confusion and call this
Instrumentation API or something like that?
--
Best regards,
Oleg Gelbukh
On Wed, Nov 20, 2013 at 6:45 PM, Matt Riedemann
wrote:
>
>
> On Wednesday, November 20, 2013 7:52:39 AM, Oleg Gelbukh wrote:
>
>> Hi, fellow stackers,
>>
>
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 <
lks.
[1] https://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.ope
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 wrote:
> Hello,
>
> I was wondering what was the status of Keystone
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 wrote:
> Could anyone tell
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 wrote:
> Excerpts from Sean Dague's message of 2013-12-19 16:33:12 -0800:
> &
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&#x
wrong.
--
Best regards,
Oleg Gelbukh
On Fri, Dec 20, 2013 at 7:12 PM, Matt Riedemann
wrote:
>
>
> 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,
>>>
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, Lesli
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,
'm not sure if that could help
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
__
ng it the other way round, i.e. 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
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 reg
ng installation which has nothing
to do with deployment engine. It means that different sets of operations
are applicable to those entities. What do you think?
--
Best regards,
Oleg Gelbukh
>
> ++
>
> Best,
> -jay
>
>
>
> _
> randomfile.bin
Hope this helps.
--
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] [iro
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
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
O
my 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
>
> ___
+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 wrote:
>
> +1 for Hugh, but IMO no need to rush with Alexei's removal
>
> Hi stackers,
>
> I would like to:
>
>
Congrats to all Climate team members who made it happen, great job!
--
Oleg Gelbukh
On Wed, Feb 5, 2014 at 3:36 PM, Dina Belova wrote:
> Hi, folks!
>
> Today Climate has been released first time and I'm really glad to say that
> :)
>
> This release impleme
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
wrote:
>
> Hello,
>
> Problem
What does PL stand for, anyway?
--
Best regards,
Oleg Gelbukh
On Mon, Mar 24, 2014 at 11:39 AM, Serg Melikyan wrote:
> >because 'dsl'/'language' terms are too broad.
> Too broad in general, but we choose name for sub-package, and in murano
> term 'language
rdinate efforts scattered across multiple
projects now. Let's find out what are most important and common use cases
for us, and outline how we're going to solve them.
What do you think?
--
Best regards,
Oleg Gelbukh
Mirantis Labs
___
OpenStack-dev m
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 at
will make their way into Scheduler service eventually.
--
Best regards,
Oleg Gelbukh
On Wed, Apr 9, 2014 at 7:47 PM, Jay Lau 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?
>
&g
caling could 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,
cleanup the
Master node.
--
Best regards,
Oleg Gelbukh
On Tue, Nov 4, 2014 at 3:26 PM, Przemyslaw Kaminski
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,
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 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
wrote:
> Hi,
>
> What would be your opinion on the question “
> 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
urces/instance.py#L35
[2]
http://docs.openstack.org/developer/nova/api/nova.api.openstack.compute.contrib.hypervisors.html#module-nova.api.openstack.compute.contrib.hypervisors
[3]
https://blueprints.launchpad.net/ceilometer/+spec/monitoring-physical-devices
--
Best regards,
Oleg Gelbukh
Mirantis Labs
O
something we want to address
eventually.
--
Best regards,
Oleg Gelbukh
Mirantis Inc.
On Wed, Oct 9, 2013 at 3:28 PM, Tim Bell 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
it will be incorporated in Tim's session, or any other session on this
topic.
[1] https://etherpad.openstack.org/openstack-instance-high-availability
--
Best regards,
Oleg Gelbukh
Mirantis Labs
On Wed, Oct 9, 2013 at 3:59 PM, Alex Glikson wrote:
> *> Hypervisor failure detection i
regards,
Oleg Gelbukh
Mirantis Labs
On Wed, Oct 9, 2013 at 3:28 PM, Tim Bell 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
e.com/watch?v=zTfRopx5bcA
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-
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 wrote:
> Hey all!
>
> We're adding a
Gary, Nikola,
The diagnostics service being developed by our labs could be of interest
for you [1]
The first use case we're working on is exactly what you suggest: validation
of configuration parameters across services before running them [2]
We now use a mix of approaches:
1. introduce extended
configuration schema:
[1] https://github.com/MirantisLabs/rubick/tree/master/rubick/schemas
[2]
https://github.com/MirantisLabs/rubick/blob/master/rubick/schemas/collector.py#L189
[3]
https://github.com/MirantisLabs/rubick/blob/master/rubick/schemas/generator.py
I think it would be useful to di
, 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
&g
Tracy,
I've created etherpad with the summary:
https://etherpad.openstack.org/p/w5BwMtCG6z
--
Best regards,
Oleg Gelbukh
On Mon, Nov 18, 2013 at 11:17 PM, Tracy Jones wrote:
> Oleg - this is great! I tried to find you on IRC to recommend we put this
> on a etherpad so severa
.
--
Best regards,
Oleg Gelbukh
Mirantis Inc
On Wed, Aug 7, 2013 at 4:44 PM, Roman Gorodeckij 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
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, 20
update of view was made by external
links.
We will continue to flesh 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,
e a contradictory. If the data 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.
ps://github.com/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
wrote:
> Oleg,
>
> I think we can remove this function for new releases and keep them
> only for backward compa
and make decision for itself whether it should execute
something on such a change or not.
Settings store proposed 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
ther
level, of 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 hav
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.
--
Best regards,
Ol
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 1:29 PM, Vladimir
l-7.0/operations.html#howto-backup-and-restore-fuel-master
--
Best regards,
Oleg Gelbukh
On Fri, Nov 6, 2015 at 6:03 PM, Matthew Mosesohn
wrote:
> Oleg,
>
> All the volatile information, including a DB dump, are contained in the
> small Fuel Master backup. There should be no inform
ck 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
wrote:
> Evgeniy
>
> I am not sure you addressed me, but, anyway, - yes, we will have a
> s
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 Kaln
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
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
wrote:
> Hello,
>
> We've been working for some time on bringing CentOS-7
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 re
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,
to override default behaviours.
--
Best regards,
Oleg Gelbukh
On Mon, Dec 7, 2015 at 9:29 PM, Eugene Korekin
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
> to s
I'd like 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 Ge
oad 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 wrote:
> One of the problems we've faced with trying to plug-in ConfigDB is trying
> to separate the cluster attributes f
to purely consumer role in the deployment data pipeline.
--
Best regards,
Oleg Gelbukh
On Fri, Apr 1, 2016 at 1:37 PM, Bogdan Dobrelya
wrote:
> On 04/01/2016 10:41 AM, Oleg Gelbukh wrote:
> > Andrew,
> >
> > This is an excellent idea. It is apparently more efficient and
&g
sues with pip unable 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
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
wrote:
> Hi,
>
> I'm sorry for replying to this old
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:
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
quired 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:
>
e 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,
663,n,z
[1] https://bugs.launchpad.net/fuel/+bug/1503663/comments/10
--
Best regards,
Oleg Gelbukh
On Tue, Dec 15, 2015 at 8:58 PM Dmitry Klenov wrote:
> Hi folks,
>
> I would propose to keep current versioning schema until fuel release
> schedule is fully aligned with OpenStack
lmost 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
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
x27;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
> wrote:
>
>> Hi
>>
>> Althoug
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.
--
Bes
push 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 Gelbu
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,
>
>
I guess that the original idea behind the wipe were security reasons so the
decommissioned node didn't contain any information of the cloud, including
configuration files and such.
--
Best regards,
Oleg Gelbukh
On Thu, Dec 24, 2015 at 11:29 AM, Artur Svechnikov wrote:
> Hi,
> We hav
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 wrote:
> Hi!
>
> I need some advice on how to tackle this issue. There
considerations. 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
nd concern
the Fuel Admin node itself. It would 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
wrote:
> Hi,
>
> > So what is open
anges will
require manual rebase anyways, so no point to keep them in listings and
search results.
So I'm for 2 weeks auto-abandon period.
--
Best regards,
Oleg Gelbukh
On Tue, Jul 7, 2015 at 11:34 PM, Mike Scherbakov
wrote:
> Hi,
> we have too many patches which hang for over
rn another syntax to write
unittests.
--
Best regards,
Oleg Gelbukh
On Thu, Jul 9, 2015 at 11:12 AM, Bartlomiej Piotrowski <
bpiotrow...@mirantis.com> wrote:
> Hi all,
>
> as hopefully everyone knows, it's very challenging to prove that Bash
> encourages
> writing read
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 wrote:
> On 2015
2.
>
Again, if something in code deps breaks our stable branch, we must learn it
as soon as possible and fix it there. However, in this case it ist the test
requirements failure, and it should pinned in 'test-requirements.txt' or in
requirements of our test suits.
--
Best regards,
O
is much easier to deal 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
> wrote:
>
>> Some comments inline.
>>
>> On Mon, Ju
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 ev
g 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 direct
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
On
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
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, Ju
consistent
with the cluster's fsid.
Which issues should 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
https://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.openstac
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
wrote:
> How much effort are we spending? I'm not so sure
y we can't just drop '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.
--
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
eve
se is more 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 wrote:
> Hi Andrew,
>
> I don't agree with you, user should be able to na
/203537/
[3] https://review.openstack.org/#/c/203536/
--
Best regards,
Oleg Gelbukh
On Fri, Jul 24, 2015 at 3:26 PM, Aleksey Kasatkin
wrote:
> +1 for an exception. Do we have time estimate though?
>
>
> Aleksey Kasatkin
>
>
> On Fri, Jul 24, 2015 at 2:46 PM, Sebastian Ka
which 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
] 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
wrote:
> Oleg, thanks for the provided information. As discussed verbally, most
> core reviewers are now busy with fixing cr
1 - 100 of 122 matches
Mail list logo
