+1 for canceling on 9/18/2014.
As for 9/25/2014, let's make a decision later.
Vladimir Kozhukalov
On Thu, Sep 18, 2014 at 9:33 AM, Mike Scherbakov mscherba...@mirantis.com
wrote:
Hi Fuelers,
as we have mini-summit in CA and majority of leads is busy with it, let's
cancel the meeting
As far as I understand, there are 4 projects which are connected with this
topic. Another two projects which were not mentioned by Devananda are
https://github.com/rackerlabs/teeth-rest
https://github.com/rackerlabs/teeth-overlord
Vladimir Kozhukalov
On Fri, Mar 7, 2014 at 4:41 AM, Devananda
we move this agent to stackforge?
Vladimir Kozhukalov
On Fri, Mar 7, 2014 at 8:53 PM, Russell Haering russellhaer...@gmail.comwrote:
Vladmir,
Hey, I'm on the team working on this agent, let me offer a little history.
We were working on a system of our own for managing bare metal gear
[driver], lambda ext:
ext.obj(d))
Granual driver driver: /power
Data: {key111: value111, ...}
Implementation:
ext_mgr.map(lambda ext: ext.name == power, lambda ext: ext.obj(data))
What do you guys think of having just plain (not tree like) bunch of
drivers?
Vladimir Kozhukalov
On Mon, Mar 10
And here is scheme
https://drive.google.com/a/mirantis.com/file/d/0B-Olcp4mLLbvRks0eEhvMXNPM3M/edit?usp=sharing
Vladimir Kozhukalov
On Fri, Mar 21, 2014 at 9:16 PM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
Guys,
I've read comments from JoshNang here
https
and which aren't.
How am I supposed to know which nodes are still alive in case of Ironic?
IPMI? Again IPMI is not always available. And if IPMI is available, then
why do we need heartbeat in Ironic agent?
Vladimir Kozhukalov
On Fri, Apr 4, 2014 at 9:46 PM, Ezra Silvera e...@il.ibm.com wrote
can make VMs and it has advanced
functionality for that. What it can NOT do is to boot them via PXE. There
is a blueprint for that
https://blueprints.launchpad.net/nova/+spec/libvirt-empty-vm-boot-pxe.
--
Vladimir Kozhukalov
___
OpenStack-dev mailing
, not kvm. It is because donated cloud
resources used for testing do not support hardware nesting.
Vladimir Kozhukalov
On Tue, Dec 3, 2013 at 7:32 PM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
We are going to make integration testing gate scheme for Ironic and we've
investigated several
for resolving task
dependencies. As our transport layer we'll then be able to use whatever we
want (Saltstack, Mcollective, bare ssh, any kind of custom implementation,
etc.)
Vladimir Kozhukalov
On Fri, Jun 13, 2014 at 8:45 AM, Mike Scherbakov mscherba...@mirantis.com
wrote:
Dmitry,
please read
user would like to be able to
take a look in old logs.
My suggestion here is to add a boolean parameter into settings which will
manage this piece of logic (1-remove old logs, 0-don't touch old logs).
Thanks for your opinions.
Vladimir Kozhukalov
logs is logrotate. Currently it just moves files like this
/var/log/remote/old-node.example.com/some.log - /var/log/remote/
old-node.example.com/some.log.1.gz. But what it actually should do is to
remove the whole directories which are related to nonexistent nodes, right?
Vladimir Kozhukalov
, debugging.
Vladimir Kozhukalov
On Fri, Apr 18, 2014 at 2:08 PM, Lucas Alvares Gomes
lucasago...@gmail.comwrote:
+1 for me as well, I'd like to have a better way to track incoming
features.
Also, as part of the migration progress I think that we need a good
wiki page explaining the process
be the requirements for an arbitrary PyPi package?
4) Standard for testing.
It requires a separate discussion.
5) Standard for documentation.
It requires a separate discussion.
Vladimir Kozhukalov
___
OpenStack-dev mailing list
OpenStack-dev
working
IPMI stuff and they don't oppose ssh based power management any more.
Personally, I'd prefer to focus our efforts towards Ironic stuff and
keeping in mind that Cobbler will be removed in the nearest future.
Vladimir Kozhukalov
On Wed, Nov 5, 2014 at 7:28 PM, Vladimir Kuklin vkuk...@mirantis.com
files and directories in a
project (shell.py, api, object, etc). I am not sure whether such a common
practice exists, but we again can follow python-openstackclient naming
model.
3) Use oslo for auth stuff (Fuel uses keystone at the moment) and wherever
it is suitable.
Vladimir Kozhukalov
On Mon
already said,
we are OK if Ironic does not need this feature.
Vladimir Kozhukalov
On Tue, Dec 9, 2014 at 1:09 PM, Roman Prykhodchenko
rprikhodche...@mirantis.com wrote:
It is true that IPA and FuelAgent share a lot of functionality in common.
However there is a major difference between them which
Vladimir Kozhukalov
On Tue, Dec 9, 2014 at 3:51 PM, Dmitry Tantsur dtant...@redhat.com wrote:
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
s/though/throw/g
Vladimir Kozhukalov
On Tue, Dec 9, 2014 at 5:40 PM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
Vladimir Kozhukalov
On Tue, Dec 9, 2014 at 3:51 PM, Dmitry Tantsur dtant...@redhat.com
wrote:
Hi folks,
Thank you for additional explanation, it does clarify
We assume next step will be to put provision data (disk partition
scheme, maybe other data) into driver_info and make Fuel Agent driver
able to serialize those data (special format) and implement a
corresponding data driver in Fuel Agent for this format. Again very
simple. Maybe it is time to
/mapper/vgname/lvname) or md device
(/dev/md0)
Fuel Agent is also able to install and configure grub.
Here is the code of Fuel Agent
https://github.com/stackforge/fuel-web/tree/master/fuel_agent
Vladimir Kozhukalov
On Tue, Dec 9, 2014 at 8:41 PM, Fox, Kevin M kevin@pnnl.gov wrote:
We've been
.
Vladimir Kozhukalov
On Wed, Dec 10, 2014 at 1:06 AM, Devananda van der Veen
devananda@gmail.com wrote:
On Tue Dec 09 2014 at 9:45:51 AM Fox, Kevin M kevin@pnnl.gov wrote:
We've been interested in Ironic as a replacement for Cobbler for some of
our systems and have been kicking
(but unfortunately 6.1 is not a real estimate for that).
Vladimir Kozhukalov
On Wed, Dec 17, 2014 at 5:03 AM, Mike Scherbakov mscherba...@mirantis.com
wrote:
Dmitry,
as part of 6.1 roadmap, we are going to work on patching feature.
There are two types of workflow to consider:
- patch existing
using kickstart/preseed based way of OS provisioning by
6.1 for all new releases allowing ONLY old ones to use this way.
Any opinions about that stuff are welcome.
Vladimir Kozhukalov
__
OpenStack Development Mailing List
Subject is changed.
Vladimir Kozhukalov
On Mon, Jan 26, 2015 at 4:55 PM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
Dear Fuelers,
As you might know we need it to be possible to install several versions of
a particular OS (Ubuntu and Centos) by 6.1 As far as having different OS
My suggestion is to make IBP the only option available for all upcoming
OpenStack releases which are defined in openstack.yaml. It is to be
possible to install OS using kickstart for all currently available
OpenStack releases.
Vladimir Kozhukalov
On Mon, Jan 26, 2015 at 6:22 PM, Igor Kalnitsky
with
their own data format. It is tested together with other Fuel components
during system testing only.
Vladimir Kozhukalov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
-agent which is completely about provisioning. Will create a separate
ML thread.
Vladimir Kozhukalov
On Mon, Jan 26, 2015 at 6:40 PM, Roman Prykhodchenko m...@romcheg.me wrote:
Hi guys,
status update incoming.
- ISO build scripts have been switched to stackforge/python-fuelclient as
the main
,
As for fuel_agent_ci, it is not used currently on the regular basis, so I
think we need it to be moved to the same separate repo and then one day in
the future maybe we will use it for functional testing.
Vladimir Kozhukalov
On Tue, Jan 27, 2015 at 1:39 AM, Roman Prykhodchenko m...@romcheg.me
Andrew is right about our ability to upgrade packages on a system using
yum update or apt-get upgrade because IBP installs standalone OS
(unlike cloud case). Even more, we'll build Ubuntu images on a master node
by 6.1 and of course we'll be able to use actual repo for that.
Vladimir Kozhukalov
would say
it is not more reliable than IBP) or to refuse preseed approach for ONLY
NEW UPCOMING releases. You can call crazy but for me having a set IFs
together with pmanager.py which are absolutely difficult to maintain is
crazy.
Vladimir Kozhukalov
On Tue, Jan 27, 2015 at 3:03 AM, Andrew Woodward
than that is provided by DIB. For ubuntu we use debootstrap and for centos
we use python-imgcreate.
Vladimir Kozhukalov
On Wed, Jan 28, 2015 at 10:35 AM, Oleg Gelbukh ogelb...@mirantis.com
wrote:
Gentlemen,
I have one small question about IBP, and I'm not sure if this is the right
place to ask
[1] does not break anything for you. Review is
welcome.
[1] https://review.openstack.org/#/c/176438
Vladimir Kozhukalov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
this file and moving some
parameters into package related files. I'll describe this in details in a
spec.
Vladimir Kozhukalov
On Mon, Jul 27, 2015 at 1:57 PM, Matthew Mosesohn mmoses...@mirantis.com
wrote:
2) production - It is always equal to docker which means we deploy
docker containers
/openstack.yaml
Vladimir Kozhukalov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo
. And it is not
so hard to implement syntax and logic checking for the text file.
Please give your opinions about this.
Vladimir Kozhukalov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack
-1 for using kernel parameters for configuring the whole master node
installation. User should be able to edit configuration and then re-deploy
the master node. I have no idea what would UX look like if we used kernel
paramenters.
Vladimir Kozhukalov
On Thu, Jul 23, 2015 at 7:49 PM, Vladimir
is to switch from ncurses to plain text file (thoroughly
commented), because it so easy to add new parameters or remove those we
don't need any more.
Vladimir Kozhukalov
On Thu, Jul 23, 2015 at 6:17 PM, Nick Chase nch...@mirantis.com wrote:
On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn
about
the place where you need to make changes.
https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82
If you create shell script, I'll help you to add it to make code.
Vladimir Kozhukalov
On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko adide...@mirantis.com
wrote:
I
/202541/
Vladimir Kozhukalov
On Fri, Jul 17, 2015 at 12:03 AM, Sergii Golovatiuk
sgolovat...@mirantis.com wrote:
Hi,
Let's put openstack.yaml to package if it requires for master node
upgrade. Environment update part should be removed as it never reached
production state.
--
Best regards
Guys, thanks a lot for your opinions. Now it is quite clear for me that
vim+text UX is definitely not our way even though many developers (not all)
prefer this.
Vladimir Kozhukalov
On Fri, Jul 24, 2015 at 12:47 AM, Fabrizio Soppelsa fsoppe...@mirantis.com
wrote:
Hello Vladimir, from me -1
. If they work, we need to merge
them and that is it. Review is welcome.
[1] https://github.com/stackforge/fuel-agent.git
Vladimir Kozhukalov
On Fri, Jul 10, 2015 at 8:14 PM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
Ok, guys.
Looks like there are no any objections. At the moment I need
on).
Vladimir Kozhukalov
On Thu, Jul 16, 2015 at 1:22 PM, Oleg Gelbukh ogelb...@mirantis.com wrote:
Vladimir,
I am fully support moving fuel-upgrade-system into repository of its own.
However, I'm not 100% sure how docker containers are going to appear on the
upgraded master node. Do we have public
python script
into rpm. It's gonna decrease the complexity of build process as well as
make it a little bit faster.
What do you think of this?
Vladimir Kozhukalov
__
OpenStack Development Mailing List (not for usage questions
to remove upgrade tarball
9) patch to fuel-web to remove fuel_upgrade_system directory
Vladimir Kozhukalov
On Thu, Jul 16, 2015 at 11:13 AM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
Dear colleagues,
I'd like to suggest to get rid of Fuel upgrade tarball and convert this
thing
on
other packages) into perestroika. Yet another thing is that eventually
all those packages and containers will be artifacts and will be treated
differently according to their nature. That will be the time when we'll be
thinking of a docker registry and other stuff like this.
Vladimir Kozhukalov
Alex,
Great that you did this. Now I think I can prepare fuel-main patch to
invoke this script right before building fuel-library package. I'll add you
to review it. Is it ok if I do this monday morning?
Vladimir Kozhukalov
On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz aschu...@mirantis.com
.git.bac86fe.noarch.rpm
if the package contains all necessary upstream modules.
Vladimir Kozhukalov
On Sat, Jul 18, 2015 at 3:28 AM, Alex Schultz aschu...@mirantis.com wrote:
Not until we start using it then any ci that tests with that module will
validate the modules inclusion. You can check the output
patch is OK, make system can build this package and ISO
passes BVT tests.
[1]
http://172.18.160.74/osci/review/CR-202763/mos/7.0/fuel/base/centos6/Packages/fuel-library7.0-7.0.0-1.mos6888.git.bac86fe.noarch.rpm
Vladimir Kozhukalov
On Mon, Jul 20, 2015 at 4:04 PM, Vladimir Kozhukalov
vkozhuka
in rpm repository.
Next step is to remove stackforge/fuel-web/fuel_agent directory.
[1] https://github.com/stackforge/fuel-agent.git
Vladimir Kozhukalov
On Wed, Jul 15, 2015 at 2:19 AM, Mike Scherbakov mscherba...@mirantis.com
wrote:
Thanks Vladimir. Let's ensure to get it done sooner than later
.
Vladimir Kozhukalov
On Tue, Oct 20, 2015 at 7:05 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Igor,
>
> Thank you for your help. I'd say ETA is today/tomorrow and depends on how
> quickly this project-config patch [1] will be reviewed and merged. I'll ask
> opens
ich are (ON REVIEW), please help.
Vladimir Kozhukalov
On Tue, Oct 20, 2015 at 6:45 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Dear colleagues,
>
> As you might know I'm working on splitting multiproject fuel-web
> repository into several sub-projects. n
://review.openstack.org/239410 (DONE)
- deprecate shotgun directory https://review.openstack.org/239407 (DONE)
- fix verify-fuel-web-docs job (it installs shotgun for some reason)
https://review.fuel-infra.org/#/c/13194/ (DONE)
- remove old shotgun package (DONE)
Vladimir Kozhukalov
On Wed, Oct 21
(DONE???)
Vladimir Kozhukalov
On Fri, Oct 23, 2015 at 7:06 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Dear colleagues,
>
> I'd like to update the status of the activity (moving fuelmenu to a
> separate repo).
>
>
>- Launchpad bug https://b
Looks like most people thing that building backup/re-install approach is
more viable. So, we certainly need to invent completely new upgrade from
and thus my suggestion is disable building/testing upgrade tarball right
now, because anyway it makes no sense.
Vladimir Kozhukalov
On Fri, Nov 6
Dear colleagues,
I'm glad to announce that network-checker is a separate project now. All
related patches have been merged. Thanks everyone for your efforts to make
this happen.
Vladimir Kozhukalov
On Thu, Oct 29, 2015 at 6:42 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
are going to upgrade the
master node ASAP. Probably my tarball related work should be reduced to
just throwing tarball away.
Vladimir Kozhukalov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
Igor,
Thank you for your help. I'd say ETA is today/tomorrow and depends on how
quickly this project-config patch [1] will be reviewed and merged. I'll ask
openstack-infra guys to do this ASAP.
[1] https://review.openstack.org/#/c/235177
Vladimir Kozhukalov
On Tue, Oct 20, 2015 at 6:39 PM
to be backported to the new git repository.
Vladimir Kozhukalov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi
to be backported to the new git repository.
Vladimir Kozhukalov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org
will need to
be backported to the new git repository.
Vladimir Kozhukalov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
. This thread is totally about separation stuff and how to do this
not breaking anything.
Vladimir Kozhukalov
On Wed, Jul 8, 2015 at 12:24 PM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
Dear colleagues,
I am going to move Fuel Agent into a separate git repository. The thing
process https://review.openstack.org/#/c/200025
And good luck to me -)
Vladimir Kozhukalov
On Wed, Jul 8, 2015 at 12:53 PM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
There were some questions from Alexandra Fedorova about independent
release cycle.
according to the configuration
into the new fuel-agent repository.
Vladimir Kozhukalov
On Fri, Jul 10, 2015 at 6:38 PM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
Guys, we are next to moving fuel_agent directory into a separate
repository. Action flow is going to be as follows:
1) Create verify jobs on our CI
-library on the master node, we would not need that complicated upgrade
stuff like we currently have for puppet modules.
Please give your opinions on this.
[1]
https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/tasks_serializer.py#L205-L218
Vladimir Kozhukalov
ill associate ISO with MOS, but it is not true when using
package based delivery approach.
It is easy to define necessary repos during deployment and thus it is easy
to control what exactly is going to be installed on slave nodes.
What do you guys think of it?
Vladimir Kozhukalov
On Tue, Sep 8, 2
/stackforge/fuel-main/blob/master/iso/ks.template#L416-L419
[2]
https://github.com/stackforge/fuel-web/blob/master/fuel_upgrade_system/fuel_upgrade/fuel_upgrade/engines/host_system.py#L109-L115
Vladimir Kozhukalov
__
OpenStack
ter node (cloning it
locally or via internet connection).
IMO, Fuel in this case is like a browser or bittorrent client. Packages are
available on Linux DVDs but it makes little sense to use them w/o internet
connection.
Vladimir Kozhukalov
On Thu, Sep 10, 2015 at 2:53 PM, Yuriy Taraday <
he way of distributing MOS.
ISO should be nothing more than just a way of installing Fuel from scratch.
MOS should be distributed via MOS repos. Fuel is available as RPM package
in RPM MOS repo.
Vladimir Kozhukalov
On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky <ikalnit...@mirantis.c
to have a kind of local copy.
Vladimir Kozhukalov
On Thu, Sep 10, 2015 at 4:17 PM, Vladimir Kuklin <vkuk...@mirantis.com>
wrote:
> Igor
>
> Having poor access to the internet is a regular use case which we must
> support. This is not a crazy requirement. Not having full ISO m
and
start deployment. Anyway, you still have rsync, mcollective and other old
plain tools to run deployment manually.
[1] http://perestroika-repo-tst.infra.mirantis.net/review/CR-221719/
Vladimir Kozhukalov
On Wed, Sep 9, 2015 at 2:48 PM, Dmitry Pyzhov <dpyz...@mirantis.com> wrote:
>
as possible. Anyway I think this argument that it is easier
to develop is not that kind of argument which can prevail when discussing
production ready delivery approach.
Vladimir Kozhukalov
On Wed, Sep 9, 2015 at 4:15 PM, Andrey Danin <ada...@mirantis.com> wrote:
> I don't think juggling w
re (by 8.0) Perestroika will be
available as an application independent from CI. So, what is wrong with
building fuel-library package? What if you want to troubleshoot nova (we
install it using packages)? Should we also use rsync for everything else
like nova, mysql, etc.?
Vladimir Kozhukalov
On Wed, Sep 9,
suggesting nothing more than to make things simpler so that I am able
to implement such tools that could be used to easily build all
inclusive/not inclusive/empty/whatever ISO if one would like to do it.
Vladimir Kozhukalov
On Thu, Sep 10, 2015 at 6:18 PM, Vladimir Kuklin <vkuk...@mirantis.
if
upstream repos are still online.
Vladimir Kozhukalov
On Thu, Sep 10, 2015 at 7:58 PM, Dmitry Pyzhov <dpyz...@mirantis.com> wrote:
> Guys,
>
> looks like you’ve started to talk about different things. As I see,
> original proposal was: stop treat MOS DEB repo as a sp
It is possible to implement really flexible
delivery scheme, but we need to think of these things as they are
independent.
For large users it is easy to build custom ISO and put there what they need
but first we need to have simple working scheme clear for everyone. I think
dealing with all repos t
Mike,
Yes, probably the best place to describe further plans is README file. I'll
create a patch.
Vladimir Kozhukalov
On Tue, Dec 1, 2015 at 8:30 PM, Mike Scherbakov <mscherba...@mirantis.com>
wrote:
> Vladimir,
> if you've been behind of this, could you please share f
-my-favorite-updates my-favorite-section
While we (for some reasons) limited our UI to define only base url and base
suite. That should be fixed.
Vladimir Kozhukalov
On Fri, Dec 11, 2015 at 2:33 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:
> > Do we really need a custom for
ctly configured.
[0]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L2006-L2053
Vladimir Kozhukalov
On Fri, Dec 11, 2015 at 1:56 PM, Aleksandr Mogylchenko <
amogylche...@mirantis.com> wrote:
> There are common practices developed b
/nailgun/nailgun/fixtures/openstack.yaml#L2006-L2053
Vladimir Kozhukalov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
BTW, here you can see an example http://demo.fuel-infra.org:8000 Just go to
any cluster and see Repositories section on the settings tab.
Vladimir Kozhukalov
On Fri, Dec 11, 2015 at 5:46 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> I'd like this module
> https:
suggest to change this. I suggest to use something
similar of what we have on Web UI in our fuel-menu.
Vladimir Kozhukalov
On Fri, Dec 11, 2015 at 5:10 PM, Alexander Kostrikov <
akostri...@mirantis.com> wrote:
> Hello, Vladimir.
> Seems nothing is better for end-user in UI/fuel-
://bugs.launchpad.net/fuel/+bug/1525323
Vladimir Kozhukalov
On Fri, Dec 11, 2015 at 5:48 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> BTW, here you can see an example http://demo.fuel-infra.org:8000 Just go
> to any cluster and see Repositories section on the
create stable branch master becomes open. That was our primary intention to
open master earlier than later when we decided to move stable branch
creation.
Vladimir Kozhukalov
On Wed, Dec 16, 2015 at 8:28 PM, Vladimir Kuklin <vkuk...@mirantis.com>
wrote:
> Vladimir
>
> I
k
a deployment script should be a root of the package dependency tree.
Vladimir Kozhukalov
On Mon, Dec 14, 2015 at 12:53 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:
> Vladimir,
>
> Thanks for raising this question. I totally support idea of separating
> provisionin
. Primary delivery approach should be rpm/deb repo, not ISO.
[0]
https://blueprints.launchpad.net/fuel/+spec/separate-fuel-node-provisioning
[1] https://review.openstack.org/#/c/254270/
Vladimir Kozhukalov
__
OpenStack
Vladimir Kozhukalov
On Fri, Dec 11, 2015 at 11:14 PM, Oleg Gelbukh <ogelb...@mirantis.com>
wrote:
> For the package-based deployment, we need to get rid of 'deployment
> script' whatsoever. All configuration stuff should be done in package
> specs, or by the user later on (maybe via som
-1
We already discussed this and we have made a decision to move stable branch
creation from HCF to SCF. There were reasons for this. We agreed that once
stable branch is created, master becomes open for new features. Let's avoid
discussing this again.
Vladimir Kozhukalov
On Wed, Dec 16, 2015
experimental ISO and to begin fixing
system tests and fix the spec.
[1] https://review.openstack.org/#/c/248649
[2] https://review.openstack.org/#/c/248650
Vladimir Kozhukalov
On Mon, Nov 23, 2015 at 7:51 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Colleagues,
>
&g
/
[2] https://review.openstack.org/#/c/248650/
[3] https://review.openstack.org/#/c/248814/
Vladimir Kozhukalov
On Mon, Nov 30, 2015 at 11:19 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:
> Is that because of trying to shoehorn docker containers into rpm's though?
> I've never seen any
in the future to avoid functionality
duplication.
Those were the reasons not to put them separately. (C) "There can be only
one".
Vladimir Kozhukalov
On Tue, Dec 1, 2015 at 1:25 PM, Thomas Goirand <z...@debian.org> wrote:
> On 12/01/2015 09:25 AM, Mike Scherbakov wrote:
&g
ase do not confuse
these two cases: switching from plain deployment to containers is
complicated, but switching from docker to plain is much simpler.
Vladimir Kozhukalov
On Fri, Nov 20, 2015 at 6:47 PM, Bogdan Dobrelya <bdobre...@mirantis.com>
wrote:
> On 20.11.2015 15:10, Timur Nur
ETA:
experimental ISO w/o docker: tonight
spec: tomorrow night
Vladimir Kozhukalov
On Mon, Nov 23, 2015 at 9:25 AM, Anastasia Urlapova <aurlap...@mirantis.com>
wrote:
> @Vova,
> thanks for bringing this up.
> The new approach without docker containers on master node
] https://review.openstack.org/#/c/248649
[2] https://review.openstack.org/#/c/248650
[3] https://review.openstack.org/#/c/248814
Vladimir Kozhukalov
On Mon, Nov 23, 2015 at 3:35 PM, Aleksandr Maretskiy <
amarets...@mirantis.com> wrote:
>
>
> On Mon, Nov 23, 2015 at 2:27 PM,
emd).
Vladimir Kozhukalov
On Tue, Nov 24, 2015 at 1:57 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:
> Hey Dmitry,
>
> Thank you for your effort. I believe it's a huge step forward that
> opens number of possibilities.
>
> > Every container runs systemd as PID 1 proc
a chance to do this ASAP (during 8.0), I know it is a huge risk for
the release, but still I think I can do this.
Vladimir Kozhukalov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
Dear colleagues,
We are approaching 9.0.1 release and for higher level of stability we are
going to pin [1] upstream puppet modules temporarily. Once 9.0.1 tag is
created we will unpin upstream to make it possible to get upstream fixes.
[1] https://review.openstack.org/#/c/325807/
Vladimir
] patch.
[0] https://wiki.openstack.org/wiki/Packetary
[1] https://github.com/openstack/python-fuelclient
[2] https://review.openstack.org/#/c/326435/
Vladimir Kozhukalov
__
OpenStack Development Mailing List (not for usage
Dear colleagues,
We have a few IRC channels but the level of activity there is quite low.
#fuel
#fuel-dev
#fuel-python
#fuel-infra
My suggestion is to merge all these channels into a single IRC channel
#fuel.
Other #fuel-* channels are to be deprecated.
What do you think of this?
Vladimir
Nice. #fuel-infra is to merged as well.
Vladimir Kozhukalov
On Fri, Jun 24, 2016 at 1:50 PM, Aleksandra Fedorova <afedor...@mirantis.com
> wrote:
> And +1 for #fuel-infra
>
> As of now it will be more useful if infra issues related to project will
> be visible for project de
Ok, let's then start from merger of
#fuel-dev
#fuel-python
#fuel-ui
#fuel-library
into a single channel #fuel. #fuel-infra is to stay separate for a while.
Vladimir Kozhukalov
On Fri, Jun 24, 2016 at 1:41 PM, Andrew Maksimov <amaksi...@mirantis.com>
wrote:
> +1 for merging #fuel
1 - 100 of 162 matches
Mail list logo
