;re
sure the gate is much better.
Thanks,
-Alex
On Wed, Oct 31, 2018 at 9:39 AM Alex Schultz wrote:
>
> Hey folks,
>
> So we have identified an issue that has been causing a bunch of
> failures and proposed a revert of our podman testing[0]. We have
> cleared the gate and are aski
d to figure out the correct way forward
with these packages.
Thanks,
-Alex
[0] https://review.openstack.org/#/c/550848/
> On 10/31/18 6:35 PM, Alex Schultz wrote:
> >
> > So this is a single layer that is updated once and shared by all the
> > containers that inherit fro
Just a heads up but we recently updated to puppet5 in the master
dependencies. It appears that this has completely hosed the master
scenarios and containers-multinode jobs. Please do recheck/approve
anything until we get this resolved.
See https://bugs.launchpad.net/tripleo/+bug/1803024
I have a
+1
On Thu, Nov 15, 2018 at 8:51 AM Sagi Shnaidman wrote:
>
> Hi,
> I'd like to propose Quique (@quiquell) as a core reviewer for TripleO. Quique
> is actively involved in improvements and development of TripleO and TripleO
> CI. He also helps in other projects including but not limited to
> Inf
On Mon, Nov 19, 2018 at 1:18 AM Tobias Urdin wrote:
>
> Hello,
>
> We've been talking for a while about the deprecation and removal of the
> stable/newton branches.
> I think it's time now that we get rid of them, we have no open patches
> and Newton is considered EOL.
>
> Could cores get back wit
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 switc
xy is damn conveniently, I don't think it should
>> 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, 201
trollers and UCA for Compute 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 wrote:
>>
>> Hey Vladimir,
>>
>> On Tue, Nov 10, 2015 at 5:56 AM, Vladimir Kuklin
&
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 wrote:
>>
>> On Tue
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 bu
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 node.
>
> However, after
hat 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:41 PM, Alex S
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 the need to restart the
>
+1 great job Ivan
On Thu, May 19, 2016 at 8:32 AM, Matt Fischer wrote:
> +1 from me!
>
> On Thu, May 19, 2016 at 8:17 AM, Emilien Macchi
> wrote:
>
>> Hi,
>>
>> I don't need to introduce Ivan Berezovskiy (iberezovskiy on IRC), he's
>> been doing tremendous work in Puppet OpenStack over the last
On Mon, Jun 27, 2016 at 7:10 AM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Dear colleagues,
>
> I'd like to suggest to replace Fuel-ostf with Rally. Rally is quite
> popular project and as far as I know it has all necessary features
> (including dashboard). We only need to implement
+1
On Mon, Jun 27, 2016 at 9:04 AM, Bogdan Dobrelya
wrote:
> On 06/27/2016 04:54 PM, Sergii Golovatiuk wrote:
> > I am very sorry for sending without subject. I am adding subject to
> > voting and my +1
>
> +1 from my side!
>
> >
> > --
> > Best regards,
> > Sergii Golovatiuk,
> > Skype #golserg
On Mon, Apr 4, 2016 at 9:12 AM, Denis Egorenko
wrote:
> Hi Marcos,
>
> Are you still working on your initial commit to puppet-ec2api [1] ?
>
> [1] https://review.openstack.org/#/c/276103/
>
It might be a good idea to redo this review with a newer version of the
cookiecutter and split the ec2api
On Thu, Apr 7, 2016 at 7:41 AM, Aleksandr Didenko
wrote:
> Hi,
>
> thanks to Dima, we now have ROLE annotations in noop tests [0]. I've
> updated all the noop rspec tests that we currently have and added
> appropriate role annotation [1]. So after this patch is merged, we no
> longer need to put
Hey Fuelers,
We have been using our own fork of the haproxy module within fuel-library
for some time. This also includes relying on a MOS specific version of
haproxy that carries the conf.d hack. Unfortunately this has meant that
we've needed to leverage the MOS version of this package when deplo
k logic no longer
would control if something was included like sahara.
-Alex
[0]
https://review.openstack.org/#/c/307538/9/deployment/puppet/osnailyfacter/modular/cluster-haproxy/cluster-haproxy.pp
> On Thu, May 12, 2016 at 5:34 PM, Alex Schultz
> wrote:
> > Hey Fuelers,
> >
>
bix/manifests/ha/haproxy.pp#L16
> [2]
> https://github.com/openstack/fuel-plugin-lma-collector/blob/master/deployment_scripts/puppet/manifests/aggregator.pp#L60-L81
>
> On Thu, May 12, 2016 at 4:42 PM, Alex Schultz
> wrote:
>
>>
>>
>> On Thu, May 12, 2016 at 8:39 AM,
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 we could leave only 3.8 and
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:
> ["/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astut
.0/operations.html#setting-up-local-mirrors
Thanks,
-Alex
> On Fri, Dec 18, 2015 at 1:29 PM, Alex Schultz
> wrote:
>
>> Hey John,
>>
>>
>> On Fri, Dec 18, 2015 at 11:15 AM, John Menke wrote:
>>
>>>
>>>
>>>
>>&g
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 contains step which calls
> erase
On Wed, Jan 6, 2016 at 4:40 PM, Emilien Macchi 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 group:
>> * He
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, but one thing we
> can do
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 addr
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 this, some verbosity to ntpd
-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
> wrote:
>>
>
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 tasks and roles names,
>> Let's drop 3.3 as well. 3.4 is oldschool enough for vintage
>> >> lovers.
>> >>
>> >> BP
>> >>
>> >> On Thu, Jan 21, 2016 at 11:03 AM, Aleksandr Didenko
>> >> mailto:adide...@mi
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 referenced in the librarian P
Done. Sorry about that.
-Alex
On Fri, Jul 10, 2015 at 9:22 AM, Simon Pasquier
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
> wrote:
>
>> > Hello everyone,
>> >
>> > I took some time this morning to
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 thi
dge in an extra 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
wrote:
>>
>>
>> ./path/additional_build_script.sh && bash ./path/additional_build_script.sh
>> ) or as additional parameter to function and add it in fuel-library call [1]
>>
>> Regards,
>> Alex
>>
>> [0] https://github.com/stackforge/fuel-main/blob/master
Hey Yanis,
On Fri, Jul 17, 2015 at 3:56 AM, Yanis Guenane 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 don't have to f
d 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
> wrote:
>
>> Hey Vladimir,
>>
>> On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov <
>> vkozhuka...@mi
as
> possible so Alex can continue.
>
>
>> Vladimir Kozhukalov
>>
>> On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz
>> wrote:
>>
>>> Hey Vladimir,
>>>
>>> On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov <
>>> vkozhu
e 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
> wrote:
>
>> Hey All,
>>
>> I've figured it out without having to modify the fuel-main build code.
>> I've upda
>
> 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 cou
ry7.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
>> wrote:
>>
>>> Not until we start using it then any ci that tests
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 awkward,
akov
wrote:
> Do we have any success here.. ?
>
> On Mon, Jul 20, 2015 at 8:32 AM Alex Schultz
> 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 throwin
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 wrote:
> Unfortunately we got stuck with package availability issues. It
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
wrote:
> Hi,
> I read these two documents:
>
>
> http://docs.openstack.org/high-availability-guide/content/_configure_rabb
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 br
Hey Emilien,
On Wed, Jul 29, 2015 at 5:16 PM, Emilien Macchi 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 suggest y
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
mething 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
Hey Evgeniya,
On Tue, Aug 4, 2015 at 8:59 AM, Evgeniya Shumakher
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 consoles.
>>>
>
an 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
wrote:
> Here is the proposed
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
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 code
ce. We already build the fuel-library 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
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 (fuel-createmir
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
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 mig
.openstack.org/#/c/188599/?
> 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
> 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 ea
>
> 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 not
On Wed, Sep 23, 2015 at 11:46 AM, Cody Herriges 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 desired static value
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 good
On Wed, Sep 23, 2015 at 2:32 PM, Alex Schultz 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 security guide[1] within the
> puppet
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
> * this way does not all
On Thu, Sep 24, 2015 at 11:54 AM, Emilien Macchi wrote:
>
>
> On 09/24/2015 10:14 AM, Alex Schultz wrote:
>> On Wed, Sep 23, 2015 at 4:56 PM, Emilien Macchi wrote:
>>> Background
>>> ==
>>>
>>> Current rspec tests are tested with m
On Thu, Sep 24, 2015 at 1:58 PM, Emilien Macchi wrote:
>
>
> On 09/24/2015 02:19 PM, Alex Schultz wrote:
>> On Thu, Sep 24, 2015 at 11:54 AM, Emilien Macchi wrote:
>>>
>>>
>>> On 09/24/2015 10:14 AM, Alex Schultz wrote:
>>>>
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
upstre
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
>>> to the list of supported p
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 o
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 for an
open-source projec
e test and
merge issues, so anything to make everyones' lives easier would be
welcomed.
Thanks,
-Alex Schultz
On Thu, Jun 11, 2015 at 4:03 PM, Matt Fischer wrote:
> We as a community don't do a great job watching bugs, so personally I'd
> prefer that fuel developers just p
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
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 declaration.
> Or
> > wri
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 Fuel
> (release contains
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
> question will help ot
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 packages
> but as pip packages.
+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 amount of features, such a
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 for adding version
> 9.0 to
+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 wrote:
>
>> Emilien Macchi wrote:
>>
On Mon, Mar 21, 2016 at 7:21 AM, Volodymyr Shypyguzov <
vshypygu...@mirantis.com> wrote:
> Hi, all
>
> Just wanted to inform you, that shotgun2 now has new command short-report,
> which allows you to receive shorter and cleaner output for attaching to bug
> description, sharing, etc.
>
> Usage: sh
7;s very hard to address issues if you cannot reproduce the
environment they occur on. I'm trying to make sure we are providing all
the information to aid in reproducing issues to get them fixed and not just
providing more information that is ultimately ignored because it's useless.
eport is to be used for internal QA team purposes only.
>
>
>
Once again, I'm just asking for more information as to the intended usage
of this new command and asking that this information be made public.
Thanks,
-Alex
>
>
>
> Vladimir Kozhukalov
>
> On Mon
Hey everyone,
Emilien is in the process of cutting the stable/mitaka branches for all of
the upstream puppet modules. As Fuel approaches SCF, we will want to
switch from the master branches we are currently tracking to leverage the
stable/mitaka branches. In talking with some other folks, I beli
On Fri, Mar 25, 2016 at 7:32 AM, Dmitry Guryanov
wrote:
> Here is the bug which I'm trying to fix -
> https://bugs.launchpad.net/fuel/+bug/1538587.
>
> In VMs (set up with fuel-virtualbox) kernel panic occurs every time you
> delete node, stack trace shows error in ext4 driver [1].
> The same as
Hey Puppet Folk,
Just a reminder, but we will be having our meeting tomorrow. Please
add something to the meeting etherpad[0] if you have a specific topic
you wish to talk about.
Thanks,
-Alex
[0] https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20170307
Hey Stefan,
On Tue, Mar 7, 2017 at 7:09 AM, Scheglmann, Stefan wrote:
> Hi,
>
> currently got some problems running the beaker test for the puppet-cep
> module. Working on OSX using Vagrant version 1.8.6 and VirtualBox version
> 5.1.14. Call is 'BEAKER_destroy=no BEAKER_debug=1 bundle exec --v
Ahoy folks,
I would like to bring attention to deriving version numbers for puppet
modules (for packaging) as part of the release process. Today we
uncovered an issue[0] in the way that version numbers were being
derived for packages which ultimately broke the TripleO CI upgrade
jobs because the
On Wed, Mar 8, 2017 at 9:02 AM, Scheglmann, Stefan wrote:
> Hey Alex,
>
> thx for the reply, unfortunately it doesn’t seem to work. Adding
> PUPPET_MAJ_VERSION to the call seems not to have any effect.
>
I just read the bottom part of the original message and it's getting a
14.04 box from puppet
On Thu, Mar 9, 2017 at 10:54 AM, Doug Hellmann wrote:
> Excerpts from Alex Schultz's message of 2017-03-07 12:56:17 -0700:
>> Ahoy folks,
>>
>> I would like to bring attention to deriving version numbers for puppet
>> modules (for packaging) as part of the release process. Today we
>> uncovered a
The agenda[0] was empty. So canceling the meeting for this week. The
next meeting will be on Mar 21, 2017 @ 1500 UTC. Feel free put
something on the agenda[1].
Thanks,
-Alex
[0] https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20170314
[1] https://etherpad.openstack.org/p/puppet
Ahoy folks,
For the Pike cycle, we have a blueprint[0] to provide a few basic
environment configurations with some custom roles. For this effort
and to reduce the complexity when dealing with roles I have put
together a patch to try and organize roles in a more consumable
fashion[1]. The goal be
but is currently out of scope
for this effort in Pike. I would like to see improvements in how we
are exposing these services/roles to the end user. I agree that
rolling this into a workflow would be a good idea.
Thanks,
-Alex
> Regards,
> Saravanan KR
>
> On Thu, Mar 16, 2017 at 3:37 AM
On Tue, Mar 21, 2017 at 3:45 PM, John Dickinson wrote:
> I've been following this thread, but I must admit I seem to have missed
> something.
>
> What problem is being solved by storing per-server service configuration
> options in an external distributed CP system that is currently not possible
On Tue, Mar 21, 2017 at 5:35 PM, John Dickinson wrote:
>
>
> On 21 Mar 2017, at 15:34, Alex Schultz wrote:
>
>> On Tue, Mar 21, 2017 at 3:45 PM, John Dickinson wrote:
>>> I've been following this thread, but I must admit I seem to have missed
>>> someth
On Wed, Mar 22, 2017 at 12:23 AM, Tim Bell wrote:
>
>> On 22 Mar 2017, at 00:53, Alex Schultz wrote:
>>
>> On Tue, Mar 21, 2017 at 5:35 PM, John Dickinson wrote:
>>>
>>>
>>> On 21 Mar 2017, at 15:34, Alex Schultz wrote:
>>>
>>>&g
On Wed, Mar 22, 2017 at 7:58 AM, Paul Belanger wrote:
> On Tue, Mar 21, 2017 at 05:53:35PM -0600, Alex Schultz wrote:
>> On Tue, Mar 21, 2017 at 5:35 PM, John Dickinson wrote:
>> >
>> >
>> > On 21 Mar 2017, at 15:34, Alex Schultz wrote:
>> >
>>
On Thu, Mar 23, 2017 at 7:43 AM, pranab boruah
wrote:
> Hi, I am trying to install triple-o undercloud on a physical machine.
> The installation fails every time. I have reinstalled the OS and tried
> starting from scratch but got the same error.
>
> System Details :
>
> DELL t620 with IPMI suppor
1 - 100 of 370 matches
Mail list logo
