date:20160628

Hi Rodrigo,

Thanks for sharing your view on this. I will consider what other way I have to 
organize the docs.

I tried to extract the common parts and use '.. include::' as much as possible. 
The patch was huge already. I'm afraid what you're saying would result in even 
more duplication which is not ideal. I also like having less sections the user 
has to check and put together as that makes it easier to follow the flow.

Best Regards,
/Ildikó

> -Original Message-
> From: Caballero Abraham, Rodrigo [mailto:rodrigo.caballero.abra...@intel.com]
> Sent: June 28, 2016 18:46
> To: Ildikó Váncsa; 'Spyros Trigazis'; OpenStack Development Mailing List (not 
> for usage questions); openstack-
> d...@lists.openstack.org
> Subject: RE: [OpenStack-docs] [openstack-dev] [telemetry] Ceilometer and Aodh 
> install guide(s)
> 
> snip
> >
> > Do you have a good proposal for structuring things?
> []
> I am assuming that you have distro specific instructions mixed with 
> non-specific ones.
> I can only suggest what has worked for me in the past. I created a common 
> file describing the process devoid of any instructions,
> distro specific or otherwise.
> Then I created distro specific procedures containing all the needed 
> instructions with the appropriate level of detail.
> The steps on the common file serve as the headings for all distro specific 
> procedures. That makes the common file an excellent
> introduction to all procedures while keeping the entire instructions in a 
> single place.
> 
> This system is not perfect however. There is some content repetition on the 
> instructions side of things.
> This could be avoided if we used the .. only:: directive on the instructions 
> side. You would then have a high level overview of the
> procedure, common to all distros, and a single file containing all 
> instructions for all distros differentiated by the only directive.
> 
> I guess what I am saying is that there is no magic bullet here. At the end of 
> the day, the content determines what modularity model
> you can use, IMO.
> Regards,
> Rodrigo
> >
> > Thanks,
> > /Ildikó
> snip
__
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/openstack-dev

Re: [openstack-dev] [OpenStack-docs] [telemetry] Ceilometer and Aodh install guide(s)

Hi Andreas,

If we would end up moving more guides to the project tree then it will be 
confusing having multiple top level docs folder in a basically code repository.

Can that be an option to have a top level 'doc' folder and having sub-folders 
under like 'doc/developer', 'doc/install-guide', etc.?

Thanks and Best Regards,
/Ildikó

> -Original Message-
> From: Andreas Jaeger [mailto:a...@suse.com]
> Sent: June 28, 2016 15:12
> To: Ildikó Váncsa; openstack-d...@lists.openstack.org
> Cc: openstack-dev@lists.openstack.org
> Subject: Re: [OpenStack-docs] [telemetry] Ceilometer and Aodh install guide(s)
> 
> On 2016-06-28 14:55, Ildikó Váncsa wrote:
> > [...]
> > I have a third less urgent question. The install-guide has it's own folder 
> > at the same level where these two projects have their 'doc'
> folder. I would assume other projects have the same or similar folder for the 
> developer docs. Would that be reasonable/possible to
> have one main 'doc' folder for all the docs?
> 
> I understand the sentiment. The install-guide is a separate book, as
> Sean Dague called it nicely, which gets published to a different place,
> integrated into the full Install Tutorial. If you make it part of the
> developer documentation, it might integrate more nicely there but not in
> the overall cross-project Install Tutorial. Developer documentation is a
> separate book already and placing several books under doc will need even
> further changes to make it clear what goes where and how to publish.
> 
> So, I think the top-level folder is the best place for this,
> 
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


__
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/openstack-dev

Re: [openstack-dev] [OpenStack-docs] [telemetry] Ceilometer and Aodh install guide(s)

Hi Goutham,

Thanks, I already checked your solution briefly.

I will wait until there is some decision about the global way forward. If '.. 
only::' remains an option I might change the Ceilometer setup back.

Best Regards,
/Ildikó

> -Original Message-
> From: Ravi, Goutham [mailto:goutham.r...@netapp.com]
> Sent: June 28, 2016 15:32
> To: Ildikó Váncsa; openstack-d...@lists.openstack.org
> Cc: openstack-dev@lists.openstack.org
> Subject: Re: [OpenStack-docs] [telemetry] Ceilometer and Aodh install guide(s)
> 
> Hi Ildikó,
> 
> Please take a look at the tooling in https://review.openstack.org/#/c/317152/ 
> - I tried preserving the ‘only::’ tags because I had a
> similar concern about all the common parts to someone compiling the install 
> guide from time to time. We were discussing whether
> this was a good solution as opposed to using ‘include’ directives with 
> distro-specific files referencing common sections; or ignore both
> and maintain four different files (obs, debian, rdo, ubuntu) with common 
> sections included within each.
> 
> Thanks,
> Goutham
> 
> On 6/28/16, 8:55 AM, "Ildikó Váncsa"  wrote:
> 
> Hi,
> 
> I'm currently working on to move the Install Guide for Ceilometer [1] and 
> Aodh [2] under the project trees. I faced with a few
> difficulties so far about which I would like to ask your opinion.
> 
> First of all these two projects are under the Telemetry umbrella, so they are 
> not completely separate. I tried to name the services in
> the documents accordingly in the files. My question here would be whether 
> these two guides will be included in the overall document
> as two totally standalone services or we can link them together somehow?
> 
> The other question I had in mind is in connection with removing ".. only::". 
> As Ceilometer is integrated with several other projects it
> needs additional configuration steps, where we have distro specific steps to 
> follow. I chose the direction of extracting the common
> parts and reused them in the distro specific files. The end result still 
> looks ugly and I have concerns about maintainability. We merged a
> first version of the structure, but I'm happy to change if we can come up 
> with a better solution. Do you have suggestions on this?
> 
> I have a third less urgent question. The install-guide has it's own folder at 
> the same level where these two projects have their 'doc'
> folder. I would assume other projects have the same or similar folder for the 
> developer docs. Would that be reasonable/possible to
> have one main 'doc' folder for all the docs?
> 
> Thanks and Best Regards,
> Ildikó
> 
> [1] https://review.openstack.org/#/c/330051/
> [2] https://review.openstack.org/#/c/330048/
> 
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
> 

__
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/openstack-dev

Re: [openstack-dev] [nova] Do we require the 'next' link for paging, always?

2016-06-28 Thread Matt Riedemann

On 6/27/2016 9:57 PM, Alex Xu wrote:

Matt, thanks for the email, I +1 on the next page link. Then user
needn't build up link by themself.

I also have one more question after review those pagination patches:

As those pagination proposes change the default sort order. So should we
keep the sort order for old version API?
I think it should be yes. For instance-actions, it should keep the
order sorted by 'create_at' column in old versionAPI. The new version
API will sort the result by 'updated_at' column.

This sounds reasonable since we were already ordering on created_at for
instance actions:

https://github.com/openstack/nova/blob/0c5ff5057edcf1f9ab55a559804a5c0c6a8158b2/nova/db/sqlalchemy/api.py#L5976

But the question for keypairs and hypervisors, looks like they
didn't specify the sort order explicitly, so I think they should depend
on the DB implementation. Should we keep the old version API unspecified
sort order?

I think Andrew Laski made a comment about this in the keypairs change
also, that since we never explicitly guaranteed a sort order for these
before and never documented anything to that effect, enforcing a new
sort order should not be a problem, regardless of the microversion. The
natural sort order should be the auto-incrementing id but that's not
guaranteed. And the hypervisors pagination change is using id for
sorting. The keypairs change is sorting by name. I think at the summit
we even told Pavel to push a separate change before the microversion to
start ordering keypairs since we weren't going to support sort keys.

So I don't have a strong opinion either way. If it's just a difference
in which DB API method gets called per the microversion, that seems
simple enough to keep it working as it did before the pagination changes
are added. If it makes the code much more complicated though, then I'd
probably not try to retrofit the ordering, or lack thereof.

Thanks,

Matt Riedemann

__
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/openstack-dev

Re: [openstack-dev] [ironic] why do we need setting network driver per node?

2016-06-28 Thread Vladyslav Drok

Thanks for bringing this up Dmitry, here are my thoughts on this.

Another case is an out-of-tree network driver, that can basically do
whatever an operator needs to, and may have some parameters defined in
driver_info as is the case for most of other interfaces ironic drivers have.

I think neutron and flat drivers coexistence in the same deployment is
unlikely, but neutron and none or flat and none seems to be valid case. As
for nova, this might be as easy as adding an availability zone with nodes
that have network isolation enabled.

Also, with all the driver composition work, I think we don't want to have
some weird things like dhcp providers anymore and go further with
interfaces. And if it is an interface, it should be considered as such (the
basic spec containing most of the requirements is merged, and we can use it
to make network interface as close to the spec as possible, while not going
too far, as multitenancy slipping another release would be very bad). There
might be some caveats with backwards compatibility in this particular case,
but they're all solvable.

Thanks,
Vlad

On Tue, Jun 28, 2016 at 7:08 PM, Mathieu Mitchell 
wrote:

> Following discussion on IRC, here are my thoughts:
>
> The proposed network_interface allows choosing a "driver" for the network
> part of a node. The values could be something like "nobody", "neutron-flat
> networking" and "neutron-tenant separation".
>
> I think this choice should be left per-node. My reasoning is that you
> could have a bunch of nodes for which you have complete Neutron support,
> through for example an ML2 plugin. These nodes would be configured using
> one of the "neutron-*" modes.
>
> On the other hand, that same Ironic installation could also manage nodes
> for which the switches are unmanaged, or manually configured. In such case,
> you would probably want to use the "nobody" mode.
>
> An important point is to expose this "capability" to Nova as you might
> want to offer nodes with neutron integration differently from "any node". I
> am unsure if the capability should be the value of the network_interface or
> a boolean "neutron integration?". Thoughts?
>
> Mathieu
>
>
> On 2016-06-28 11:32 AM, Dmitry Tantsur wrote:
>
>> Hi folks!
>>
>> I was reviewing https://review.openstack.org/317391 and realized I don't
>> quite understand why we want to have node.network_interface. What's the
>> real life use case for it?
>>
>> Do we expect some nodes to use Neutron, some - not?
>>
>> Do we expect some nodes to benefit from network separation, some - not?
>> There may be a use case here, but then we have to expose this field to
>> Nova for scheduling, so that users can request a "secure" node or a
>> "less secure" one. If we don't do that, Nova will pick at random, which
>> makes the use case unclear again.
>> If we do that, the whole work goes substantially beyond what we were
>> trying to do initially: isolate tenants from the provisioning network
>> and from each other.
>>
>> Flexibility it good, but the patches raise upgrade concerns, because
>> it's unclear how to provide a good default for the new field. And anyway
>> it makes the whole thing much more complex than it could be.
>>
>> Any hints are welcome.
>>
>> __
>> 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/openstack-dev
>>
>
> __
> 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/openstack-dev
>
__
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/openstack-dev

Re: [openstack-dev] [all] Proposal: Architecture Working Group

2016-06-28 Thread Clint Byrum

Thanks everyone for participating and remaining positive and focused
on improving OpenStack. I've posted a review, and I'd like to encourage
everyone to move any future discussion of the Architecture Working group
to that review.

https://review.openstack.org/335141

Excerpts from Clint Byrum's message of 2016-06-17 14:52:43 -0700:
> ar·chi·tec·ture
> ˈärkəˌtek(t)SHər/
> noun
> noun: architecture
> 
> 1. 
> 
> the art or practice of designing and constructing buildings.
> 
> synonyms:building design, building style, planning, building, 
> construction; 
> 
> formalarchitectonics 
> 
> "modern architecture"
> 
> the style in which a building is designed or constructed, especially with 
> regard to a specific period, place, or culture.
> 
> plural noun: architectures
> 
> "Victorian architecture"
> 
> 2. 
> 
> the complex or carefully designed structure of something.
> 
> "the chemical architecture of the human brain"
> 
> the conceptual structure and logical organization of a computer or 
> computer-based system.
> 
> "a client/server architecture"
> 
> synonyms:structure, construction, organization, layout, design, build, 
> anatomy, makeup; 
> 
> informalsetup 
> 
> "the architecture of a computer system"
> 
> 
> Introduction
> =
> 
> OpenStack is a big system. We have debated what it actually is [1],
> and there are even t-shirts to poke fun at the fact that we don't have
> good answers.
> 
> But this isn't what any of us wants. We'd like to be able to point
> at something and proudly tell people "This is what we designed and
> implemented."
> 
> And for each individual project, that is a possibility. Neutron can
> tell you they designed how their agents and drivers work. Nova can
> tell you that they designed the way conductors handle communication
> with API nodes and compute nodes. But when we start talking about how
> they interact with each other, it's clearly just a coincidental mash of
> de-facto standards and specs that don't help anyone make decisions when
> refactoring or adding on to the system.
> 
> Oslo and cross-project initiatives have brought some peace and order
> to the implementation and engineering processes, but not to the design
> process. New ideas still start largely in the project where they are
> needed most, and often conflict with similar decisions and ideas in other
> projects [dlm, taskflow, tooz, service discovery, state machines, glance
> tasks, messaging patterns, database patterns, etc. etc.]. Often times this
> creates a log jam where none of the projects adopt a solution that would
> align with others. Most of the time when things finally come to a head
> these things get done in a piecemeal fashion, where it's half done here,
> 1/3 over there, 1/4 there, and 3/4 over there..., which to the outside
> looks like  chaos, because that's precisely what it is.
> 
> And this isn't always a technical design problem. OpenStack, for instance,
> isn't really a micro service architecture. Of course, it might look like
> that in diagrams [2], but we all know it really isn't. The compute node is
> home to agents for every single concern, and the API interactions between
> the services is too tightly woven to consider many of them functional
> without the same lockstep version of other services together. A game to
> play is ask yourself what would happen if a service was isolated on its
> own island, how functional would its API be, if at all. Is this something
> that we want? No. But there doesn't seem to be a place where we can go
> to actually design, discuss, debate, and ratify changes that would help
> us get to the point of gathering the necessary will and capability to
> enact these efforts.
> 
> Maybe nova-compute should be isolated from nova, with an API that
> nova, cinder and neutron talk to. Maybe we should make the scheduler
> cross-project aware and capable of scheduling more than just nova
> instances. Maybe we should have experimental groups that can look at how
> some of this functionality could perhaps be delegated to non-openstack
> projects. We hear that Mesos, for example to help with the scheduling
> aspects, but how do we discuss these outside hijacking threads on the
> mailing list? These are things that we all discuss in the hallways
> and bars and parties at the summit, but because they cross projects at
> the design level, and are inherently a lot of social and technical and
> exploratory work, Many of us fear we never get to a place of turning
> our dreams into reality.
> 
> So, with that, I'd like to propose the creation of an Architecture Working
> Group. This group's charge would not be design by committee, but a place
> for architects to share their designs and gain support across projects
> to move forward with and ratify architectural decisions. That includes
> coordinating exploratory work that may turn into being the base of further
> architectural decisions for OpenStack. I

Re: [openstack-dev] [kolla] Usage of Reno - all devs please read

2016-06-28 Thread Hui Kang

Hi, Jeffrey and Nate,
Thanks for the links. I will update my PS.

- Hui

On Tue, Jun 28, 2016 at 12:15 PM, Nate Johnston  wrote:
> On Tue, Jun 28, 2016 at 11:47:58PM +0800, Jeffrey Zhang wrote:
>> On Tue, Jun 28, 2016 at 9:23 PM, Hui Kang  wrote:
>>
>> > Do you mind giving some example of such reno release note? Thanks.
>>
>> like this https://review.openstack.org/#/c/235398/ .
>
> The instructions are also very good:
>
> http://docs.openstack.org/developer/reno/usage.html
>
> --N.
>
> __
> 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/openstack-dev

__
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/openstack-dev

Re: [openstack-dev] [Fuel] Failed to build the bootstrap image

2016-06-28 Thread Maksim Malchuk

1. Show the logfile to see the bootstrap process is finished without any
errors.
2. It depends on the Fuel version, http://10.20.0.2/cobbler/boot in some
cases can't be seen through the web browser.
3. You shouldn't do anything only reboot the slave node. If fuel-bootstrap
executed correctly - your slave node should boot.
4. Also, there can be a problem in the VirtualBox settings, please don't
touch network/interfaces and use only fuel-virtualbox scripts to configure
them.


On Tue, Jun 28, 2016 at 6:28 PM, Alioune  wrote:

> Maksim,
> The bootstrap process woks fine without error but the slave can boot from
> network.
> I think that the issue is due TFTP process, it tries to reach
> http://10.20.0.2/cobbler/boot, I used my web browser but there is not
> directory named boot in cobbler folder.
> Should the bootstrap create this directory ?
>
> On 28 June 2016 at 15:59, Maksim Malchuk  wrote:
>
>> You can start build command with debug options enabled for example and
>> copy/paste output:
>>>
>>> fuel-bootstrap --verbose --debug build --activate
>>>
>>
>> Very bad idea to remove logfile, it's better to empty it not remove.
>>
>>  If you don't have the logfile, so recreate it with command:
>>
>>> touch /var/log/fuel-bootstrap-image-build.log
>>>
>>
>>
>> On Tue, Jun 28, 2016 at 4:09 PM, Alioune  wrote:
>>
>>> I've removed /var/log/fuel-bootstrap-image-build.log, created new
>>> bootstrap ubuntu again after setting proxy parameters and reboot.
>>> After the there is no /var/log/fuel-bootstrap-image-build.log create
>>> from the new bootstrap but slave doesn't boot correctly.
>>> Is there another way to detect slave nodes without creating image ?
>>> Regards,
>>> [image: Inline images 2]
>>>
>>> On 28 June 2016 at 13:34, Maksim Malchuk  wrote:
>>>
 You have an issue with connectivity from the Fuel master node to
 http://archive.ubuntu.com
 from the log:

> Command: debootstrap --include=ca-certificates,apt-transport-https 
> --verbose --no-check-gpg --arch=amd64 trusty 
> /tmp/tmp1K2haC.fuel-agent-image http://archive.ubuntu.com/ubuntu
> Exit code: 1
> Stdout: 'I: Retrieving Release \nE: Failed getting release file 
> http://archive.ubuntu.com/ubuntu/dists/trusty/Release\n'
> Stderr: ''
> Failed to execute command: Unexpected error while running command.
>
> please check your network connectivity, maybe firewall or nat settings.


 On Tue, Jun 28, 2016 at 2:28 PM, Alioune  wrote:

> Hi all,
> I tried to create ubuntu bootstrap using [0] but the slave can still
> not booting. You can find the bootstrap log following [1].
>
> Noticed that I've deleted the depot [2] from fuelmenu because it
> generated an error  "URL for repository mos is not accessible".
>
> Regards,
>
> [0] fuel-bootstrap build --ubuntu-release trusty  --activate
> [1]
> https://drive.google.com/folderview?id=0B-bfET74f0WZWE9Uc1lVOXJLcWM=sharing
> [2]  http://127.0.0.1:8080/ubuntu/x86_64/ mos8.0 main restricted
>
> On 27 June 2016 at 17:48, Maksim Malchuk 
> wrote:
>
>> Maybe the problem because you create the CentOS bootstrap which is
>> deprecated now.
>> If You really need the CentOS bootstrap, need to look into the
>> mentioned log file for this issue.
>>
>>
>> On Mon, Jun 27, 2016 at 6:33 PM, Alioune  wrote:
>>
>>> Thanks for your response,
>>>
>>> I've created and activated a new centOS bootstrap as suggested Sergi.
>>> Now the fuel-slave tries to boot from network but it fails at step
>>> TFTP http://10.20.0.2/cobbler/boot (unable to locate configuration
>>> file ).
>>> The bootstrap zip was generated in
>>> /tmp/a721103c-8693-4c58-985d-3f8223bdbc88.tar.gz, it seems that the 
>>> slave
>>> can not retreive the config files of the bootstrap.
>>> Are there additional config to do on the master side ?
>>> Regards
>>>
>>>  fuel-bootstrap list
>>>
>>> +--+--++
>>> | uuid | label
>>>  | status |
>>>
>>> +--+--++
>>> | a721103c-8693-4c58-985d-3f8223bdbc88 |
>>> a721103c-8693-4c58-985d-3f8223bdbc88 | active |
>>> | centos   | deprecated
>>>   ||
>>>
>>> +--+--++
>>>
>>> On 27 June 2016 at 16:58, Sergii Golovatiuk <
>>> sgolovat...@mirantis.com> wrote:
>>>
 Hi,

 I would suggest to build image from CLI using [0]. That will give
 more details to you.

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

2016-06-28 Thread Elisha, Moshe (Nokia - IL)

Hi,

Thank you for the kind words, Alexey.

I was able to reproduce your bug and I have also found the issue.

The problem is that we did not create the parser with the engine_options used 
in the yaql library by default when using the CLI.
Specifically, the "yaql.limitIterators" was missing… I am not sure that this 
settings should have this affect but maybe the Yaql guys can comment on that.

If we will change yaqluator to use this setting it will mean that yaqluator 
will not be consistent with Mistral because Mistral is using YAQL without this 
engine option (If I use your example in a workflow, Mistral returns exactly 
like the yaqluator returns)

Workflow:

---
version: '2.0'

test_yaql:
  tasks:
test_yaql:
  action: std.noop
  publish:
output_expr: <% [1,2].join([3], true, [$1, $2]) %>

Workflow result:

[root@s53-19 ~(keystone_admin)]# mistral task-get-published 
01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7
{
"output_expr": [
[
1,
3
]
]
}

As Matthews pointed out, the yaqluator is indeed OpenSource and contributions 
are welcomed.

[1] 
https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2

From: Dougal Matthews >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, 27 June 2016 at 16:44
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

On 27 June 2016 at 14:30, Alexey Khivin 
> wrote:
Hello, Moshe

Tomorrow I discovered yaqluator.com for myself! Thanks 
for the useful tool!

But suddenly I was said that the expression
[1,2].join([3], true, [$1, $2])
evaluated to [[1,3]] on the yaqluator

A the same time this expression evaluated right when I using raw yaql 
interpreter.

Could we fix this issue?

By the way, don't you want to make yaqluator opensource? If you would transfer 
yaqluator to Openstack Foundation, then  community will be able to fix such 
kind of bugs

It looks like it is open source, there is a link in the footer: 
https://github.com/ALU-CloudBand/yaqluator

Thank you!
Best regards, Alexey Khivin

__
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/openstack-dev

__
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/openstack-dev

Re: [openstack-dev] [OpenStack-docs] [telemetry] Ceilometer and Aodh install guide(s)

2016-06-28 Thread Caballero Abraham, Rodrigo

snip
> 
> Do you have a good proposal for structuring things?
[] 
I am assuming that you have distro specific instructions mixed with 
non-specific ones.
I can only suggest what has worked for me in the past. I created a common file 
describing the process devoid of any instructions, distro specific or otherwise.
Then I created distro specific procedures containing all the needed 
instructions with the appropriate level of detail.
The steps on the common file serve as the headings for all distro specific 
procedures. That makes the common file an excellent introduction to all 
procedures while keeping the entire instructions in a single place.

This system is not perfect however. There is some content repetition on the 
instructions side of things. 
This could be avoided if we used the .. only:: directive on the instructions 
side. You would then have a high level overview of the procedure, common to all 
distros, and a single file containing all instructions for all distros 
differentiated by the only directive.

I guess what I am saying is that there is no magic bullet here. At the end of 
the day, the content determines what modularity model you can use, IMO.
Regards,
Rodrigo
> 
> Thanks,
> /Ildikó
snip
__
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/openstack-dev

Re: [openstack-dev] [telemetry] Ceilometer and Aodh install guide(s)

Hi,

@Julien: +1 to the one 'doc' folder.

I think it's not yet decided whether it should be modular, using '.. only::' or 
we can/will have both.

I use the modular approach as well right now, I have many files containing the 
common things and the distro specific steps. For Ceilometer it resulted in way 
more files and folders than it should be in my opinion. And I think it will 
discourage people from contributing to it. The more files you have the harder 
to see how the guide will look like after the build, which can make it slower 
to identify and then modify the files.

Do you have a good proposal for structuring things?

Thanks,
/Ildikó

> -Original Message-
> From: Spyros Trigazis [mailto:strig...@gmail.com]
> Sent: June 28, 2016 17:18
> To: OpenStack Development Mailing List (not for usage questions); Ildikó 
> Váncsa; openstack-d...@lists.openstack.org
> Subject: Re: [openstack-dev] [telemetry] Ceilometer and Aodh install guide(s)
> 
> +1 on the modular approach by Rodrigo Caballero
> 
> I'm writing magnum's guide and I'm working on the debian guide. Debian's 
> guide will have a couple of differences and I plan to move
> them in other files or/and break the existing common config files.
> 
> IMO, one of the goals of the project specific guides was to let teams decide 
> what works for them. If the output guide is similar to
> others, I think you can choose what suits you best.
> 
> Cheers,
> Spyros
> 
> 
> On 28 June 2016 at 16:44, Julien Danjou  wrote:
> 
> 
>   On Tue, Jun 28 2016, Ildikó Váncsa wrote:
> 
>   > I have a third less urgent question. The install-guide has it's own 
> folder at
>   > the same level where these two projects have their 'doc' folder. I 
> would assume
>   > other projects have the same or similar folder for the developer 
> docs. Would
>   > that be reasonable/possible to have one main 'doc' folder for all the 
> docs?
> 
>   This is our long-term objective for Telemetry projects.
> 
>   Gnocchi already have only one doc/ folder with all the documentation,
>   From installation to usage.
> 
>   I don't think our projects are not big enough and have enough resources
>   to start maintaining different documentations with different scopes,
>   etc.
> 
>   --
>   Julien Danjou
>   ;; Free Software hacker
>   ;; https://julien.danjou.info
> 
>   
> __
>   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/openstack-dev
> 
> 
> 

__
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/openstack-dev

Re: [openstack-dev] [ironic] why do we need setting network driver per node?

2016-06-28 Thread Mathieu Mitchell


Following discussion on IRC, here are my thoughts:

The proposed network_interface allows choosing a "driver" for the 
network part of a node. The values could be something like "nobody", 
"neutron-flat networking" and "neutron-tenant separation".


I think this choice should be left per-node. My reasoning is that you 
could have a bunch of nodes for which you have complete Neutron support, 
through for example an ML2 plugin. These nodes would be configured using 
one of the "neutron-*" modes.


On the other hand, that same Ironic installation could also manage nodes 
for which the switches are unmanaged, or manually configured. In such 
case, you would probably want to use the "nobody" mode.


An important point is to expose this "capability" to Nova as you might 
want to offer nodes with neutron integration differently from "any 
node". I am unsure if the capability should be the value of the 
network_interface or a boolean "neutron integration?". Thoughts?


Mathieu

On 2016-06-28 11:32 AM, Dmitry Tantsur wrote:

Hi folks!

I was reviewing https://review.openstack.org/317391 and realized I don't
quite understand why we want to have node.network_interface. What's the
real life use case for it?

Do we expect some nodes to use Neutron, some - not?

Do we expect some nodes to benefit from network separation, some - not?
There may be a use case here, but then we have to expose this field to
Nova for scheduling, so that users can request a "secure" node or a
"less secure" one. If we don't do that, Nova will pick at random, which
makes the use case unclear again.
If we do that, the whole work goes substantially beyond what we were
trying to do initially: isolate tenants from the provisioning network
and from each other.

Flexibility it good, but the patches raise upgrade concerns, because
it's unclear how to provide a good default for the new field. And anyway
it makes the whole thing much more complex than it could be.

Any hints are welcome.

__
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/openstack-dev


__
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/openstack-dev

Re: [openstack-dev] [kolla] Usage of Reno - all devs please read

2016-06-28 Thread Nate Johnston

On Tue, Jun 28, 2016 at 11:47:58PM +0800, Jeffrey Zhang wrote:
> On Tue, Jun 28, 2016 at 9:23 PM, Hui Kang  wrote:
> 
> > Do you mind giving some example of such reno release note? Thanks.
> 
> like this https://review.openstack.org/#/c/235398/ .

The instructions are also very good:

http://docs.openstack.org/developer/reno/usage.html

--N.

__
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/openstack-dev

Re: [openstack-dev] [kolla] version of python2-oslo-config

2016-06-28 Thread Steven Dake (stdake)

The mitaka branch of Kolla requires 3.7 or later.

Git 
checkout stable/mitaka

Master may require 3.10, but that happens via the global requirements update 
process, of which RDO will surely address in the future.

Regards
-steve

From: "hu.zhiji...@zte.com.cn" 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, June 28, 2016 at 4:30 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [kolla] version of python2-oslo-config

Hi Kolla team,

Base upon requirement.txt, Kolla needs oslo-config version 3.10. But CentOS 
Mitaka uses 3.9 ,which is python2-oslo-config-3.9.0-1.el7.noarch.rpm.

I want to know if Kolla can also work on oslo-config-3.9.0. If it can, then 
will be a benefit because pip is conflict with rpm on python2-oslo-config 
package. For example, the rpm version has the ability to find config file in 
/usr/share/keystone/keystone-dist.conf but the pip version not.


Thanks
Zhijiang,



ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.



__
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/openstack-dev

Re: [openstack-dev] [kolla] Usage of Reno - all devs please read

2016-06-28 Thread Jeffrey Zhang

On Tue, Jun 28, 2016 at 9:23 PM, Hui Kang  wrote:

> Do you mind giving some example of such reno release note? Thanks.


like this https://review.openstack.org/#/c/235398/ .



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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/openstack-dev

Re: [openstack-dev] [murano] Load murano Apps

2016-06-28 Thread Serg Melikyan

Hi Alione,

you need to archive content of the "package" folder, e.g. MySQL [0].
Make sure that manifest.yaml is on the root level.


References:
[0] https://github.com/openstack/murano-apps/tree/master/MySQL/package

On Tue, Jun 28, 2016 at 8:36 AM, Alioune  wrote:
> Hi all,
> I've downloaded murano apps from [1] and I would like to upload them as
> package.
>
> I would like to know which folders into murano-apps to zip and load from
> "Package Definition" ?
>
> How to add these apps with murano package-import ?
>
> Regards,
>
> [1] https://github.com/openstack/murano-apps
>
> __
> 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/openstack-dev
>



-- 
Serg Melikyan, Development Manager at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

__
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/openstack-dev

[openstack-dev] [Nova][Neutron][Live-Migration] Cross l2 agent migration and solving Nova-Neutron live migration bugs

2016-06-28 Thread Andreas Scheuring

Hi,

I'm currently working on solving Nova-Neutron issues during Live
Migration. This mail is intended to raise awareness cross project and
get things kicked off.

The issues
==

#1 When portbinding fails, instance is migrated but stuck in error state
#2 Macvtap agent live Migration when source and target use different
physical_interface_mapping [3]. Either the migration fails (good case)
or it would place the instance on a wrong network (worst case)
#3 (more a feature):  Migration cross l2 agent not possible (e.g.
migrate from lb host to ovs host, or from ovs-hybrid to new ovsfirewall
host)


The proposal

All those problems could be solved with the same approach . The proposal
is, to bind a port to the source AND to the target port during
migration.

* Neutron would need to allow multiple bindings for a compute port and
externalize that via API. 
  - Neutron Spec [1]
  - Bug [4]  is a prereq to the spec.

* Nova would need to use those new APIs to check in pre_live_migration,
if the binding for target host is valid and to modify the instance
definition (e.g. domain.xml) during migration.
  - Nova Spec [2]

This would solve the issues in the following way:
#1 would abort the migration before it started, so instance is still
usable
#2 Migration is possible with all configurations 
#3 would allow such a migration


Coordination

Some coordination between Nova & Neutron is required. Along todays Nova
Live Migration Meeting [5] this will happen on the Nova midcycle. I put
an item on the agenda [6].


Would be great that anybody that is interested in this bugfix/feature
could comment on the specs [1] or [2] to get as much feedback as
possible before the nova midcycle in July!

Thank you!



[1] Neutron spec: https://review.openstack.org/#/c/309416
[2] Nova spec: https://review.openstack.org/301090
[3] macvtap bug: https://bugs.launchpad.net/neutron/+bug/1550400
[4] https://bugs.launchpad.net/neutron/+bug/1367391
[5]
http://eavesdrop.openstack.org/meetings/nova_live_migration/2016/nova_live_migration.2016-06-28-14.00.log.html

[6] https://etherpad.openstack.org/p/nova-newton-midcycle





andreas_s


__
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/openstack-dev

Re: [openstack-dev] [Cinder] Nominating Scott D'Angelo to Cindercore

2016-06-28 Thread Kendall J Nelson


Congratulations Scott :)

All the Best,
  
   Kendall J. Nelson  
   Software Engineer &
   OpenStack Contributor  
  


   
   
   
   E-mail: kjnel...@us.ibm.com IBM 
   Cell Phone: (952) 215- 4025 
   IRC Nickname: diablo_rojo 3605 Hwy 52 N 
 Rochester, MN 
55901-1407 
 United States 
   






From:   Eric Harney 
To: openstack-dev@lists.openstack.org
Date:   06/28/2016 10:07 AM
Subject:Re: [openstack-dev] [Cinder] Nominating Scott D'Angelo to
Cinder  core



On 06/27/2016 01:27 PM, Sean McGinnis wrote:
> I would like to nominate Scott D'Angelo to core. Scott has been very
> involved in the project for a long time now and is always ready to help
> folks out on IRC. His contributions [1] have been very valuable and he
> is a thorough reviewer [2].
>
> Please let me know if there are any objects to this within the next
> week. If there are none I will switch Scott over by next week, unless
> all cores approve prior to then.
>
> Thanks!
>
> Sean McGinnis (smcginnis)
>
> [1] https://review.openstack.org/#/q/owner:%22Scott+DAngelo
+%253Cscott.dangelo%2540hpe.com%253E%22+status:merged
> [2] http://cinderstats-dellstorage.rhcloud.com/cinder-reviewers-90.txt
>


Definitely a +2.  Welcome, Scott!

__
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/openstack-dev



__
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/openstack-dev

[openstack-dev] [murano] Load murano Apps

Hi all,
I've downloaded murano apps from [1] and I would like to upload them as
package.

I would like to know which folders into murano-apps to zip and load from
"Package Definition" ?

How to add these apps with murano package-import ?

Regards,

[1] https://github.com/openstack/murano-apps
__
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/openstack-dev

[openstack-dev] [ironic] why do we need setting network driver per node?

2016-06-28 Thread Dmitry Tantsur


Hi folks!

I was reviewing https://review.openstack.org/317391 and realized I don't 
quite understand why we want to have node.network_interface. What's the 
real life use case for it?


Do we expect some nodes to use Neutron, some - not?

Do we expect some nodes to benefit from network separation, some - not? 
There may be a use case here, but then we have to expose this field to 
Nova for scheduling, so that users can request a "secure" node or a 
"less secure" one. If we don't do that, Nova will pick at random, which 
makes the use case unclear again.
If we do that, the whole work goes substantially beyond what we were 
trying to do initially: isolate tenants from the provisioning network 
and from each other.


Flexibility it good, but the patches raise upgrade concerns, because 
it's unclear how to provide a good default for the new field. And anyway 
it makes the whole thing much more complex than it could be.


Any hints are welcome.

__
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/openstack-dev

Re: [openstack-dev] [Fuel] Failed to build the bootstrap image

Maksim,
The bootstrap process woks fine without error but the slave can boot from
network.
I think that the issue is due TFTP process, it tries to reach
http://10.20.0.2/cobbler/boot, I used my web browser but there is not
directory named boot in cobbler folder.
Should the bootstrap create this directory ?

On 28 June 2016 at 15:59, Maksim Malchuk  wrote:

> You can start build command with debug options enabled for example and
> copy/paste output:
>>
>> fuel-bootstrap --verbose --debug build --activate
>>
>
> Very bad idea to remove logfile, it's better to empty it not remove.
>
>  If you don't have the logfile, so recreate it with command:
>
>> touch /var/log/fuel-bootstrap-image-build.log
>>
>
>
> On Tue, Jun 28, 2016 at 4:09 PM, Alioune  wrote:
>
>> I've removed /var/log/fuel-bootstrap-image-build.log, created new
>> bootstrap ubuntu again after setting proxy parameters and reboot.
>> After the there is no /var/log/fuel-bootstrap-image-build.log create from
>> the new bootstrap but slave doesn't boot correctly.
>> Is there another way to detect slave nodes without creating image ?
>> Regards,
>> [image: Inline images 2]
>>
>> On 28 June 2016 at 13:34, Maksim Malchuk  wrote:
>>
>>> You have an issue with connectivity from the Fuel master node to
>>> http://archive.ubuntu.com
>>> from the log:
>>>
 Command: debootstrap --include=ca-certificates,apt-transport-https 
 --verbose --no-check-gpg --arch=amd64 trusty 
 /tmp/tmp1K2haC.fuel-agent-image http://archive.ubuntu.com/ubuntu
 Exit code: 1
 Stdout: 'I: Retrieving Release \nE: Failed getting release file 
 http://archive.ubuntu.com/ubuntu/dists/trusty/Release\n'
 Stderr: ''
 Failed to execute command: Unexpected error while running command.

 please check your network connectivity, maybe firewall or nat settings.
>>>
>>>
>>> On Tue, Jun 28, 2016 at 2:28 PM, Alioune  wrote:
>>>
 Hi all,
 I tried to create ubuntu bootstrap using [0] but the slave can still
 not booting. You can find the bootstrap log following [1].

 Noticed that I've deleted the depot [2] from fuelmenu because it
 generated an error  "URL for repository mos is not accessible".

 Regards,

 [0] fuel-bootstrap build --ubuntu-release trusty  --activate
 [1]
 https://drive.google.com/folderview?id=0B-bfET74f0WZWE9Uc1lVOXJLcWM=sharing
 [2]  http://127.0.0.1:8080/ubuntu/x86_64/ mos8.0 main restricted

 On 27 June 2016 at 17:48, Maksim Malchuk  wrote:

> Maybe the problem because you create the CentOS bootstrap which is
> deprecated now.
> If You really need the CentOS bootstrap, need to look into the
> mentioned log file for this issue.
>
>
> On Mon, Jun 27, 2016 at 6:33 PM, Alioune  wrote:
>
>> Thanks for your response,
>>
>> I've created and activated a new centOS bootstrap as suggested Sergi.
>> Now the fuel-slave tries to boot from network but it fails at step
>> TFTP http://10.20.0.2/cobbler/boot (unable to locate configuration
>> file ).
>> The bootstrap zip was generated in
>> /tmp/a721103c-8693-4c58-985d-3f8223bdbc88.tar.gz, it seems that the slave
>> can not retreive the config files of the bootstrap.
>> Are there additional config to do on the master side ?
>> Regards
>>
>>  fuel-bootstrap list
>>
>> +--+--++
>> | uuid | label
>>  | status |
>>
>> +--+--++
>> | a721103c-8693-4c58-985d-3f8223bdbc88 |
>> a721103c-8693-4c58-985d-3f8223bdbc88 | active |
>> | centos   | deprecated
>> ||
>>
>> +--+--++
>>
>> On 27 June 2016 at 16:58, Sergii Golovatiuk > > wrote:
>>
>>> Hi,
>>>
>>> I would suggest to build image from CLI using [0]. That will give
>>> more details to you.
>>>
>>> [0]
>>> http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/bootstrap/bootstrap_builder.html
>>>
>>> --
>>> Best regards,
>>> Sergii Golovatiuk,
>>> Skype #golserge
>>> IRC #holser
>>>
>>> On Mon, Jun 27, 2016 at 3:20 PM, Maksim Malchuk <
>>> mmalc...@mirantis.com> wrote:
>>>
 Hi,

 The error about an internet connection is the only common case. You
 should check the actual error in the log file
 /var/log/fuel-bootstrap-image-build.log.
 You can also share this file with us via any public service
 (GoogleDrive, DropBox, etc) and we will check it for

Re: [openstack-dev] [mistal] Mistral logo ideas?

2016-06-28 Thread Elisha, Moshe (Nokia - IL)

Hi,

Attached another draft based on Michal's idea (it probably should be more 
colourful)

Maybe we can upload them to some online survey and vote…


From: Ryan Brady >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, 28 June 2016 at 17:08
To: Jason Rist >, "OpenStack 
Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [mistal] Mistral logo ideas?



On Tue, Jun 28, 2016 at 1:38 AM, Jason Rist 
> wrote:
On 06/27/2016 06:57 AM, Dougal Matthews wrote:
> On 27 June 2016 at 07:45, Renat Akhmerov 
> > wrote:
>
> >
> >> Ideally it would be nice to have something that matches the meaning of
> > the
> >> name. Maybe we can combine wind with one of the other ideas.
> >>
> >> I like the idea of the logo being a stylized wind turbine. Perhaps it
> > could be
> >> a turbine with a gust of wind. Then we can show that Mistral harnesses
> > the
> >> power of the wind :-)
> >
> > Yeah, I’m just wondering how it would look like :)
> >
> >
> Yeah, for this idea we probably need somebody with artistic skills far
> superior
> to anything I could manage. We are getting quite a few good ideas now
> anyway!
>
>
> Renat Akhmerov
> > @Nokia
> >
> >
>

Ever since I saw the blueprint for a mistral logo, I've been working on some 
ideas.  I've presented a few to Dougal and Ryan, but I'm sharing widely here.  
I also did the one Michal came up with in Illustrator as well.  Please give me 
some feedback!  Both of the ones I thought of are "wind" related.  I thought 
about doing the ship before as well, but perhaps a little too war related, and 
also obscure.

+1 to the mistral-tornado.png logo.  I think it would be easily distinguishable 
at any size or distance.


Thanks,
Jason

P.S. you may recognize my name from the DLRN logo [1] and the TripleO Logo [2].

[1] 
https://github.com/openstack-packages/DLRN/blob/master/doc/source/_images/DLRN.png
[2] 
https://github.com/dprince/tripleosphinx/blob/master/tripleosphinx/theme/tripleo/static/tripleo_owl.svg

--
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

__
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/openstack-dev




--
Ryan Brady
Cloud Engineering
rbr...@redhat.com
919.890.8925
__
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/openstack-dev

Re: [openstack-dev] [telemetry] Ceilometer and Aodh install guide(s)

2016-06-28 Thread Spyros Trigazis

+1 on the modular approach by Rodrigo Caballero

I'm writing magnum's guide and I'm working on the debian guide. Debian's
guide will have a couple of differences and I plan to move them in other
files or/and break the existing common config files.

IMO, one of the goals of the project specific guides was to let teams decide
what works for them. If the output guide is similar to others, I think you
can
choose what suits you best.

Cheers,
Spyros


On 28 June 2016 at 16:44, Julien Danjou  wrote:

> On Tue, Jun 28 2016, Ildikó Váncsa wrote:
>
> > I have a third less urgent question. The install-guide has it's own
> folder at
> > the same level where these two projects have their 'doc' folder. I would
> assume
> > other projects have the same or similar folder for the developer docs.
> Would
> > that be reasonable/possible to have one main 'doc' folder for all the
> docs?
>
> This is our long-term objective for Telemetry projects.
>
> Gnocchi already have only one doc/ folder with all the documentation,
> From installation to usage.
>
> I don't think our projects are not big enough and have enough resources
> to start maintaining different documentations with different scopes,
> etc.
>
> --
> Julien Danjou
> ;; Free Software hacker
> ;; https://julien.danjou.info
>
> __
> 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/openstack-dev
>
>
__
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/openstack-dev

Re: [openstack-dev] [Fuel] Deprecate fuel-upgrade repository

2016-06-28 Thread Vladimir Kozhukalov

This patch [1] is a part of project retirement procedure [2]. Review is
welcome.

[1] https://review.openstack.org/#/c/335085/
[2] http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project

Vladimir Kozhukalov

On Tue, Jun 28, 2016 at 1:41 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> Please be informed that fuel-upgrade [1] repository is going to be
> deprecated. We used to develop Fuel admin node upgrade scenarios in this
> repo, but now all upgrade related stuff is in fuel-octane [2] repo. So,
> fuel-upgrade is to be removed from the list of official Fuel repos [3].
> Fuel-upgrade will stay available for a while perhaps for about a year or so
> in case some of Fuel users want to build upgrade tarball.
>
>
> [1] https://github.com/openstack/fuel-upgrade
> [2] https://github.com/openstack/fuel-octane
> [3] https://review.openstack.org/#/c/334903/
>
> 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/openstack-dev

Re: [openstack-dev] [puppet] weekly meeting #86

2016-06-28 Thread Emilien Macchi

Meeting cancelled again, no topic this week.
See you next week!

On Mon, Jun 27, 2016 at 8:39 AM, Emilien Macchi <emil...@redhat.com> wrote:
> Hi,
>
> If you have any topic for our meeting tomorrow, please add them on the 
> etherpad:
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160628
>
> See you tomorrow,
>
> On Tue, Jun 21, 2016 at 10:59 AM, Emilien Macchi <emil...@redhat.com> wrote:
>> Meeting cancelled, no topics this week.
>>
>> See you next week!
>>
>> On Mon, Jun 20, 2016 at 9:44 AM, Emilien Macchi <emil...@redhat.com> wrote:
>>> Hi Puppeteers!
>>>
>>> We'll have our weekly meeting tomorrow at 3pm UTC on
>>> #openstack-meeting-4.
>>>
>>> Here's a first agenda:
>>> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160621
>>>
>>> Feel free to add more topics, and any outstanding bug and patch.
>>>
>>> See you tomorrow!
>>> Thanks,
>>> --
>>> Emilien Macchi
>>
>>
>>
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

__
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/openstack-dev

Re: [openstack-dev] [Cinder] Nominating Scott D'Angelo to Cinder core

2016-06-28 Thread Eric Harney

On 06/27/2016 01:27 PM, Sean McGinnis wrote:
> I would like to nominate Scott D'Angelo to core. Scott has been very
> involved in the project for a long time now and is always ready to help
> folks out on IRC. His contributions [1] have been very valuable and he
> is a thorough reviewer [2].
> 
> Please let me know if there are any objects to this within the next
> week. If there are none I will switch Scott over by next week, unless
> all cores approve prior to then.
> 
> Thanks!
> 
> Sean McGinnis (smcginnis)
> 
> [1] 
> https://review.openstack.org/#/q/owner:%22Scott+DAngelo+%253Cscott.dangelo%2540hpe.com%253E%22+status:merged
> [2] http://cinderstats-dellstorage.rhcloud.com/cinder-reviewers-90.txt
> 


Definitely a +2.  Welcome, Scott!

__
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/openstack-dev

[openstack-dev] [Neutron][DVR] - No IRC Meeting this week

2016-06-28 Thread Brian Haley


Hi Folks,

We will not have a DVR sub-team meeting this week since neither Swami nor myself 
will be there to chair it.


We will resume our meetings next week on July 6th.

If you have any questions please ping us on IRC or send an email to the list.

https://wiki.openstack.org/wiki/Meetings/Neutron-DVR

Thanks,

-Brian

__
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/openstack-dev

Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume Not Removed on Instance Delete

2016-06-28 Thread D'Angelo, Scott

If a volume is attached to an instance, and the instance is deleted, the volume 
will be DETACHED, but the volume will still exist, it will NOT be DELETED.

It is up to the volume owner to delete the volume if they wish.

From: Will Zhou 
Sent: Tuesday, June 28, 2016 8:43:51 AM
To: aa...@tesora.com; OpenStack Development Mailing List (not for usage 
questions)
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete

Hi all,

I'd like to make sure should the volume, which is attached to an instance, be 
detached or be deleted after the instance is deleted? Thanks.

On Tue, Jun 28, 2016 at 10:16 PM Ali Asgar Adil (Code Review) 
> wrote:
Ali Asgar Adil has posted comments on this change.

Change subject: Ophaned Volume Not Removed on Instance Delete
..

Patch Set 1:

In what situation would a nova instance be in "available" state. Also, we are 
are deleting the instance so we would want the volume to be deleted as well not 
detached.

--
To view, visit https://review.openstack.org/334722
To unsubscribe, visit https://review.openstack.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ie921a8ff2851e2d9d76a3c3836945c750f090c4e
Gerrit-PatchSet: 1
Gerrit-Project: openstack/trove
Gerrit-Branch: master
Gerrit-Owner: Ali Asgar Adil >
Gerrit-Reviewer: Ali Asgar Adil >
Gerrit-Reviewer: Jenkins
Gerrit-Reviewer: zzxwill >
Gerrit-HasComments: No
--

-
?
???
Mobile: 13701280947
?WeChat: 472174291

__
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/openstack-dev

Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume Not Removed on Instance Delete

2016-06-28 Thread Will Zhou

Hi Scott, many thanks for your figuration.  Thanks and +1 for your
nomination to nova core:)

Hi aadil, we should DETACH the volume, instead of DELETE. Please help
enhance your code which is really a helpful fix to the bug. Thanks.

On Tue, Jun 28, 2016 at 10:51 PM D'Angelo, Scott 
wrote:

> If a volume is attached to an instance, and the instance is deleted, the
> volume will be DETACHED, but the volume will still exist, it will NOT be
> DELETED.
>
> It is up to the volume owner to delete the volume if they wish.
>
> 
> From: Will Zhou 
> Sent: Tuesday, June 28, 2016 8:43:51 AM
> To: aa...@tesora.com; OpenStack Development Mailing List (not for usage
> questions)
> Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned
> Volume Not Removed on Instance Delete
>
> Hi all,
>
> I'd like to make sure should the volume, which is attached to an instance,
> be detached or be deleted after the instance is deleted? Thanks.
>
>
> On Tue, Jun 28, 2016 at 10:16 PM Ali Asgar Adil (Code Review) <
> rev...@openstack.org> wrote:
> Ali Asgar Adil has posted comments on this change.
>
> Change subject: Ophaned Volume Not Removed on Instance Delete
> ..
>
>
> Patch Set 1:
>
> In what situation would a nova instance be in "available" state. Also, we
> are are deleting the instance so we would want the volume to be deleted as
> well not detached.
>
> --
> To view, visit https://review.openstack.org/334722
> To unsubscribe, visit https://review.openstack.org/settings
>
> Gerrit-MessageType: comment
> Gerrit-Change-Id: Ie921a8ff2851e2d9d76a3c3836945c750f090c4e
> Gerrit-PatchSet: 1
> Gerrit-Project: openstack/trove
> Gerrit-Branch: master
> Gerrit-Owner: Ali Asgar Adil >
> Gerrit-Reviewer: Ali Asgar Adil  >>
> Gerrit-Reviewer: Jenkins
> Gerrit-Reviewer: zzxwill >
> Gerrit-HasComments: No
> --
>
> -
> ?
> ???
> Mobile: 13701280947
> ?WeChat: 472174291
>
> __
> 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/openstack-dev
>
-- 

-

周正喜
Mobile: 13701280947
WeChat: 472174291
__
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/openstack-dev

Re: [openstack-dev] [cinder] [keystone] cinder quota behavior differences after Keystone mitaka upgrade

2016-06-28 Thread Matt Fischer

Thanks Henry,

>From a Keystone POV I think it makes sense, but it's causing some
operational headaches, so I'm curious what the cinder team thinks about
this. Not being able to see or set someone's quota as an admin is
frustrating for dealing with support requests.


On Tue, Jun 28, 2016 at 12:38 AM, Henry Nash  wrote:

> Hi Matt,
>
> So the keystone changes were intentional. From Mitaka onwards, a domain is
> represented as a project which is “acting as a domain” (it has an attribute
> “is_domain” set to true). The situation you describe, where what were top
> level projects now have the project acting as the default domain as their
> parent, is what I would expect to happen after the update.
>
> During Mitaka development, we  worked with the cinder folks - who were to
> re-designing their quota code anyway - and this was modified to take
> account of the project structure. I’m not sure if the quota semantics you
> see are what was intended (I’ll let the cinder team comment). Code can, if
> desired, distinguish the case of top projects that are at the top level, vs
> projects somewhere way down the hierarchy, by looking at the parent and
> seeing if it is a project acting as a domain.
>
> Henry
> keystone core
>
> On 27 Jun 2016, at 17:13, Matt Fischer  wrote:
>
> We upgraded our dev environment last week to Keystone stable/mitaka. Since
> then we're unable to show or set quotas on projects of which the admin is
> not a member. Looking at the cinder code, it seems that cinder is pulling a
> project list and attempting to determine a hierarchy.  On Liberty Keystone,
> projects seem to lack parents:
>
>  id=9e839870dd0d4a2f96f9d71b7e7c5a4e, is_domain=False, links={u'self': u'
> https://liberty-endpoint:5000/v3/projects/9e839870dd0d4a2f96f9d71b7e7c5a4e'},
> name=admin, parent_id=None, subtree=None>
>
> In Mitaka, it seems that projects are children of the default domain:
>
>  id=4764ba822ecb43e582794b875751924c, is_domain=False, links={u'self': u'
> http://mitaka-endpoint:5000/v3/projects/4764ba822ecb43e582794b875751924c'},
> name=admin, parent_id=default, subtree=None>
>
> In Liberty since all projects were parentless, the authorize_* code blocks
> were skipped since both conditionals were false:
>
>
> https://github.com/openstack/cinder/blob/stable/liberty/cinder/api/contrib/quotas.py#L174-L191
>
> But now in Mitaka, the code is run, and it fails out since the projects
> are "brothers", both with the parent of the default domain, but not
> hierarchically related.
>
> Previously it was a useful ability for us to be able to (as admins) set
> and view  quotas for cinder projects. Now we need to scope into the user's
> project to even be able to view their quotas, much less change them. This
> seems broken, but I'm not sure where the issue is or why the keystone
> behavior changed. Is this the expected behavior?
>
> __
> 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/openstack-dev
>
>
>
> __
> 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/openstack-dev
>
>
__
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/openstack-dev

Re: [openstack-dev] [Cinder] Nominating Scott D'Angelo to Cinder core

2016-06-28 Thread Ivan Kolodyazhny

+2. Welcome to the team!

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Tue, Jun 28, 2016 at 1:48 PM, Erlon Cruz  wrote:

> +1
> Not a core but surely is well deserved. Congrats Scott!!
>
> On Tue, Jun 28, 2016 at 5:06 AM, Gorka Eguileor 
> wrote:
>
>>
>> +2
>>
>> Congrats Scott!!
>>
>>
>> On 27/06, Sean McGinnis wrote:
>> > I would like to nominate Scott D'Angelo to core. Scott has been very
>> > involved in the project for a long time now and is always ready to help
>> > folks out on IRC. His contributions [1] have been very valuable and he
>> > is a thorough reviewer [2].
>> >
>> > Please let me know if there are any objects to this within the next
>> > week. If there are none I will switch Scott over by next week, unless
>> > all cores approve prior to then.
>> >
>> > Thanks!
>> >
>> > Sean McGinnis (smcginnis)
>> >
>> > [1]
>> https://review.openstack.org/#/q/owner:%22Scott+DAngelo+%253Cscott.dangelo%2540hpe.com%253E%22+status:merged
>> > [2] http://cinderstats-dellstorage.rhcloud.com/cinder-reviewers-90.txt
>> >
>> >
>> __
>> > 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/openstack-dev
>>
>> __
>> 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/openstack-dev
>>
>
>
> __
> 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/openstack-dev
>
>
__
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/openstack-dev

Re: [openstack-dev] [telemetry] Ceilometer and Aodh install guide(s)

2016-06-28 Thread Julien Danjou

On Tue, Jun 28 2016, Ildikó Váncsa wrote:

> I have a third less urgent question. The install-guide has it's own folder at
> the same level where these two projects have their 'doc' folder. I would 
> assume
> other projects have the same or similar folder for the developer docs. Would
> that be reasonable/possible to have one main 'doc' folder for all the docs?

This is our long-term objective for Telemetry projects.

Gnocchi already have only one doc/ folder with all the documentation,
From installation to usage.

I don't think our projects are not big enough and have enough resources
to start maintaining different documentations with different scopes,
etc.

-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info

signature.asc
Description: PGP signature
__
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/openstack-dev

Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume Not Removed on Instance Delete

2016-06-28 Thread Will Zhou

Hi all,

I'd like to make sure should the volume, which is attached to an instance,
be *detached* or be *deleted* after the instance is deleted? Thanks.


On Tue, Jun 28, 2016 at 10:16 PM Ali Asgar Adil (Code Review) <
rev...@openstack.org> wrote:

> Ali Asgar Adil has posted comments on this change.
>
> Change subject: Ophaned Volume Not Removed on Instance Delete
> ..
>
>
> Patch Set 1:
>
> In what situation would a nova instance be in "available" state. Also, we
> are are deleting the instance so we would want the volume to be deleted as
> well not detached.
>
> --
> To view, visit https://review.openstack.org/334722
> To unsubscribe, visit https://review.openstack.org/settings
>
> Gerrit-MessageType: comment
> Gerrit-Change-Id: Ie921a8ff2851e2d9d76a3c3836945c750f090c4e
> Gerrit-PatchSet: 1
> Gerrit-Project: openstack/trove
> Gerrit-Branch: master
> Gerrit-Owner: Ali Asgar Adil 
> Gerrit-Reviewer: Ali Asgar Adil 
> Gerrit-Reviewer: Jenkins
> Gerrit-Reviewer: zzxwill 
> Gerrit-HasComments: No
>
-- 

-

周正喜
Mobile: 13701280947
WeChat: 472174291
__
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/openstack-dev

[openstack-dev] [Smaug]- IRC Meeting today (28/06) - 1500 UTC SM,

2016-06-28 Thread Saggi Mizrahi

Hi All,

We will hold our weekly IRC meeting today (Tuesday, 28/06) at 1500
UTC in #openstack-meeting

Please review the proposed meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/smaug

Please feel free to add to the agenda any subject you would like to
discuss.

Thanks,
Saggi
-
This email and any files transmitted and/or attachments with it are 
confidential and proprietary information of
Toga Networks Ltd., and intended solely for the use of the individual or entity 
to whom they are addressed.
If you have received this email in error please notify the system manager. This 
message contains confidential
information of Toga Networks Ltd., and is intended only for the individual 
named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail. Please 
notify the sender immediately
by e-mail if you have received this e-mail by mistake and delete this e-mail 
from your system. If you are not
the intended recipient you are notified that disclosing, copying, distributing 
or taking any action in reliance on
the contents of this information is strictly prohibited.



__
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/openstack-dev

Re: [openstack-dev] [mistal] Mistral logo ideas?

2016-06-28 Thread Ryan Brady

On Tue, Jun 28, 2016 at 1:38 AM, Jason Rist  wrote:

> On 06/27/2016 06:57 AM, Dougal Matthews wrote:
> > On 27 June 2016 at 07:45, Renat Akhmerov 
> wrote:
> >
> > >
> > >> Ideally it would be nice to have something that matches the meaning of
> > > the
> > >> name. Maybe we can combine wind with one of the other ideas.
> > >>
> > >> I like the idea of the logo being a stylized wind turbine. Perhaps it
> > > could be
> > >> a turbine with a gust of wind. Then we can show that Mistral harnesses
> > > the
> > >> power of the wind :-)
> > >
> > > Yeah, I’m just wondering how it would look like :)
> > >
> > >
> > Yeah, for this idea we probably need somebody with artistic skills far
> > superior
> > to anything I could manage. We are getting quite a few good ideas now
> > anyway!
> >
> >
> > Renat Akhmerov
> > > @Nokia
> > >
> > >
> >
>
> Ever since I saw the blueprint for a mistral logo, I've been working on
> some ideas.  I've presented a few to Dougal and Ryan, but I'm sharing
> widely here.  I also did the one Michal came up with in Illustrator as
> well.  Please give me some feedback!  Both of the ones I thought of are
> "wind" related.  I thought about doing the ship before as well, but perhaps
> a little too war related, and also obscure.
>

+1 to the mistral-tornado.png logo.  I think it would be easily
distinguishable at any size or distance.


> Thanks,
> Jason
>
> P.S. you may recognize my name from the DLRN logo [1] and the TripleO Logo
> [2].
>
> [1]
> https://github.com/openstack-packages/DLRN/blob/master/doc/source/_images/DLRN.png
> [2]
> https://github.com/dprince/tripleosphinx/blob/master/tripleosphinx/theme/tripleo/static/tripleo_owl.svg
>
> --
> Jason E. Rist
> Senior Software Engineer
> OpenStack User Interfaces
> Red Hat, Inc.
> openuc: +1.972.707.6408
> mobile: +1.720.256.3933
> Freenode: jrist
> github/twitter: knowncitizen
>
> __
> 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/openstack-dev
>
>


-- 
Ryan Brady
Cloud Engineering
rbr...@redhat.com
919.890.8925
__
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/openstack-dev

Re: [openstack-dev] [tricircle] About registering and loading a plugin

2016-06-28 Thread Yipei Niu

Hi all,

Thanks a lot for your valuable advice. I have already succeed in
registering and loading a self-defined plugin. The entry_point is generated
by executing setup.py, and found in .egg-info/entry_points.txt, which is
different from using setup.cfg in https://review.openstack.org/#/c/331638/.

Moreover, I tried to load drivers by line "cfg.CONF.nyp.plugins.simple",
the console prompts oslo_config.cfg.NoSuchOptError: no such option in group
DEFAULT: nyp. The setup.cfg is defined as follows.

[entry_points]
nyp.plugins.formmater =
simple = nyp.plugins.simple:SimpleFormatter
plain = nyp.plugins.simple:SimpleFormatter
field = nyp.plugins.field:FieldList

How to solve the problem?

Best regards,
Yipei

On Tue, Jun 28, 2016 at 10:35 AM, Vega Cai  wrote:

> Hi Yipei,
>
> You can also refer to my network type driver implementation:
>
> https://review.openstack.org/#/c/331638/
>
> Type driver is registered in setup.cfg and loaded by code.
>
> BR
> Zhiyuan
>
> On 27 June 2016 at 21:44, Yipei Niu  wrote:
>
>> Dear all,
>>
>> Recently, I learn to name a plugin based on the doc
>> http://docs.openstack.org/developer/stevedore/tutorial/naming.html#. I
>> define a new entry_point for the plugin, then it fails. The console prompts
>> "stevedore.exception.NoMatches: No 'net.nyp.formatter' driver found,
>> looking for 'simple'". After setting a new entry_point with setuptools, why
>> stevedore cannot find the driver based on the entry_point?
>>
>> Best regards,
>> Yipei
>>
>
>
__
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/openstack-dev

Re: [openstack-dev] [Fuel] Failed to build the bootstrap image

2016-06-28 Thread Maksim Malchuk

You can start build command with debug options enabled for example and
copy/paste output:
>
> fuel-bootstrap --verbose --debug build --activate
>

Very bad idea to remove logfile, it's better to empty it not remove.

 If you don't have the logfile, so recreate it with command:

> touch /var/log/fuel-bootstrap-image-build.log
>


On Tue, Jun 28, 2016 at 4:09 PM, Alioune  wrote:

> I've removed /var/log/fuel-bootstrap-image-build.log, created new
> bootstrap ubuntu again after setting proxy parameters and reboot.
> After the there is no /var/log/fuel-bootstrap-image-build.log create from
> the new bootstrap but slave doesn't boot correctly.
> Is there another way to detect slave nodes without creating image ?
> Regards,
> [image: Inline images 2]
>
> On 28 June 2016 at 13:34, Maksim Malchuk  wrote:
>
>> You have an issue with connectivity from the Fuel master node to
>> http://archive.ubuntu.com
>> from the log:
>>
>>> Command: debootstrap --include=ca-certificates,apt-transport-https 
>>> --verbose --no-check-gpg --arch=amd64 trusty 
>>> /tmp/tmp1K2haC.fuel-agent-image http://archive.ubuntu.com/ubuntu
>>> Exit code: 1
>>> Stdout: 'I: Retrieving Release \nE: Failed getting release file 
>>> http://archive.ubuntu.com/ubuntu/dists/trusty/Release\n'
>>> Stderr: ''
>>> Failed to execute command: Unexpected error while running command.
>>>
>>> please check your network connectivity, maybe firewall or nat settings.
>>
>>
>> On Tue, Jun 28, 2016 at 2:28 PM, Alioune  wrote:
>>
>>> Hi all,
>>> I tried to create ubuntu bootstrap using [0] but the slave can still not
>>> booting. You can find the bootstrap log following [1].
>>>
>>> Noticed that I've deleted the depot [2] from fuelmenu because it
>>> generated an error  "URL for repository mos is not accessible".
>>>
>>> Regards,
>>>
>>> [0] fuel-bootstrap build --ubuntu-release trusty  --activate
>>> [1]
>>> https://drive.google.com/folderview?id=0B-bfET74f0WZWE9Uc1lVOXJLcWM=sharing
>>> [2]  http://127.0.0.1:8080/ubuntu/x86_64/ mos8.0 main restricted
>>>
>>> On 27 June 2016 at 17:48, Maksim Malchuk  wrote:
>>>
 Maybe the problem because you create the CentOS bootstrap which is
 deprecated now.
 If You really need the CentOS bootstrap, need to look into the
 mentioned log file for this issue.


 On Mon, Jun 27, 2016 at 6:33 PM, Alioune  wrote:

> Thanks for your response,
>
> I've created and activated a new centOS bootstrap as suggested Sergi.
> Now the fuel-slave tries to boot from network but it fails at step
> TFTP http://10.20.0.2/cobbler/boot (unable to locate configuration
> file ).
> The bootstrap zip was generated in
> /tmp/a721103c-8693-4c58-985d-3f8223bdbc88.tar.gz, it seems that the slave
> can not retreive the config files of the bootstrap.
> Are there additional config to do on the master side ?
> Regards
>
>  fuel-bootstrap list
>
> +--+--++
> | uuid | label
>| status |
>
> +--+--++
> | a721103c-8693-4c58-985d-3f8223bdbc88 |
> a721103c-8693-4c58-985d-3f8223bdbc88 | active |
> | centos   | deprecated
> ||
>
> +--+--++
>
> On 27 June 2016 at 16:58, Sergii Golovatiuk 
> wrote:
>
>> Hi,
>>
>> I would suggest to build image from CLI using [0]. That will give
>> more details to you.
>>
>> [0]
>> http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/bootstrap/bootstrap_builder.html
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Mon, Jun 27, 2016 at 3:20 PM, Maksim Malchuk <
>> mmalc...@mirantis.com> wrote:
>>
>>> Hi,
>>>
>>> The error about an internet connection is the only common case. You
>>> should check the actual error in the log file
>>> /var/log/fuel-bootstrap-image-build.log.
>>> You can also share this file with us via any public service
>>> (GoogleDrive, DropBox, etc) and we will check it for you.
>>>
>>> On Mon, Jun 27, 2016 at 4:08 PM, Maksim Malchuk <
>>> mmalc...@mirantis.com> wrote:
>>>
 Hi,

 The error about an internet connection is the only common case. You
 should check the actual error in the log file
 /var/log/fuel-bootstrap-image-build.log.
 You can also share this file with us via any public service
 (GoogleDrive, DropBox, etc) and we will check it for you.


 On Mon, Jun 27, 2016 at 1:43

Re: [openstack-dev] [mistal] Mistral logo ideas?

2016-06-28 Thread Dougal Matthews

On 28 June 2016 at 06:38, Jason Rist  wrote:

> On 06/27/2016 06:57 AM, Dougal Matthews wrote:
> > On 27 June 2016 at 07:45, Renat Akhmerov 
> wrote:
> >
> > >
> > >> Ideally it would be nice to have something that matches the meaning of
> > > the
> > >> name. Maybe we can combine wind with one of the other ideas.
> > >>
> > >> I like the idea of the logo being a stylized wind turbine. Perhaps it
> > > could be
> > >> a turbine with a gust of wind. Then we can show that Mistral harnesses
> > > the
> > >> power of the wind :-)
> > >
> > > Yeah, I’m just wondering how it would look like :)
> > >
> > >
> > Yeah, for this idea we probably need somebody with artistic skills far
> > superior
> > to anything I could manage. We are getting quite a few good ideas now
> > anyway!
> >
> >
> > Renat Akhmerov
> > > @Nokia
> > >
> > >
> >
>
> Ever since I saw the blueprint for a mistral logo, I've been working on
> some ideas.  I've presented a few to Dougal and Ryan, but I'm sharing
> widely here.  I also did the one Michal came up with in Illustrator as
> well.  Please give me some feedback!  Both of the ones I thought of are
> "wind" related.  I thought about doing the ship before as well, but perhaps
> a little too war related, and also obscure.
>

Hey Jason,

Thanks for sending those over - I think I had only seen the first one, not
your workflow version or tornado version before.

I really like Michal's workflow idea that you built on. My only concern is
that it is quite hard to read when it is small - the letters blend into the
arrow lines as they are a similar width. Maybe with a different, or bolder
font it would work better? I only noticed this issue when looking at it via
gmail's preview of the image. Coloring the arrows or letters may help too?

As for the others, I think I prefer the mistral-tornado.png version over
mistral.png

Cool seeing so many ideas come in!


> Thanks,
> Jason
>
> P.S. you may recognize my name from the DLRN logo [1] and the TripleO Logo
> [2].
>
> [1]
> https://github.com/openstack-packages/DLRN/blob/master/doc/source/_images/DLRN.png
> [2]
> https://github.com/dprince/tripleosphinx/blob/master/tripleosphinx/theme/tripleo/static/tripleo_owl.svg
>
> --
> Jason E. Rist
> Senior Software Engineer
> OpenStack User Interfaces
> Red Hat, Inc.
> openuc: +1.972.707.6408
> mobile: +1.720.256.3933
> Freenode: jrist
> github/twitter: knowncitizen
>
__
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/openstack-dev

Re: [openstack-dev] [telemetry] Ceilometer and Aodh install guide(s)

2016-06-28 Thread Caballero Abraham, Rodrigo



> -Original Message-
> From: Ildikó Váncsa [mailto:ildiko.van...@ericsson.com]
> Sent: Tuesday, June 28, 2016 7:56 AM
> To: openstack-d...@lists.openstack.org
> Cc: openstack-dev@lists.openstack.org
> Subject: [OpenStack-docs] [telemetry] Ceilometer and Aodh install
> guide(s)
snip
> 
> The other question I had in mind is in connection with removing "..
> only::". As Ceilometer is integrated with several other projects it needs
> additional configuration steps, where we have distro specific steps to
> follow. I chose the direction of extracting the common parts and reused
> them in the distro specific files. The end result still looks ugly and I have
> concerns about maintainability. We merged a first version of the
> structure, but I'm happy to change if we can come up with a better
> solution. Do you have suggestions on this?
> 
[] 
I would suggest a modular approach with the use of .. include::
It would look something like this:

==
Instructions for Ubuntu
==

.. include:: file-with-common-steps.rst

.. include:: file-with-ubuntu-steps.rst

Then you can do the same for each distro. Having all the separate procedures
in different files should help solve your maintainability concerns.

Regards,
Rodrigo Caballero

snip
> 
> Thanks and Best Regards,
> Ildikó
> 
> [1] https://review.openstack.org/#/c/330051/
> [2] https://review.openstack.org/#/c/330048/
> 
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
__
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/openstack-dev

Re: [openstack-dev] [OpenStack-docs] [telemetry] Ceilometer and Aodh install guide(s)

2016-06-28 Thread Ravi, Goutham

Hi Ildikó, 

Please take a look at the tooling in https://review.openstack.org/#/c/317152/ - 
I tried preserving the ‘only::’ tags because I had a similar concern about all 
the common parts to someone compiling the install guide from time to time. We 
were discussing whether this was a good solution as opposed to using ‘include’ 
directives with distro-specific files referencing common sections; or ignore 
both and maintain four different files (obs, debian, rdo, ubuntu) with common 
sections included within each. 

Thanks, 
Goutham

On 6/28/16, 8:55 AM, "Ildikó Váncsa"  wrote:

Hi,

I'm currently working on to move the Install Guide for Ceilometer [1] and Aodh 
[2] under the project trees. I faced with a few difficulties so far about which 
I would like to ask your opinion.

First of all these two projects are under the Telemetry umbrella, so they are 
not completely separate. I tried to name the services in the documents 
accordingly in the files. My question here would be whether these two guides 
will be included in the overall document as two totally standalone services or 
we can link them together somehow?

The other question I had in mind is in connection with removing ".. only::". As 
Ceilometer is integrated with several other projects it needs additional 
configuration steps, where we have distro specific steps to follow. I chose the 
direction of extracting the common parts and reused them in the distro specific 
files. The end result still looks ugly and I have concerns about 
maintainability. We merged a first version of the structure, but I'm happy to 
change if we can come up with a better solution. Do you have suggestions on 
this?

I have a third less urgent question. The install-guide has it's own folder at 
the same level where these two projects have their 'doc' folder. I would assume 
other projects have the same or similar folder for the developer docs. Would 
that be reasonable/possible to have one main 'doc' folder for all the docs?

Thanks and Best Regards,
Ildikó

[1] https://review.openstack.org/#/c/330051/ 
[2] https://review.openstack.org/#/c/330048/ 

___
OpenStack-docs mailing list
openstack-d...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs


__
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/openstack-dev

[openstack-dev] [charms] inclusion of charm-helpers (LGPL licensed)

2016-06-28 Thread James Page

Hi All

Whilst working on the re-licensing of the OpenStack charms to Apache 2.0,
its apparent that syncing and inclusion of the charm-helpers python module
directly into the charm is not going to work from a license compatibility
perspective. charm-helpers is LGPL v3 (which is OK for a runtime dependency
of an OpenStack project - see [0]).

We already have a plan in place to remove the inclusion of charm-helpers
for execution of functional tests, but we need to come up with a solution
to the runtime requirement for charm-helpers, preferably one that does not
involve direct installation at deploy time from either pypi or from
lp:charm-helpers.

Thoughts? ideas?

Cheers

James

[0] http://governance.openstack.org/reference/licensing.html
__
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/openstack-dev

Re: [openstack-dev] [kolla] Usage of Reno - all devs please read

2016-06-28 Thread Hui Kang

Hi, Steven
Do you mind giving some example of such reno release note? Thanks.

- Hui

On Tue, Jun 28, 2016 at 8:46 AM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> We have had reno in place since the end of Mitaka, yet folks aren't using it
> very often.  I am guilty myself of not thinking of it when reviewing
> changes.
>
> Core reviewers:
> Please –1 any review of significant work that doesn't include a reno release
> note.
>
> Developers:
> If you have made significant changes to the code base (things like
> Ceilometer come to mind) please submit release notes for them.  Note release
> notes should generally be submitted with the work in question, but in this
> case, lets just get the notes in the codebase.
>
> A release note takes 5 minutes to write – it doesn't have to be long and
> complicated.
>
> Thanks
> -steve
>
>
> __
> 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/openstack-dev
>

__
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/openstack-dev

Re: [openstack-dev] [OpenStack-docs] [telemetry] Ceilometer and Aodh install guide(s)

2016-06-28 Thread Andreas Jaeger

On 2016-06-28 14:55, Ildikó Váncsa wrote:
> [...]
> I have a third less urgent question. The install-guide has it's own folder at 
> the same level where these two projects have their 'doc' folder. I would 
> assume other projects have the same or similar folder for the developer docs. 
> Would that be reasonable/possible to have one main 'doc' folder for all the 
> docs?

I understand the sentiment. The install-guide is a separate book, as
Sean Dague called it nicely, which gets published to a different place,
integrated into the full Install Tutorial. If you make it part of the
developer documentation, it might integrate more nicely there but not in
the overall cross-project Install Tutorial. Developer documentation is a
separate book already and placing several books under doc will need even
further changes to make it clear what goes where and how to publish.

So, I think the top-level folder is the best place for this,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

__
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/openstack-dev

Re: [openstack-dev] [Fuel] Failed to build the bootstrap image

I've removed /var/log/fuel-bootstrap-image-build.log, created new bootstrap
ubuntu again after setting proxy parameters and reboot.
After the there is no /var/log/fuel-bootstrap-image-build.log create from
the new bootstrap but slave doesn't boot correctly.
Is there another way to detect slave nodes without creating image ?
Regards,
[image: Inline images 2]

On 28 June 2016 at 13:34, Maksim Malchuk  wrote:

> You have an issue with connectivity from the Fuel master node to
> http://archive.ubuntu.com
> from the log:
>
>> Command: debootstrap --include=ca-certificates,apt-transport-https --verbose 
>> --no-check-gpg --arch=amd64 trusty /tmp/tmp1K2haC.fuel-agent-image 
>> http://archive.ubuntu.com/ubuntu
>> Exit code: 1
>> Stdout: 'I: Retrieving Release \nE: Failed getting release file 
>> http://archive.ubuntu.com/ubuntu/dists/trusty/Release\n'
>> Stderr: ''
>> Failed to execute command: Unexpected error while running command.
>>
>> please check your network connectivity, maybe firewall or nat settings.
>
>
> On Tue, Jun 28, 2016 at 2:28 PM, Alioune  wrote:
>
>> Hi all,
>> I tried to create ubuntu bootstrap using [0] but the slave can still not
>> booting. You can find the bootstrap log following [1].
>>
>> Noticed that I've deleted the depot [2] from fuelmenu because it
>> generated an error  "URL for repository mos is not accessible".
>>
>> Regards,
>>
>> [0] fuel-bootstrap build --ubuntu-release trusty  --activate
>> [1]
>> https://drive.google.com/folderview?id=0B-bfET74f0WZWE9Uc1lVOXJLcWM=sharing
>> [2]  http://127.0.0.1:8080/ubuntu/x86_64/ mos8.0 main restricted
>>
>> On 27 June 2016 at 17:48, Maksim Malchuk  wrote:
>>
>>> Maybe the problem because you create the CentOS bootstrap which is
>>> deprecated now.
>>> If You really need the CentOS bootstrap, need to look into the mentioned
>>> log file for this issue.
>>>
>>>
>>> On Mon, Jun 27, 2016 at 6:33 PM, Alioune  wrote:
>>>
 Thanks for your response,

 I've created and activated a new centOS bootstrap as suggested Sergi.
 Now the fuel-slave tries to boot from network but it fails at step TFTP
 http://10.20.0.2/cobbler/boot (unable to locate configuration file ).
 The bootstrap zip was generated in
 /tmp/a721103c-8693-4c58-985d-3f8223bdbc88.tar.gz, it seems that the slave
 can not retreive the config files of the bootstrap.
 Are there additional config to do on the master side ?
 Regards

  fuel-bootstrap list

 +--+--++
 | uuid | label
| status |

 +--+--++
 | a721103c-8693-4c58-985d-3f8223bdbc88 |
 a721103c-8693-4c58-985d-3f8223bdbc88 | active |
 | centos   | deprecated
   ||

 +--+--++

 On 27 June 2016 at 16:58, Sergii Golovatiuk 
 wrote:

> Hi,
>
> I would suggest to build image from CLI using [0]. That will give more
> details to you.
>
> [0]
> http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/bootstrap/bootstrap_builder.html
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Mon, Jun 27, 2016 at 3:20 PM, Maksim Malchuk  > wrote:
>
>> Hi,
>>
>> The error about an internet connection is the only common case. You
>> should check the actual error in the log file
>> /var/log/fuel-bootstrap-image-build.log.
>> You can also share this file with us via any public service
>> (GoogleDrive, DropBox, etc) and we will check it for you.
>>
>> On Mon, Jun 27, 2016 at 4:08 PM, Maksim Malchuk <
>> mmalc...@mirantis.com> wrote:
>>
>>> Hi,
>>>
>>> The error about an internet connection is the only common case. You
>>> should check the actual error in the log file
>>> /var/log/fuel-bootstrap-image-build.log.
>>> You can also share this file with us via any public service
>>> (GoogleDrive, DropBox, etc) and we will check it for you.
>>>
>>>
>>> On Mon, Jun 27, 2016 at 1:43 PM, Alioune 
>>> wrote:
>>>
 hi all,

 I'm trying to install fuel in VirtualBox, the fuel master is
 correctly running but I'm receiving the this error on the fuel GUI:

 WARNING: Failed to build the bootstrap image, see
 /var/log/fuel-bootstrap-image-build.log for details.
 Perhaps your Internet connection is broken. Please fix the problem
 and run `fuel-bootstrap build --activate`.
 While you don't activate any bootstrap -

[openstack-dev] [telemetry] Ceilometer and Aodh install guide(s)

Hi,

I'm currently working on to move the Install Guide for Ceilometer [1] and Aodh 
[2] under the project trees. I faced with a few difficulties so far about which 
I would like to ask your opinion.

First of all these two projects are under the Telemetry umbrella, so they are 
not completely separate. I tried to name the services in the documents 
accordingly in the files. My question here would be whether these two guides 
will be included in the overall document as two totally standalone services or 
we can link them together somehow?

The other question I had in mind is in connection with removing ".. only::". As 
Ceilometer is integrated with several other projects it needs additional 
configuration steps, where we have distro specific steps to follow. I chose the 
direction of extracting the common parts and reused them in the distro specific 
files. The end result still looks ugly and I have concerns about 
maintainability. We merged a first version of the structure, but I'm happy to 
change if we can come up with a better solution. Do you have suggestions on 
this?

I have a third less urgent question. The install-guide has it's own folder at 
the same level where these two projects have their 'doc' folder. I would assume 
other projects have the same or similar folder for the developer docs. Would 
that be reasonable/possible to have one main 'doc' folder for all the docs?

Thanks and Best Regards,
Ildikó

[1] https://review.openstack.org/#/c/330051/ 
[2] https://review.openstack.org/#/c/330048/ 

__
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/openstack-dev

[openstack-dev] [kolla] Usage of Reno - all devs please read

2016-06-28 Thread Steven Dake (stdake)

Hey folks,

We have had reno in place since the end of Mitaka, yet folks aren't using it 
very often.  I am guilty myself of not thinking of it when reviewing changes.

Core reviewers:
Please -1 any review of significant work that doesn't include a reno release 
note.

Developers:
If you have made significant changes to the code base (things like Ceilometer 
come to mind) please submit release notes for them.  Note release notes should 
generally be submitted with the work in question, but in this case, lets just 
get the notes in the codebase.

A release note takes 5 minutes to write - it doesn't have to be long and 
complicated.

Thanks
-steve

__
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/openstack-dev

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

2016-06-28 Thread Andrew Laski

 
 
 
On Tue, Jun 28, 2016, at 03:26 AM, Zhenyu Zheng wrote:
> Hi all,
>
> I'm working on add pagination and timestamp filter for os-instance-
> actions API:
> https://review.openstack.org/#/c/326326/
> As Alex_xu pointed out that it will be better to filter by
> `updated_at` for timestamp filter which is reasonable, but when I
> tried to modify the patch I found out that:
>
> 1. The current APIs only called _record_action_start
>(objects.InstanceAction.action_start) and never call
>action_finish, so
> the field of `finish_time` is always empty in instance_actions table;
 
There was a spec proposed to address this, though I don't believe it
was approved for Newton. So for now you have to assume this will
continue to be empty.
 
>
> 2. The updated_at field is also empty, should we sync the updated_at
>time to the created_at time when we create the action and also
>update it whenever the action status changed, e.g finished.
 
When a finish_time is recorded that should definitely also update
updated_at. I would be in favor of having updated_at set when the
instance action is created. I've never fully understood why Nova doesn't
do that generally.
 
>
> Thanks,
> Kevin Zheng
> -
> 
> 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/openstack-dev
 
__
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/openstack-dev

Re: [openstack-dev] [cinder] [keystone] cinder quota behavior differences after Keystone mitaka upgrade

2016-06-28 Thread Rodrigo Duarte

On Tue, Jun 28, 2016 at 3:38 AM, Henry Nash  wrote:

> Hi Matt,
>
> So the keystone changes were intentional. From Mitaka onwards, a domain is
> represented as a project which is “acting as a domain” (it has an attribute
> “is_domain” set to true). The situation you describe, where what were top
> level projects now have the project acting as the default domain as their
> parent, is what I would expect to happen after the update.
>
> During Mitaka development, we  worked with the cinder folks - who were to
> re-designing their quota code anyway - and this was modified to take
> account of the project structure. I’m not sure if the quota semantics you
> see are what was intended (I’ll let the cinder team comment). Code can, if
> desired, distinguish the case of top projects that are at the top level, vs
> projects somewhere way down the hierarchy, by looking at the parent and
> seeing if it is a project acting as a domain.
>

Just to add to Henry's answer, checking if the parent is a project acting
as a domain is just matter of comparing the parent_id with the domain_id,
if they are equal, it means the parent is a project acting as a domain.


>
> Henry
> keystone core
>
> On 27 Jun 2016, at 17:13, Matt Fischer  wrote:
>
> We upgraded our dev environment last week to Keystone stable/mitaka. Since
> then we're unable to show or set quotas on projects of which the admin is
> not a member. Looking at the cinder code, it seems that cinder is pulling a
> project list and attempting to determine a hierarchy.  On Liberty Keystone,
> projects seem to lack parents:
>
>  id=9e839870dd0d4a2f96f9d71b7e7c5a4e, is_domain=False, links={u'self': u'
> https://liberty-endpoint:5000/v3/projects/9e839870dd0d4a2f96f9d71b7e7c5a4e'},
> name=admin, parent_id=None, subtree=None>
>
> In Mitaka, it seems that projects are children of the default domain:
>
>  id=4764ba822ecb43e582794b875751924c, is_domain=False, links={u'self': u'
> http://mitaka-endpoint:5000/v3/projects/4764ba822ecb43e582794b875751924c'},
> name=admin, parent_id=default, subtree=None>
>
> In Liberty since all projects were parentless, the authorize_* code blocks
> were skipped since both conditionals were false:
>
>
> https://github.com/openstack/cinder/blob/stable/liberty/cinder/api/contrib/quotas.py#L174-L191
>
> But now in Mitaka, the code is run, and it fails out since the projects
> are "brothers", both with the parent of the default domain, but not
> hierarchically related.
>
> Previously it was a useful ability for us to be able to (as admins) set
> and view  quotas for cinder projects. Now we need to scope into the user's
> project to even be able to view their quotas, much less change them. This
> seems broken, but I'm not sure where the issue is or why the keystone
> behavior changed. Is this the expected behavior?
>
> __
> 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/openstack-dev
>
>
>
> __
> 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/openstack-dev
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
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/openstack-dev

[openstack-dev] [nova][SR-IOV] PCI/SR-IOV meeting today is canceled 06/28/16

2016-06-28 Thread Moshe Levi

Sorry for the late mail, but I won't be able to chair the meeting today 

__
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/openstack-dev

[openstack-dev] 答复: [probably forge email可能是仿冒邮件] [kolla] version of python2-oslo-config

2016-06-28 Thread hu . zhijiang

Sorry I used the wrong branch of Kolla, in stable/Mitaka , Kolla only 
requires oslo-config ver 3.7




发件人: hu.zhiji...@zte.com.cn
收件人: "OpenStack Development Mailing List (not for usage 
questions)" , 
日期:   2016-06-28 19:34
主题:   [probably forge email可能是仿冒邮件][openstack-dev] [kolla] 
version of python2-oslo-config



Hi Kolla team, 

Base upon requirement.txt, Kolla needs oslo-config version 3.10. But 
CentOS Mitaka uses 3.9 ,which is 
python2-oslo-config-3.9.0-1.el7.noarch.rpm. 

I want to know if Kolla can also work on oslo-config-3.9.0. If it can, 
then will be a benefit because pip is conflict with rpm on 
python2-oslo-config package. For example, the rpm version has the ability 
to find config file in /usr/share/keystone/keystone-dist.conf but the pip 
version not. 


Thanks 
Zhijiang, 


ZTE Information Security Notice: The information contained in this mail 
(and any attachment transmitted herewith) is privileged and confidential 
and is intended for the exclusive use of the addressee(s).  If you are not 
an intended recipient, any disclosure, reproduction, distribution or other 
dissemination or use of the information contained is strictly prohibited. 
If you have received this mail in error, please delete it and notify us 
immediately.


__
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/openstack-dev



ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
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/openstack-dev

Re: [openstack-dev] [tripleo] glance backend: replace swift by file in CI

2016-06-28 Thread Erno Kuvaja

TL;DR

Makes absolutely sense to run file backend on single node undercloud at CI.

Few more comments inline.

On Mon, Jun 27, 2016 at 8:49 PM, Emilien Macchi  wrote:
> On Mon, Jun 27, 2016 at 3:46 PM, Clay Gerrard  wrote:
>> There's probably some minimal gain in cross compatibility testing to
>> sticking with the status quo.  The Swift API is old and stable, but I
>> believe there was some bug in recent history where some return value in
>> swiftclient changed from a iterable to a generator or something and some
>> aggressive non-duck type checking broke something somewhere
>>
>> I find that bug reports sorta interesting, the reported memory pressure
>> there doesn't make sense.  Maybe there's some non-
>> essential middleware configured on that proxy that's causing the workers to
>> bloat up like that?
>
> Swift proxy pipeline:
> pipeline = catch_errors healthcheck cache ratelimit bulk tempurl
> formpost authtoken keystone staticweb proxy-logging proxy-server

Some things I do not think we benefit having there if we want to
experiment still with swift in undercloud:
staticweb - do we need containers being presented as webpages?
tempurl - Id assume we can expect the user having access the needed
objects with their own credentials.
formpost - likely we do not need http forms instead of PUT calls either.
ratelimit - There and there, have we had single time where something
goes grazy and ratelimit has saved us and the tests still not failed.
healthcheck - not likely used, but also really lightweight so
shouldn't make any difference

cache - Memcache is likely the thing that kills us.

>
> Thanks for your help,
>
>> -clayg
>>
>> On Mon, Jun 27, 2016 at 12:30 PM, Emilien Macchi  wrote:
>>>
>>> Hi,
>>>
>>> Today we're re-investigating a CI failure that we had multiple times [1]:
>>> Swift memory usage grows until it is OOM-killed.
>>>
>>> The perimeter of this thread is about our CI and not production
>>> environments.
>>> Indeed, our CI is running limited resources while production
>>> environments should not hit this problem.
>>>
>>> After some investigation on #ŧripleo, we found out this scenario was
>>> happening almost every time since recently:
>>>
>>> * undercloud is deployed, glance and swift are running. Glance is
>>> configured with Swift backend to store images.
>>> * tripleo CI upload overcloud image into Glance, image is successfully
>>> uploaded.
>>> * when overcloud starts deploying, some nodes randomly fail to deploy
>>> because the undercloud OOM-kills swift-proxy-server that is still
>>> sending the ovecloud image requested by Glance API. Swift fails,
>>> Glance fails, overcloud deployment fails with a "No valid hosts
>>> found".
>>>
>>> It's likely due to performances issues in our CI, and there is nothing
>>> we can do but adding more resources or reducing the number of
>>> environments, something we won't do at this time, because our recent
>>> improvements in our CI (more ram, SSD, etc).

So the possible streamlining and optimizing swift for small
environment was tried already?

Another thing that comes to my mind based on the discussions lately.
What is the core count on our CI uc node? Are all the serviced
deployed there with their default worker values? Might be sensible
(even for production use) to limit the amount of workers our services
kick up in aio undercloud as that tends to have huge impact on memory
consumption.

- Erno "jokke_" Kuvaja
>>>
>>> As a first iteration, I propose [2] that we stop using Swift as a
>>> backend for Glance. Indeed, our undercloud is currently single-node, I
>>> see zero value of using Swift to store the overcloud image.
>>> If there is a value, then we can add the option to whether or not
>>> using it (and set it to False in our CI to use file backend, which
>>> won't lead to OOM).
>>>
>>> Note: on the overcloud: we currently support file, swift and rbd
>>> backends, that you can easily select during your deployment.
>>>
>>> [1] https://bugs.launchpad.net/tripleo/+bug/1595916
>>> [2] https://review.openstack.org/#/c/334555/
>>> --
>>> Emilien Macchi
>>>
>>> __
>>> 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/openstack-dev
>>
>>
>>
>> __
>> 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/openstack-dev
>>
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>

Re: [openstack-dev] [Fuel] Failed to build the bootstrap image

2016-06-28 Thread Maksim Malchuk

You have an issue with connectivity from the Fuel master node to
http://archive.ubuntu.com
from the log:

> Command: debootstrap --include=ca-certificates,apt-transport-https --verbose 
> --no-check-gpg --arch=amd64 trusty /tmp/tmp1K2haC.fuel-agent-image 
> http://archive.ubuntu.com/ubuntu
> Exit code: 1
> Stdout: 'I: Retrieving Release \nE: Failed getting release file 
> http://archive.ubuntu.com/ubuntu/dists/trusty/Release\n'
> Stderr: ''
> Failed to execute command: Unexpected error while running command.
>
> please check your network connectivity, maybe firewall or nat settings.


On Tue, Jun 28, 2016 at 2:28 PM, Alioune  wrote:

> Hi all,
> I tried to create ubuntu bootstrap using [0] but the slave can still not
> booting. You can find the bootstrap log following [1].
>
> Noticed that I've deleted the depot [2] from fuelmenu because it generated
> an error  "URL for repository mos is not accessible".
>
> Regards,
>
> [0] fuel-bootstrap build --ubuntu-release trusty  --activate
> [1]
> https://drive.google.com/folderview?id=0B-bfET74f0WZWE9Uc1lVOXJLcWM=sharing
> [2]  http://127.0.0.1:8080/ubuntu/x86_64/ mos8.0 main restricted
>
> On 27 June 2016 at 17:48, Maksim Malchuk  wrote:
>
>> Maybe the problem because you create the CentOS bootstrap which is
>> deprecated now.
>> If You really need the CentOS bootstrap, need to look into the mentioned
>> log file for this issue.
>>
>>
>> On Mon, Jun 27, 2016 at 6:33 PM, Alioune  wrote:
>>
>>> Thanks for your response,
>>>
>>> I've created and activated a new centOS bootstrap as suggested Sergi.
>>> Now the fuel-slave tries to boot from network but it fails at step TFTP
>>> http://10.20.0.2/cobbler/boot (unable to locate configuration file ).
>>> The bootstrap zip was generated in
>>> /tmp/a721103c-8693-4c58-985d-3f8223bdbc88.tar.gz, it seems that the slave
>>> can not retreive the config files of the bootstrap.
>>> Are there additional config to do on the master side ?
>>> Regards
>>>
>>>  fuel-bootstrap list
>>>
>>> +--+--++
>>> | uuid | label
>>>  | status |
>>>
>>> +--+--++
>>> | a721103c-8693-4c58-985d-3f8223bdbc88 |
>>> a721103c-8693-4c58-985d-3f8223bdbc88 | active |
>>> | centos   | deprecated
>>>   ||
>>>
>>> +--+--++
>>>
>>> On 27 June 2016 at 16:58, Sergii Golovatiuk 
>>> wrote:
>>>
 Hi,

 I would suggest to build image from CLI using [0]. That will give more
 details to you.

 [0]
 http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/bootstrap/bootstrap_builder.html

 --
 Best regards,
 Sergii Golovatiuk,
 Skype #golserge
 IRC #holser

 On Mon, Jun 27, 2016 at 3:20 PM, Maksim Malchuk 
 wrote:

> Hi,
>
> The error about an internet connection is the only common case. You
> should check the actual error in the log file
> /var/log/fuel-bootstrap-image-build.log.
> You can also share this file with us via any public service
> (GoogleDrive, DropBox, etc) and we will check it for you.
>
> On Mon, Jun 27, 2016 at 4:08 PM, Maksim Malchuk  > wrote:
>
>> Hi,
>>
>> The error about an internet connection is the only common case. You
>> should check the actual error in the log file
>> /var/log/fuel-bootstrap-image-build.log.
>> You can also share this file with us via any public service
>> (GoogleDrive, DropBox, etc) and we will check it for you.
>>
>>
>> On Mon, Jun 27, 2016 at 1:43 PM, Alioune  wrote:
>>
>>> hi all,
>>>
>>> I'm trying to install fuel in VirtualBox, the fuel master is
>>> correctly running but I'm receiving the this error on the fuel GUI:
>>>
>>> WARNING: Failed to build the bootstrap image, see
>>> /var/log/fuel-bootstrap-image-build.log for details.
>>> Perhaps your Internet connection is broken. Please fix the problem
>>> and run `fuel-bootstrap build --activate`.
>>> While you don't activate any bootstrap - new nodes cannot be
>>> discovered and added to cluster.
>>> For more information please visit
>>> https://docs.mirantis.com/openstack/fuel/fuel-master/
>>>
>>> The fuel server has access to internet even though it could not find
>>> depots during install, I ran "yum update" and reboot but I still get 
>>> this
>>> error.
>>> I configured a fuel-slave server boot from network attached to the
>>> fuel-master but the process failed also.
>>> Any help please to solve this ?
>>>
>>> Regards,
>>>
>>>

[openstack-dev] [kolla] version of python2-oslo-config

2016-06-28 Thread hu . zhijiang

Hi Kolla team,

Base upon requirement.txt, Kolla needs oslo-config version 3.10. But 
CentOS Mitaka uses 3.9 ,which is 
python2-oslo-config-3.9.0-1.el7.noarch.rpm.

I want to know if Kolla can also work on oslo-config-3.9.0. If it can, 
then will be a benefit because pip is conflict with rpm on 
python2-oslo-config package. For example, the rpm version has the ability 
to find config file in /usr/share/keystone/keystone-dist.conf but the pip 
version not.


Thanks
Zhijiang,

ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
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/openstack-dev

[openstack-dev] [new][oslo] tooz 1.40.0 release (newton)

We are psyched to announce the release of:

tooz 1.40.0: Coordination library for distributed systems.

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/tooz

With package available at:

https://pypi.python.org/pypi/tooz

Please report issues through launchpad:

http://bugs.launchpad.net/python-tooz/

For more details, please see below.

Changes in tooz 1.39.0..1.40.0
--

170680e Add docs for new consul driver
e8d37b0 Change dependency to use flavors
7360f85 Run doc8 only in pep8 target
e2683c7 Move pep8 requirements in their own target
d096a0d zookeeper: do not hard depend on eventlet
36655c6 Remove unused iso8601 dependency
040464e tests: remove testscenario usage
2ec9044 file: set no timeout by default
ebf6ae1 tests: move bad_url from scenarios to static test
756d265 Expose timeout capabilities and use them for tests
4906e72 Use pifpaf to setup daemons
274f9a6 redis: do not force LuaLock


Diffstat (except docs and test files)
-

requirements.txt|   4 --
setup-consul-env.sh | 125 +++-
setup-etcd-env.sh   |  16 +
setup-memcached-env.sh  |  22 ---
setup-mysql-env.sh  |  49 
setup-postgresql-env.sh |  23 
setup-redis-env.sh  |  22 ---
setup-sentinel-env.sh   |  56 --
setup-zookeeper-env.sh  |  55 --
setup.cfg   |  41 +
test-requirements.txt   |  29 --
tools/compat-matrix.py  |   4 ++
tooz/coordination.py|   7 +++
tooz/drivers/file.py|   8 ++-
tooz/drivers/ipc.py |   1 +
tooz/drivers/mysql.py   |   1 +
tooz/drivers/pgsql.py   |   1 +
tooz/drivers/redis.py   |   7 +--
tooz/drivers/zake.py|   1 +
tooz/drivers/zookeeper.py   |  11 +++-
tox.ini |  53 ++---
26 files changed, 214 insertions(+), 479 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index e6cff75..826db66 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8,2 +7,0 @@ enum34;python_version=='2.7' or python_version=='2.6' or 
python_version=='3.3' #
-iso8601>=0.1.11 # MIT
-zake>=0.1.6 # Apache-2.0
@@ -18,2 +15,0 @@ oslo.serialization>=1.10.0 # Apache-2.0
-requests>=2.10.0 # Apache-2.0
-python-consul>=0.4.7 # MIT License



__
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/openstack-dev

[openstack-dev] [new][oslo] oslo.messaging 5.5.0 release (newton)

We are glad to announce the release of:

oslo.messaging 5.5.0: Oslo Messaging API

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.messaging

With package available at:

https://pypi.python.org/pypi/oslo.messaging

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.messaging

For more details, please see below.

Changes in oslo.messaging 5.4.0..5.5.0
--

dfd5c79 [zmq] Fix message sending when using proxy and not using PUB/SUB
3316edb AMQP 1.0 - create only one Cyrus SASL configuration for the tests
5afb605 Updated from global requirements
eb02de8 [zmq] Remove redundant Envelope class
33c3f16 [zmq] Properly stop ZmqServer
e57afac [Trival] fix a typo nit
d8b6bb0 [zmq] Fix backend router port for proxy.


Diffstat (except docs and test files)
-

.../_drivers/zmq_driver/broker/zmq_queue_proxy.py  |  8 +-
.../publishers/dealer/zmq_dealer_call_publisher.py |  2 -
.../publishers/dealer/zmq_dealer_publisher.py  |  2 -
.../dealer/zmq_dealer_publisher_proxy.py   |  5 +-
.../client/publishers/dealer/zmq_reply_waiter.py   |  4 +-
.../client/publishers/zmq_pub_publisher.py |  2 +-
.../_drivers/zmq_driver/client/zmq_envelope.py | 89 --
.../_drivers/zmq_driver/client/zmq_request.py  | 15 
.../zmq_driver/matchmaker/matchmaker_redis.py  | 10 ++-
.../server/consumers/zmq_consumer_base.py  | 13 
.../server/consumers/zmq_dealer_consumer.py| 27 +++
.../server/consumers/zmq_router_consumer.py|  7 +-
.../zmq_driver/server/zmq_incoming_message.py  |  4 +-
.../_drivers/zmq_driver/server/zmq_server.py   |  8 +-
oslo_messaging/_drivers/zmq_driver/zmq_updater.py  |  3 +
oslo_messaging/notify/notifier.py  |  2 +-
requirements.txt   |  4 +-
setup-test-env-zmq.sh  |  8 +-
test-requirements.txt  |  2 +-
21 files changed, 105 insertions(+), 176 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 7ec46a9..54d0895 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8,2 +8,2 @@ futurist>=0.11.0 # Apache-2.0
-oslo.config>=3.9.0 # Apache-2.0
-oslo.context>=2.2.0 # Apache-2.0
+oslo.config>=3.10.0 # Apache-2.0
+oslo.context>=2.4.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 6f5b25c..19b0eb8 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -9 +9 @@ discover # BSD
-fixtures<2.0,>=1.3.1 # Apache-2.0/BSD
+fixtures>=3.0.0 # Apache-2.0/BSD



__
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/openstack-dev

Re: [openstack-dev] [Fuel] Failed to build the bootstrap image

Hi all,
I tried to create ubuntu bootstrap using [0] but the slave can still not
booting. You can find the bootstrap log following [1].

Noticed that I've deleted the depot [2] from fuelmenu because it generated
an error  "URL for repository mos is not accessible".

Regards,

[0] fuel-bootstrap build --ubuntu-release trusty  --activate
[1]
https://drive.google.com/folderview?id=0B-bfET74f0WZWE9Uc1lVOXJLcWM=sharing
[2]  http://127.0.0.1:8080/ubuntu/x86_64/ mos8.0 main restricted

On 27 June 2016 at 17:48, Maksim Malchuk  wrote:

> Maybe the problem because you create the CentOS bootstrap which is
> deprecated now.
> If You really need the CentOS bootstrap, need to look into the mentioned
> log file for this issue.
>
>
> On Mon, Jun 27, 2016 at 6:33 PM, Alioune  wrote:
>
>> Thanks for your response,
>>
>> I've created and activated a new centOS bootstrap as suggested Sergi.
>> Now the fuel-slave tries to boot from network but it fails at step TFTP
>> http://10.20.0.2/cobbler/boot (unable to locate configuration file ).
>> The bootstrap zip was generated in
>> /tmp/a721103c-8693-4c58-985d-3f8223bdbc88.tar.gz, it seems that the slave
>> can not retreive the config files of the bootstrap.
>> Are there additional config to do on the master side ?
>> Regards
>>
>>  fuel-bootstrap list
>>
>> +--+--++
>> | uuid | label
>>  | status |
>>
>> +--+--++
>> | a721103c-8693-4c58-985d-3f8223bdbc88 |
>> a721103c-8693-4c58-985d-3f8223bdbc88 | active |
>> | centos   | deprecated
>> ||
>>
>> +--+--++
>>
>> On 27 June 2016 at 16:58, Sergii Golovatiuk 
>> wrote:
>>
>>> Hi,
>>>
>>> I would suggest to build image from CLI using [0]. That will give more
>>> details to you.
>>>
>>> [0]
>>> http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/bootstrap/bootstrap_builder.html
>>>
>>> --
>>> Best regards,
>>> Sergii Golovatiuk,
>>> Skype #golserge
>>> IRC #holser
>>>
>>> On Mon, Jun 27, 2016 at 3:20 PM, Maksim Malchuk 
>>> wrote:
>>>
 Hi,

 The error about an internet connection is the only common case. You
 should check the actual error in the log file
 /var/log/fuel-bootstrap-image-build.log.
 You can also share this file with us via any public service
 (GoogleDrive, DropBox, etc) and we will check it for you.

 On Mon, Jun 27, 2016 at 4:08 PM, Maksim Malchuk 
 wrote:

> Hi,
>
> The error about an internet connection is the only common case. You
> should check the actual error in the log file
> /var/log/fuel-bootstrap-image-build.log.
> You can also share this file with us via any public service
> (GoogleDrive, DropBox, etc) and we will check it for you.
>
>
> On Mon, Jun 27, 2016 at 1:43 PM, Alioune  wrote:
>
>> hi all,
>>
>> I'm trying to install fuel in VirtualBox, the fuel master is
>> correctly running but I'm receiving the this error on the fuel GUI:
>>
>> WARNING: Failed to build the bootstrap image, see
>> /var/log/fuel-bootstrap-image-build.log for details.
>> Perhaps your Internet connection is broken. Please fix the problem
>> and run `fuel-bootstrap build --activate`.
>> While you don't activate any bootstrap - new nodes cannot be
>> discovered and added to cluster.
>> For more information please visit
>> https://docs.mirantis.com/openstack/fuel/fuel-master/
>>
>> The fuel server has access to internet even though it could not find
>> depots during install, I ran "yum update" and reboot but I still get this
>> error.
>> I configured a fuel-slave server boot from network attached to the
>> fuel-master but the process failed also.
>> Any help please to solve this ?
>>
>> Regards,
>>
>>
>> __
>> 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/openstack-dev
>>
>>
>
>
> --
> Best Regards,
> Maksim Malchuk,
> Senior DevOps Engineer,
> MOS: Product Engineering,
> Mirantis, Inc
> 
>



 --
 Best Regards,
 Maksim Malchuk,
 Senior DevOps Engineer,
 MOS: Product Engineering,
 Mirantis, Inc
 


 __
 OpenStack Development Mailing List

[openstack-dev] [new][oslo] oslo.vmware 2.10.0 release (newton)

We are eager to announce the release of:

oslo.vmware 2.10.0: Oslo VMware library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.vmware

With package available at:

https://pypi.python.org/pypi/oslo.vmware

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.vmware

For more details, please see below.

Changes in oslo.vmware 2.9.0..2.10.0


8d8a5de Updated from global requirements
784ad53 Support download of virtual disk in ova container


Diffstat (except docs and test files)
-

oslo_vmware/image_transfer.py|  32 +-
oslo_vmware/image_util.py|  30 +
requirements.txt |   1 +
test-requirements.txt|   2 +-
7 files changed, 364 insertions(+), 50 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 8682b9e..c952316 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -16,0 +17 @@ PyYAML>=3.1.0 # MIT
+lxml>=2.3 # BSD
diff --git a/test-requirements.txt b/test-requirements.txt
index e1fdf23..a40ffab 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -24 +24 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



__
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/openstack-dev

[openstack-dev] [new][oslo] oslo.middleware 3.14.0 release (newton)