+1
On Fri, Mar 4, 2016 at 10:07 AM, Matt Fischer wrote:
> +1 from me!
>
> gmail/openstack-dev is doing its thing where I see your email 4 hours
> before Emilien's original, so apologies for the reply ordering
>
> On Fri, Mar 4, 2016 at 8:49 AM, Cody Herriges
On Thu, Mar 3, 2016 at 7:19 AM, Matthew Mosesohn wrote:
>
> Hi Fuelers,
>
> I would like to bring your attention a dilemma we have here. It seems
> that there is a dispute as to whether we should maintain the releases
> list for example plugins[0]. In this case, this is
+1
On Wed, Feb 24, 2016 at 5:50 AM, Vladimir Kuklin
wrote:
> Fellow Fuelers
>
> I would like to kindly ask you to consider voting for Matthew Mosesohn as
> a Fuel Library Core
> reviewer.
>
> Matthew has been working with Fuel since its inception, worked on
> countless
On Tue, Feb 23, 2016 at 1:48 AM, Ptacek, MichalX
wrote:
> Hello again,
>
>
>
> In last days I realized that rpm/deb packages from supported platforms are
> too old (OSC, python-PROJECTclient,….)
>
> so I suppose that I should install newer versions not via deb/rpm
On Thu, Feb 18, 2016 at 3:26 PM, Matt Fischer wrote:
> Is anyone able to share the secret of running spec tests since the r10k
> transition? bundle install && bundle exec rake spec have issues because
> r10k is not being installed. Since I'm not the only one hopefully this
On Thu, Feb 18, 2016 at 4:00 AM, Aleksandr Didenko
wrote:
> > Given the requirements to be able to use new features in fuel, with an
> older version of OpenStack, what alternative would you propose?
>
> For example, it's possible to use existing "release" functionality in
On Wed, Feb 17, 2016 at 10:23 AM, Bogdan Dobrelya
wrote:
> > So we'll have tons of conditionals in composition layer, right? Even if
> > some puppet-openstack class have just one new parameter in new release,
> > then we'll have to write a conditional and duplicate class
On Fri, Jan 29, 2016 at 2:12 AM, Bogdan Dobrelya wrote:
> This is a continuation of the forked discussion [0].
>
> The idea is to relax Fuel-library downstream policy and implement a
> "lazy downstreaming", which is to not create a downstream fork of a
> puppet module
2016 at 11:03 AM, Aleksandr Didenko
>> >> <adide...@mirantis.com <mailto:adide...@mirantis.com>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> > I also think 3.3 is the version that ships with 14.04.
>>
On Jan 27, 2016 4:58 PM, "Andrew Woodward" wrote:
>
> Simon, you should use the deployment_tasks.yaml interface (which will
likely eventually move to '*/tasks.yaml' (to mimic library) This uses the
same task system as granular deploy. you can set task ordering between
known
On Tue, Jan 26, 2016 at 11:42 AM, Stanislaw Bogatkin
wrote:
> Hi guys,
>
> for some time we have a bug [0] with ntpdate. It doesn't reproduced 100% of
> time, but breaks our BVT and swarm tests. There is no exact point where
> problem root located. To better understand
-v change that didn't have any response
information so maybe it's the other problem where there is some
network connectivity isn't working correctly or the responses are
getting dropped somewhere?
-Alex
>
> On Tue, Jan 26, 2016 at 10:41 PM, Alex Schultz <aschu...@mirantis.com>
> wro
Hey Folks,
So on Friday our CI unit tests for puppet version 3.8 started
failing[0] due to an update to facter which seems to have issues with
one of our ceph facts[1]. This has blocked up the pipeline, so in
order to unstick it we are looking at updating the ceph
osd_devices_list fact[2] to
On Wed, Jan 20, 2016 at 9:02 AM, Matthew Mosesohn
wrote:
> Hi all,
>
> Unit tests on CI and gate bottleneck are really slowing down commit
> progress. We recently had a meeting to discuss possible ways to improve
> this, including symlinks, caching git repositories, etc,
On Wed, Jan 6, 2016 at 4:40 PM, Emilien Macchi <emil...@redhat.com> wrote:
>
>
> On 01/05/2016 12:55 PM, Emilien Macchi wrote:
>> Hi,
>>
>> Alex Schultz (mwhahaha on IRC) has been a very active contributor over
>> the last months in the Puppet OpenStack
On Thu, Dec 24, 2015 at 1:29 AM, Artur Svechnikov
wrote:
> Hi,
> We have faced the issue that nodes' disks are wiped after stop deployment.
> It occurs due to the logic of nodes removing (this is old logic and it's not
> actual already as I understand). This logic
Hey John,
On Fri, Dec 18, 2015 at 11:15 AM, John Menke wrote:
>
>
>
> 2015-12-17 20:49:36ERR[566] Error running RPC method verify_networks:
> Network verification not avaliable because nodes ["1"] not avaliable via
> mcollective, trace:
>
el/fuel-7.0/operations.html#setting-up-local-mirrors
Thanks,
-Alex
> On Fri, Dec 18, 2015 at 1:29 PM, Alex Schultz <aschu...@mirantis.com>
> wrote:
>
>> Hey John,
>>
>>
>> On Fri, Dec 18, 2015 at 11:15 AM, John Menke <jmj...@gmail.com> wrote:
>>
On Wed, Dec 16, 2015 at 3:33 AM, Bartłomiej Piotrowski
wrote:
> Fuelers,
>
> with the switch to CentOS 7, we also started using Puppet 3.8 in place
> of 3.4. Is there any reason to run entire range of
> gate-fuel-library-puppet-unit-3.*-dsvm-centos7 tests?
>
> I suppose
or improvement to ensure that the cluster doesn't
crash itself when it runs out of space. The goal of change was to
ensure that rabbitmq/mysql/etc are cleanly shutdown prior to a
critical lack of disk space which can lead to the systems melting
down.
Thanks,
-Alex
> On Tue, Nov 17, 2015 at 5
Hey Kyrylo,
On Tue, Nov 17, 2015 at 8:28 AM, Kyrylo Galanov wrote:
> Hi Team,
>
> I have been testing fail-over after free disk space is less than 512 mb.
> (https://review.openstack.org/#/c/240951/)
> Affected node is stopped correctly and services migrate to a healthy
On Tue, Nov 17, 2015 at 11:12 AM, Vladimir Kuklin wrote:
> Bogdan
>
> I think we should firstly check whether attribute deletion leads to node
> starting its services or not. From what I read in the official Pacemaker
> documentation, it should work out of the box without
e the
Fuel default. I think eventually we'll need to reevaluate how we can
split out the MOS packages for these features and allow a user to
select which package set to use and still have it 'work'.
Thanks,
-Alex
>
> On Thu, Nov 12, 2015 at 1:51 AM, Alex Schultz <aschu...@mirantis.com> wrote:
Hey folks,
Based on my previous email, I promised to send out a note this week
about this topic. My original email also included testing out the
development version of the upstream puppet modules. I was able to get
an environment working with the master branches of the OpenStack
Puppet modules
mpute or vice
versa. But that should probably be more an academic exercise rather
than production one.
-Alex
>
> On Tue, Nov 10, 2015 at 6:25 PM, Alex Schultz <aschu...@mirantis.com> wrote:
>>
>> Hey Vladimir,
>>
>> On Tue, Nov 10, 2015 at 5:56 AM, Vladim
t;> die. There is just one way I know to use haproxy with several different
>> conf's - to construct looong command line with all of them - and
>> it's really inconvenient.
>>
>> On Tue, Nov 10, 2015 at 12:20 PM, Simon Pasquier <spasqu...@mirantis.com>
>&g
Hey folks,
I'm testing[0] out flipping our current method of consuming upstream
puppet modules from using pinned versions hosted on fuel-infra to be
able to use the ones directly from upstream (master). This work is
primarily to be closer aligned with the other OpenStack projects as
well as
On Mon, Oct 5, 2015 at 5:56 AM, Eugene Nikanorov
wrote:
> Ok,
>
> Project-wise:
> 1) Pacemaker is not under our company's control, we can't assure its quality
> 2) it has terrible UX
> 3) it is not reliable
>
I disagree with #1 as I do not agree that should be a criteria
On Fri, Oct 2, 2015 at 7:43 AM, Ivan Udovichenko
wrote:
> Hello,
>
> On 10/02/2015 03:15 PM, Emilien Macchi wrote:
>> Hey Thomas,
>>
>> On 10/02/2015 04:33 AM, Thomas Goirand wrote:
>> [...]
>>> We also may need, at some point, to add the type mosdebian and moscentos
Hey All,
So I was working on Bug 1493520 which is about what happens when a
controller runs out of space. For this I came up with a solution[1] to
leverage pacemaker to migrate services away from the controller when
it runs out of space. This works great for rabbitmq/mysql where if
they run out
Hey Fuel folks,
We have recently had some concerns around the librarian workflows and
custom patches to upstream modules. I have updated the Fuel wiki[0]
with additional information to try and clarify how librarian is used
within fuel-library and what the rules are around the use of custom
On Wed, Sep 23, 2015 at 4:56 PM, Emilien Macchi wrote:
> Background
> ==
>
> Current rspec tests are tested with modules mentioned in .fixtures.yaml
> file of each module.
>
> * the file is not consistent across all modules
> * it hardcodes module names & versions
> *
On Thu, Sep 24, 2015 at 1:58 PM, Emilien Macchi <emil...@redhat.com> wrote:
>
>
> On 09/24/2015 02:19 PM, Alex Schultz wrote:
>> On Thu, Sep 24, 2015 at 11:54 AM, Emilien Macchi <emil...@redhat.com> wrote:
>>>
>>>
>>> On 09/24/2015 10:14 AM, Al
On Thu, Sep 24, 2015 at 11:54 AM, Emilien Macchi <emil...@redhat.com> wrote:
>
>
> On 09/24/2015 10:14 AM, Alex Schultz wrote:
>> On Wed, Sep 23, 2015 at 4:56 PM, Emilien Macchi <emil...@redhat.com> wrote:
>>> Background
>>> ==
>>>
>
>
> I've been mulling this over the last several days and I just can't
> accept an entire ruby function which would be ran for every parameter
> with the desired static value of "" when the class is
> declared and parsed. I am not generally against using functions as a
> parameter default just
On Wed, Sep 23, 2015 at 11:46 AM, Cody Herriges <c...@puppetlabs.com> wrote:
> Alex Schultz wrote:
>>> I've been mulling this over the last several days and I just can't
>>> accept an entire ruby function which would be ran for every parameter
>>> with the desir
Hey all,
So as part of the Puppet mid-cycle, we did bug triage. One of the
bugs that was looked into was bug 1289631[0]. This bug is about
applying the recommendations from the security guide[1] within the
puppet-swift module. So I'm sending a note out to get other feedback
on if this is a
On Wed, Sep 23, 2015 at 2:32 PM, Alex Schultz <aschu...@mirantis.com> wrote:
> Hey all,
>
> So as part of the Puppet mid-cycle, we did bug triage. One of the
> bugs that was looked into was bug 1289631[0]. This bug is about
> applying the recommendations from the sec
/?
> Does it work? Is it possible to install swift in a 'base-os' role node?
>
> On Fri, Sep 11, 2015 at 4:11 PM, Alex Schultz <aschu...@mirantis.com>
> wrote:
>
>> Hey Daniel,
>>
>> So as part of the 7.0 work we added support in plugins to be able to
>&
Hey puppet folks,
Based on the meeting yesterday[0], I had proposed creating a parser
function called is_service_default[1] to validate if a variable matched our
agreed upon value of ''. This got me thinking about how
can we maybe not use the arbitrary string throughout the puppet that can
not
Hello!
So after our first round of librarian changes for 7.0, it is time to start
switching to upstream for more changes. We've had a few updates during the
fuel meetings over the last month[0][1]. I have begun to prepare
additional reviews to move modules.
The current modules available for
Hey Daniel,
So as part of the 7.0 work we added support in plugins to be able to create
roles and being able to separate roles from the existing system. I think
swift would be a good candidate for this. I know we also added in some
support for an external swift configuration that will be helpful
I agree that we shouldn't need to sync as we should be able to just update
the fuel-library package. That being said, I think there might be a few
issues with this method. The first issue is with plugins and how to
properly handle the distribution of the plugins as they may also include
puppet
ibrary package, so there's no
reason you couldn't try switching the rsync to install the package if it's
available on a mirror. I just think you're going to run into the issues I
mentioned which need to be solved before we could just mark it done.
-Alex
> Vladimir Kozhukalov
>
> On Wed, Sep 9, 2
Hey Vladimir,
>
> The idea is to remove MOS DEB repo from the Fuel master node by default
> and use online MOS repo instead. Pros of such an approach are:
>
> 0) Reduced requirement for the master node minimal disk space
>
Is this a problem? How much disk space is saved If I have to go create a
Hey Vladimir,
>
>
>> 1) There won't be such things in like [1] and [2], thus less complicated
>>> flow, less errors, easier to maintain, easier to understand, easier to
>>> troubleshoot
>>> 2) If one wants to have local mirror, the flow is the same as in case of
>>> upstream repos
Hey Marcos,
On Tue, Sep 1, 2015 at 7:50 AM, Marcos Fermin Lobo <
marcos.fermin.l...@cern.ch> wrote:
> Hi all,
>
> The standalone EC2 api project https://github.com/stackforge/ec2-api does
> not have puppet module yet. I want to develop this puppet module and my
> idea is start in a public Github
Hey Evgeniya,
On Tue, Aug 4, 2015 at 8:59 AM, Evgeniya Shumakher eshumak...@mirantis.com
wrote:
Fuel team,
One of Fuel 6.1 users found a very annoying bug:
I’ve installed new Mirantis 6.1 a couple of weeks ago and I’m seeing the
following message on both Controller and Compute node
on getting the iso together today and hopefully can get a
QA resource to test cinder out thoroughly. If QA is ok, this should be
merged on Tuesday 8/11.
cinder - https://review.openstack.org/#/c/203394/
Thanks,
-Alex
On Fri, Jul 31, 2015 at 12:11 PM, Alex Schultz aschu...@mirantis.com
wrote:
Here
if something goes wrong.
So there is a list of action items:
Alex Schultz will send a schedule of which modules will be merged on which
week and ensure that core reviewers know which commits they should merge
when either by keeping W-1 on particular commits or by sharing the schedule
in commit message
Hey Emilien,
On Wed, Jul 29, 2015 at 5:16 PM, Emilien Macchi emil...@redhat.com wrote:
This is a very good initiative and I'm happy to see that happening. It
reflects what I was asking in our collaboration request.
Though I have one suggestion for Custom Upstream Module Changes section.
I
Hey everyone,
During on the fuel meeting today we discussed the librarian changes and
their status.
As part of this work, the wiki page was updated and a first attempt at
migrating the
following modules has been completed pending merge:
stdlib
concat
inifile
ssh
ntp
apache
firewall
xinetd
cinder
Hello everyone,
I have put together a wiki describing the proposed interactions between
fuel-library and upstream modules based on previous talks around
librarian-puppet[0]. Please take some time to review
https://wiki.openstack.org/wiki/Fuel/Library_and_Upstream_Modules. This
page provides a
https://www.rabbitmq.com/ha.html
Both? I think ha_all/HA is just the policy name and so it can be whatever
you want.
-Alex
On Tue, Jul 28, 2015 at 2:17 AM, Alvise Dorigo alvise.dor...@pd.infn.it
wrote:
Hi,
I read these two documents:
Just to followup since the required packages are finally available, the
patches have been updated and are passing CI now.
https://review.openstack.org/#/c/202763/
-Alex
On Fri, Jul 24, 2015 at 8:32 AM, Alex Schultz aschu...@mirantis.com wrote:
Unfortunately we got stuck with package
wrote:
Do we have any success here.. ?
On Mon, Jul 20, 2015 at 8:32 AM Alex Schultz aschu...@mirantis.com
wrote:
Vladimir,
Thanks. Can you point me to the error for perestroika? I'd be happy to
take a look as well. I spent most of Friday throwing various options at the
CI system to try
For this to be consumable by end-users, a config file and editor (vim
seriously?) is terrible UX. We need to remember who we are targeting to
consume this functionality as it may not be an expert or even someone
absolutely familiar with the linux tool set. While the existing thing may
be
via
HTTP. Please check here
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
if the package contains all necessary upstream modules.
Vladimir Kozhukalov
On Sat, Jul 18, 2015 at 3:28 AM, Alex Schultz aschu
As a new contributor to any openstack project, this is the first thing I
do. Find out when the weekly meetings is, attend and monitor the
conversion. Almost always there is an open discussion at the end of the
weekly business.
Going back through the last 5 weeks of irclogs[1], I couldn't
script execution to do the module fetch.
The creation of the script isn't the issue, the issue is how can I properly
run it as part of the build process.
Regards,
Alex
Thanks,
-Alex
On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz aschu...@mirantis.com
wrote:
Hello everyone,
I have committed
[0] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L16-L37
[1] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L45
On Fri, Jul 17, 2015 at 2:37 PM, Alex Schultz aschu...@mirantis.com
wrote:
Hey Alex,
On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com
Hey Yanis,
On Fri, Jul 17, 2015 at 3:56 AM, Yanis Guenane yguen...@redhat.com wrote:
Hello everyone,
Based on the conversation we had during last meeting I went ahead and
created an
ini_setting provider[1] that will act as a proxy between our provider
and the
upstream one, this way we
some way to validate that the module was pulled in
properly as part of fuel-library CI?
On Fri, Jul 17, 2015 at 2:48 PM Alex Schultz aschu...@mirantis.com
wrote:
Hey All,
I've figured it out without having to modify the fuel-main build code.
I've updated the fuel-library spec with a build
this monday morning?
Vladimir Kozhukalov
On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz aschu...@mirantis.com
wrote:
Hey Vladimir,
On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
Alex,
Gathering upstream modules certainly should be implemented
at 5:51 PM, Alex Schultz aschu...@mirantis.com
wrote:
Hey Vladimir,
On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
Alex,
Gathering upstream modules certainly should be implemented as a
separate script so as to make it possible to use it wherever we need
Hello everyone,
I have committed the initial configuration required to start leveraging
librarian-puppet as part of the way we pull in upstream puppet modules[0].
Additionally, I have also committed a change that would pull in the
openstack-ironic module[1]. The one piece that is missing from
Done. Sorry about that.
-Alex
On Fri, Jul 10, 2015 at 9:22 AM, Simon Pasquier spasqu...@mirantis.com
wrote:
Alex, could you enable the comments for all on your document?
Thanks!
Simon
On Thu, Jul 9, 2015 at 11:07 AM, Bogdan Dobrelya bdobre...@mirantis.com
wrote:
Hello everyone,
I
Hello everyone,
I took some time this morning to write out a document[0] that outlines
one possible ways for us to manage our upstream modules in a more
consistent fashion. I know we've had a few emails bouncing around
lately around this topic of our use of upstream modules and how can we
improve
everyones' lives easier would be
welcomed.
Thanks,
-Alex Schultz
On Thu, Jun 11, 2015 at 4:03 PM, Matt Fischer m...@mattfischer.com wrote:
We as a community don't do a great job watching bugs, so personally I'd
prefer that fuel developers just push patches, filing a bug too if you want.
(Note: we
301 - 369 of 369 matches
Mail list logo