Mike -
I'm not a fuel-docs core, so it's up to fuel-docs-core team to remove
*dead* cores. According to Stackalytics [1] Irina Povolotskaya's
showing a low contribution rate. Regarding Vitaly, I don't know why
Stackalytics marks him as core, since he's not a member of gerrit core
group [2].
- Igo
Hi,
Looks like a file went AWOL from pypi:
https://github.com/micheles/decorator/commits/master/
I am baby-sitting this requirements review on zuul:
https://review.openstack.org/#/c/256238/
That will fix the upper-constraints.txt and will help fix the breaks.
Thanks,
Dims
--
Davanum Srinivas
-Original Message-
From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
Sent: 10 December 2015 12:56
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to caller
-Original Message-
From:
Do you think that then we should mark it as 'deprecate'? so it throws a
warning when called until we finally decide to drop it off in a future
cycle?
El 11/12/15 a las 03:52, GHANSHYAM MANN escribió:
> Hi,
>
> Yes, That's very valid point about there might be some real users or in
> future.
>
> S
Hello Vladimir,
I definitely agree that using one uri for generating number of repos is not
the best solution.
According to Fuel Menu - there was the discussion in gerrit [1] about
repositories format. The first version of my patch implements actually your
idea about equality and independence of r
Jeremy Stanley wrote:
> On 2015-12-10 18:20:44 + (+), Flavio Percoco wrote:
>> Has this been attempted? Any objections? Is there something I'm not
>> considering?
>
> I'm not aware of any work so far to that end, but have a feeling you
> could reuse http://git.openstack.org/cgit/openstack-
Hey folks -
+1 from my side on the idea of having the unified repo format. It will
simplify a cross-project contribution. I think we can file a blueprint
for 9.0.
I have only two questions to discuss:
* We need to declare format for RPM repos either.
* Shouldn't we use slightly different set of
Review has merged, it's safe to recheck your reviews now.
thanks,
Dims
On Fri, Dec 11, 2015 at 12:16 PM, Davanum Srinivas wrote:
> Hi,
>
> Looks like a file went AWOL from pypi:
> https://github.com/micheles/decorator/commits/master/
>
> I am baby-sitting this requirements review on zuul:
> http
Hi,
I agree with the idea of unification for repo configurations, but it
looks like we are developing yet another standard.
Do we really need a custom format? Why can not we use native format
for yum.conf and apt.sources files, and native tooling (all those
python bindings, cli utils and so on) w
There are common practices developed by operating system developers, and
thousands of people using them every day.
Redefining that experience will bring nothing more but questions and
misunderstanding, because if someone has questions, instead of hundreds already
written manuals a person would
Hello.
On 02.12.2015 12:01, Bogdan Dobrelya wrote:
>> Bogdan,
>>
>> Which service would use this flag to start with? and how would the
>> code change to provide "app side is fully responsible for duplicates
>> handling"?
>
> (fixed topic tags to match oslo.messaging)
>
> AFAIK, this mode is requ
Hello.
I am trying to pick a way of making puppet
manifest fuel-library/deployment/puppet/osnailyfacter/modular/apache/apache.pp
idempotent.
During a normal execution flow, Fuel (fuel-astute, actually) would run
"apache" task before running other tasks, which create virtual host
configuration file
Hi,
This is a question regarding design of clients and managers in a tempest plugin.
I'm not familiar with tempest, but it seems that there are the following terms:
Client: client of service or feature (part of service)
ClientManager: having clients which are needed for particular tes
Hello,
Trying to install the Monasca through vagrant stuff. On the 'vagrant
provision' step, getting the threshold smoke failure.
Any clue what might be the cause. I am in Ubuntu 15.10:
pradipm@pradipm-ThinkPad-W530:~$ uname -a
Linux pradipm-ThinkPad-W530 4.2.0-19-generic #23-Ubuntu SMP Wed Nov
> Do we really need a custom format? Why can not we use native format
> for yum.conf and apt.sources files
Because we don't want to parse this format each time we want to verify
/ handle particular component of this format. Moreover, there's no,
for example, priority in Debian repo format. Priorit
This thread is not about format itself, but about the approach when all
repos are thought independently. I.e. no patterns like this suite,
suite-updates, suite-security, no limitations for suite and suite-updates
should be located on the same host. It should be flat list of independent
repos. There
Regarding to UI. Of course, we could provide native format to a user on UI.
Although I don't think it would be much easier to edit, but it is flexible
enough to define something like this:
http://url trusty main
http://anotherurl trusty universe multiverse restricted
http://yet-another-url trusty-
Hi folks,
my sense of aesthetics was slightly disturbed when I saw that the mounts
fact[1] is implemented by joining mount points using a comma.
It turns out that what Alex did is completely right as Puppet up to 3.8
release has enabled stringify_facts by default. TLDR of that setting is
that any
Hi Tomi,
It looks like CLI was not added from the beginning of virtual-interface
history[1]. Jichenjc works on patch[2] to fix this issue.
[1] - https://review.openstack.org/#/c/3368/
[2] - https://review.openstack.org/#/c/254707/
On Thu, Dec 10, 2015 at 1:26 PM, Juvonen, Tomi (Nokia - FI/Espo
Hi all,
So, after the painful process of getting CI working for stable/liberty,
everything is now working pretty well, and I have a few small requests to
hopefully help improve velocity for backports landing:
1. Please use git "cherry-pick -x" when backporting from master - this is a
small detail
> -Original Message-
> From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
> Sent: 11 December 2015 09:19
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to
> caller
>
>
>
> -Original Me
Hi Mike,
Yes, I agree that we cannot move blueprints to "Implemented" unless all
dependencies are complete (incl tests and doc). Probably we can use "Beta
available" for such tickets instead of "Deployment" as we can already try
the functionality.
All development-related child blueprints for [1]
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, 2015
Hi,
I suppose disabling purge_configs is the only solution here. Running all
the configuration in a single task does not fit well into deployment
granularization philosophy.
Regards,
Alex
On Fri, Dec 11, 2015 at 12:13 PM, Dmitry Bilunov
wrote:
> Hello.
>
> I am trying to pick a way of making p
Hi,
I agree, let's do this.
Regards,
Alex
On Fri, Dec 11, 2015 at 1:08 PM, Bartłomiej Piotrowski <
bpiotrow...@mirantis.com> wrote:
> Hi folks,
>
> my sense of aesthetics was slightly disturbed when I saw that the mounts
> fact[1] is implemented by joining mount points using a comma.
>
> It tur
Folks, when you get consensus here, please file a bug - it's most likely
fixable in 8.0.
2015-12-11 14:44 GMT+03:00 Vladimir Kozhukalov :
> Regarding to UI. Of course, we could provide native format to a user on
> UI. Although I don't think it would be much easier to edit, but it is
> flexible en
Hello, Vladimir.
Seems nothing is better for end-user in UI/fuel-mirror/image-bootstrap than
'You Get What You See' because system administrator should not learn new
standard:
http://url trusty main
http://anotherurl trusty universe multiverse restricted
http://yet-another-url trusty-my-favorite-up
I'd like this module
https://github.com/openstack/fuel-menu/blob/master/fuelmenu/modules/bootstrapimg.py
to be fixed so a user can define several repos independently. This
particular ML thread is not about internal repo data format, it is not
about particular format that we expose to end user. This
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://github.com/openst
Folks,
First, let me report current feature status: we continued the work with
Bogdan Dobrelya and Sergii Golovatiuk. I have incorporated their feedback
into the change. Also, I have fully tested it on custom ISO and Fuel CI
passes successfully. Also, I have an approval from Bogdan on the
implemen
Hi friends,
As you may already know from my IRC/gerrit spam, I'm working hard to
move Ironic to using devstack and grenade plugins, rather than being in
those projects directly. I wanted to lay out some notes on that here so
people know what's going on.
* The patches are all in this gerrit topic:
Fuelers,
for a long time functional tests in Fuel Client were not triggered by Fuel CI
because of a pesky bug [1] in our tox.ini. The fix [2] for it was landed a few
minutes ago.
Since we don’t have gate jobs that trigger functional tests, I gently ask you
to rebase your patches for Fuel Clien
I think we should turn it on in the next release. That would be really nice
to have it.
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
On Fri, Dec 11, 2015 at 2:50 PM, Aleksandr Didenko
wrote:
> Hi,
>
> I agree, let's do this.
>
> Regards,
> Alex
>
> On Fri, Dec 11, 2015 at 1:0
Hi Dmitry,
I would like not to overcomplicate blueprints. If additional work is
required there should be additional dependent blueprint. This will help us
to deliver all blueprints on time while other teams are working on own
blueprints (e.g. Documentation) with own release cadence.
[1] https://w
If there are no any objections, let's do fix fuel-menu ASAP. As Fedor said
this approach was suggested first, but then it was rejected during review
process. It should not be so hard to get it back. Fedor, could you please
confirm that it is possible to do this before SCF? Here is the bug
https://b
Oleg,
thanks. I've tried it [1], looks like it works.
- GOOD. "override_resource" resource. Like "back door" into puppet modules.
- BAD. It allows just apply, not track changes. Moreover works weird,
if multiple changes uploaded, applying not the latest, but initial
config change.
- BAD. Just lim
RFC5424 requires timestamps in a strict subset of RFC3339. Currently,
oslo.log has no way to provide dates in this format without specifying a
custom logging formatter, which means that oslo.log is incapable of
providing RFC5424-compliant log messages.
I've proposed a proof-of-concept to add that
Hi folks!
As it was decided during the Mitaka design summit, we are separating the
experimental Artifact Repository API from the main Glance API. This API
will have a versioning sequence independent from the main Glance API and
will be run as a standalone optional service, listening on the port
di
Hi Alex,
Searchlight uses port 9393 (it also made sense to us when we spun out of
Glance!), so we would prefer it if there's another one that makes sense.
Regarding the three hardest things in computer science, searchlight's already
dealing with cache invalidation so I'll stay out of the naming
On Fri, Dec 11, 2015, at 10:12 AM, Chris St. Pierre wrote:
> RFC5424 requires timestamps in a strict subset of RFC3339. Currently,
> oslo.log has no way to provide dates in this format without specifying a
> custom logging formatter, which means that oslo.log is incapable of
> providing RFC5424-com
Hi Steve,
Thanks for the note on port. Any objections on glare using 9494 then?
Anyone?
Пт, 11 дек. 2015 г. в 21:39, McLellan, Steven :
> Hi Alex,
>
> Searchlight uses port 9393 (it also made sense to us when we spun out of
> Glance!), so we would prefer it if there's another one that makes sense
The port is an arbitray choice for developers running on standalone
services over HTTP. Just don't choose something in the linux ephemeral port
range :) In production, assume all services can be deployed on 443.
As for service *type*, it should not include project names, code names, API
versions,
On Thu, Dec 10, 2015 at 06:20:44PM +, Flavio Percoco wrote:
>
> With the new home for the release schedule, and it being a good place
> for projects to add their own deadlines as well, I believe it would be
> good for people that use calendars to have these .ics being generated
> and linked th
Perma Link:
http://www.openstack.org/blog/2015/12/openstack-developer-mailing-list-digest-20151205/
Success Bot Says
* AJaeger: With Juno End-of-Life, Python 2.6 testing has been removed from
OpenStack CI.
* Tell us yours via IRC with a message “#success [insert success]”.
* Mo
Hi Nikolay,
Is there further information I could provide about the bug?
Thanks.
--Vahid
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscr
Dear colleagues,
At the moment part of the Fuel master deployment logic is located in ISO
kickstart file, which is bad. We'd better carefully split provisioning and
deployment stages so as to install base operating system during
provisioning stage and then everything else on the deployment stage.
The CRUD operations for Nova volume attachments have inconsistencies
between documentation and implementation. Additionally, the read/get
operation is implemented twice under different URIs. What is Nova's
direction for volume attachment APIs and how should the following
discrepancies be resolved
Vahid,
The bug you mentioned was fixed recently:
https://review.openstack.org/#/c/255154/
Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis
On Fri, Dec 11, 2015 at 10:46 PM, Vahid S Hashemian <
vahidhashem...@us.ibm.com> wrote:
> Hi Nikolay,
>
> Is there further information I
On 12/11/15, 12:25, "Alexander Tivelkov" wrote:
>Hi folks!
>
>
>As it was decided during the Mitaka design summit, we are separating the
>experimental Artifact Repository API from the main Glance API. This API
>will have a versioning sequence independent from the main Glance API and
>will be ru
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 some fuelmenu-like lightweight UI, or via
WebUI).
Thus, fuel package must install everything that is required for runn
sorry, my email was blocking the list for a bit so i missed this.
the original reason this was implemented i believe was to track alarm
state changes as an event in ceilometer events. i still see this as a
valid use case but it does duplicate some of the functionality of alarm
history.
i thi
> On Dec 10, 2015, at 12:56 AM, Alvise Dorigo wrote:
>
> So my question is: is there any progress on this topic ? is there a way
> (something like a cronjob script) to make the metadata-agent redundant
> without involving the clustering software Pacemaker/Corosync ?
Reason for such a dirty so
Hi all,
On Wed, Dec 2, 2015 at 7:47 PM, Mike Scherbakov
wrote:
> Hi all,
> we ran a meeting and made a decision on feature freeze exceptions. Full
> log is here:
> https://etherpad.openstack.org/p/fuel-8.0-FF-meeting
>
> The following features were granted with feature freeze exception:
>
>1
Hi all,
Today TripleO CI jobs failed because a new commit introduced on
puppetlabs-mysql[1].
Mr. Jiri Stransky solved it as a temporally fix by pinning the puppet
module clone to a previous
commit in the tripleo-common project[2].
source-repositories puppet element[3] allows you to pin the puppet
Today (Dec 12) there was an update performed to gerrit web server changing
how apache proxies requests to the java application. This change is in
preperation for the update of gerrit planned for December 16th. We have
moved from utilizing mod_rewrite to directly using mod_proxy. In performing
this
Folks,
The meeting will be at the Cisco Campus, Building I (eye).
Here it is the address:
Cisco Building I (eye)
285 W. Tasman Drive
San Jose
California
95134
United States
I will provide more details beginning of January.
I am also trying to get a Monasca mid-cycle to happen the same week at t
Hello Fuelers,
Due to a very large scope of the original bp/spec, it had to be split into
3 smaller ones.
Currently, there is one blueprint[1] available. It covers root access to
openstack nodes.
It basically comes down to following:
- Allow user to specify account name(s) to create and configur
On 3 December 2015 at 10:46, Carl Baldwin wrote:
> I was going to bring this up in the meeting this morning but IRC
> troubles prevented it.
>
> After chatting with Armando, I'd like to suggest a few enhancements to
> how we're tackling DVR during this cycle. I'm hoping that these
> changes help
Fuelers
I am thrilled to announce that task based deployment engine [0] has been
just merged into Fuel master. We checked it against existing BVT test cases
for regressions as well as against functional testing for several cases of
deployment. All the OSTF and network verification tests have succe
Hi Armando/Carl,
Yes based on Carl’s recommendation I have categorized the bugs in the Wiki
below right now. If you think adding an Etherpad will be more appropriate, we
can add one.
https://wiki.openstack.org/wiki/Meetings/Neutron-DVR
Thanks
Swami
From: Armando M. [mailto:arma...@gmail.com]
S
oslo-incubator is EOL now but it's missing a stable/liberty branch, and
we need one for backporting changes that will be synced to projects in
liberty. I'm not sure what commit would be used to create the
stable/liberty branch though.
--
Thanks,
Matt Riedemann
_
On 12/11/2015 1:48 PM, Sam Matzek wrote:
The CRUD operations for Nova volume attachments have inconsistencies
between documentation and implementation. Additionally, the read/get
operation is implemented twice under different URIs. What is Nova's
direction for volume attachment APIs and how s
Latest update: all implemented now.
Task-based deployment was the last one, and it got merged today:
http://lists.openstack.org/pipermail/openstack-dev/2015-December/082093.html
.
Great work everyone!
On Fri, Dec 11, 2015 at 12:48 PM Sergii Golovatiuk
wrote:
> Hi all,
>
> On Wed, Dec 2, 2015 at
Hi Thang, Vincent,
I guess the root cause is that finish_volume_migration() still
handles a volume as a dictionary instead of volume object and
the method returns dict volume.
And then, 'rpcapi.delete_volume()' in migrate_volume_completion()
tries to delete dict volume but it fails due to the fo
On 8 December 2015 at 11:56, Doug Wiegley
wrote:
> I actually found this week’s meeting more useful than normal. The typical
> agenda items feel rote and less useful to aligning things, sort of,
> thinking out loud.
>
>
Ok, let's keep chewing at the list. We'll send a reminder shortly.
> doug
>
Hi Ryota,
That is the one way as you mentioned.
On Fri, Dec 11, 2015 at 8:15 PM, Ryota Mibu wrote:
> Hi,
>
>
> This is a question regarding design of clients and managers in a tempest
> plugin.
>
>
> I'm not familiar with tempest, but it seems that there are the following
> terms:
>
> Clie
On 11 December 2015 at 15:23, Vasudevan, Swaminathan (PNB Roseville) <
swaminathan.vasude...@hpe.com> wrote:
> Hi Armando/Carl,
>
> Yes based on Carl’s recommendation I have categorized the bugs in the Wiki
> below right now. If you think adding an Etherpad will be more appropriate,
> we can add o
On Fri, Dec 11, 2015 at 8:38 PM, Anne Gentle
wrote:
>
>
> On Fri, Dec 11, 2015 at 7:33 PM, Matt Riedemann <
> mrie...@linux.vnet.ibm.com> wrote:
>
>>
>>
>> On 12/11/2015 1:48 PM, Sam Matzek wrote:
>>
>>> The CRUD operations for Nova volume attachments have inconsistencies
>>> between documentatio
On Fri, Dec 11, 2015 at 7:33 PM, Matt Riedemann
wrote:
>
>
> On 12/11/2015 1:48 PM, Sam Matzek wrote:
>
>> The CRUD operations for Nova volume attachments have inconsistencies
>> between documentation and implementation. Additionally, the read/get
>> operation is implemented twice under differen
Matt,
Do you have an example? This was a deliberate decision to leave it out.
-- Dims
On Sat, Dec 12, 2015 at 4:35 AM, Matt Riedemann
wrote:
> oslo-incubator is EOL now but it's missing a stable/liberty branch, and we
> need one for backporting changes that will be synced to projects in liberty
On 12/11/15, 3:13 PM, "Ian Cordasco" wrote:
>On 12/11/15, 12:25, "Alexander Tivelkov" wrote:
>
>>Hi folks!
>>
>>
>>As it was decided during the Mitaka design summit, we are separating the
>>experimental Artifact Repository API from the main Glance API. This API
>>will have a versioning sequence
71 matches
Mail list logo