Re: [openstack-dev] [Nova][Neutron]What's the problem if there is no port status 'up' notification sent from neutron, while creating VM

[Kevin Benton]

The VM is paused until the 'up' notification to give the Neutron backend
time to wire up the port.

On Tue, Jun 28, 2016 at 7:59 PM,  wrote:

>  Hi guys:
>
> As we know, nova will interacts with neutron for port creating and
> configuration while creating VM.
>
> In the method /nova/virt/libvirt/driver.py:_create_domain_and_network,
> here nova ultilizes event mechanism(sqlalchemy) to monitor port status in
> neutron DB. After having subscribed event from neutron DB for port status
> update, it will wait for the event sent from neutron. Finally nova revceive
> port status update event sent from neutron server, which means port is
> ready and the creating of VM will almost complete. But it seems like the
> creating of VM will fail if nova not receive event after the timeout
> period(default 300s).
>
> What the problem I have encountered is that the VM have been created
> successfully without the notification event send from neutron. Using
> command "nova show VM-ID" shows all states of VM are correct(vm_state:
> active and power state: running). Let's assume a scenario where we replace
> neutron agent with controller, as in the case of OVN, dragonflow, ODL,etc.
>
> There is an example to support port 'up' or 'down ' notification in
> project OVN. Please refer to this link:
> https://review.openstack.org/#/c/178826/
>
> So, anyone can give an explanation what's the purpose of the event? Dose
> the event have any impact on creating of VM? Any comment will be
> appreciated, thanks!
>
> Best Regard!
> Jingting
>
> __
> 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] [storlets] Docker images re-structuring

[kajinamit]

Hi Eran,


Thank you for bringing up a great idea.

> 1. Much easier to upgrade.
> 2. Less time from fix to test.
That's a big problem I experienced in my testing.
Storlet agent should be managed by infra operator side,
not by application developer side, as a part of infra software.

It's a little bit strange and hard work for system operators,
to ask all application developers to upgrade their container
when infra software is updated.

Your idea seems to show the appropriate way to go.

As I discussed with you in the last irc meeting(yesterday),
We should be careful about the runtime on which storlets stuff
works. (jre and python)
IMO, they should also be managed by infra side, and placed outside
docker container.

We have to consider some more things to realize the idea,
but anyway it makes much sense to me!

Thank you,
Takashi

-Original Message-
From: e...@itsonlyme.name [mailto:e...@itsonlyme.name] 
Sent: Tuesday, June 28, 2016 6:05 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [storlets] Docker images re-structuring

Currently, our Docker images are built form the following layers:
1. Ubuntu 14.04
2. JRE 8
3. Storlets stuff
4. Dummy layer having the tenant id as a name.

Only yesterday (after more then 2 years...), it occurred to me that the 3rd 
layer is a bit of a (understatement) mistake. Why not place the storlets stuff 
(daemon_factory, SDaemon, SCommon, etc.) in a read only mountable volume?

Pros:
1. Much easier to upgrade.
2. Less time from fix to test.
3. Less disk space that is wasted on Docker images as upgrades accumulate.

Thoughts?

Thanks,
Eran


__
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] [mistal] Mistral logo ideas?

[Renat Akhmerov]

> On 30 Jun 2016, at 00:12, Jason Rist  wrote:
> I was thinking of a tornado with eyes or a tasmanian devil.  Both are wind 
> related.  Thoughts?

Jason, that would be cool to see :) Something like this IMO would be awesome, 
but as always in such cases, a particular illustration matters the most.


Renat Akhmerov
@Nokia

__
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] [constraints] Updating stable branch URL

[Sachi King]

On Tue, Jun 28, 2016 at 9:38 AM, Tony Breeds  wrote:
> On Mon, Jun 27, 2016 at 11:28:47PM +, Jeremy Stanley wrote:
>
>> I want to say there was a reason we were branching the requirements
>> repo last, but now I can't remember what it is (or if we even did
>> branch it last). Thierry or Doug likely recall but are indisposed
>> this week so I suggest waiting until they're around to reply before
>> making a decision on this anyway (especially since it's the Release
>> Managers who will need to adjust that process if it does merit
>> changing).

I don't remember the specifics, but I had a chat about this some time
ago, and concur.  As well, requirements branched a couple weeks after
both Nova and Neutron this time around, I didn't check any others.


Regardless, I don't think there is any way to make a compelling
argument that the constraints URL should ever dictate when
the reqs repo should be branched, even if there weren't current
restrictions to this.


> I'm not certain how this is different to updating .gitreview and the default
> branch?  Can't we extend the tools[1] that do that step with the updating of
> tox.ini?

I initially had the same thought as Jeremy here, forgetting it could sit in
review on the stable branch.  While having it sit in the queue and needing
to be manually checked if it can be merged yet is sub-optimal, I think that
is probably the best option so far.  The commit message could contain
details as to the limitations/a link to documentation.


> It could be worked around with
> additional logic to fall back on the master URL if the branch
> doesn't exist, but it's also possible we just document this as a
> shortcoming for the sake of simplicity.

This would be wonderful, but I think it would raise the barrier
to entry on constraints a bit too high and would end up relying
a bit too much on un-gated code that would mostly be cargo-cult.
To support this with tox, would require wrapping the tox
install_command on any project that wishes to use constraints,
and modifying existing wrapped install_command, which is
common with the neutron-*aas projects, without any easy way
to update any of them.

> OK, lets wait and see what they say.

Sounds good.

Cheers,
Sachi

__
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-infra][nodepool] Can the nodes created by nodepool be reused by jenkins jobs?

[王华]

Hi Paul,

There is a period between a job is done in Jenkins and the node is deleted
by nodepool.
Before the node is deleted, the node can be seen on Jenkins.How can Jenkins
know not
to use the node which has already run a job? Is there a mechanism to
 ensure this case?

On Thu, Jun 30, 2016 at 11:12 AM, Paul Belanger 
wrote:

> On Thu, Jun 30, 2016 at 10:49:41AM +0800, 王华 wrote:
> > Hi all,
> >
> > In OpenStack infra system after a job in Jenkins has finalized, Jenkins
> > send a message called onFinalized to  nodepool to delete the node. I
> have a
> > question. Between the time the job is done and
> > the node is deleted by nodepool, will the node be reused by other jobs in
> > jenkins? All nodes created by nodepool only run a jenkins job and then be
> > deleted? Can we let some jenkins jobs like pep8 to reuse the nodes?
> >
> Yes, it is possible. We have a setting in nodepool called
> OFFLINE_NODE_WHEN_COMPLETE[1]. When this parameter is not set, jenkins will
> be allow to reused the nodes created by nodepool.
>
> It is possible to reused nodes for pep8 jobs only, it is a configuration
> change
> to zuul.
>
> But we don't wan to do this in openstack-infra, because we want new nodes
> for
> each job.
>
> [1]
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/openstack_functions.py#n34
>
> > Best Regards,
> > Wanghua
>
> >
> __
> > 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] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors

[Kosnik, Lubosz]

Like Doug said Amphora suppose to be a black box. It suppose to get some data - 
like info in /etc/defaults and do everything inside on its own.
Everyone will be able to prepare his own implementation of this image without 
mixing things between each other.

Lubosz Kosnik
Cloud Software Engineer OSIC
lubosz.kos...@intel.com

On Jun 29, 2016, at 3:17 PM, Gregory Haynes 
> wrote:

On Wed, Jun 29, 2016, at 02:18 PM, Nir Magnezi wrote:
Hi Greg,

Thanks for the replay, comments inline.

On Wed, Jun 29, 2016 at 9:59 PM, Gregory Haynes 
> wrote:

On Wed, Jun 29, 2016, at 10:26 AM, Nir Magnezi wrote:
Hello,

Lately, I've been working on a fix[1] for the amhpora-agent, which currently 
only support Debian based flavors such as Ubuntu.

The main Issues here:
1. NIC hot plugs: Ubuntu's ethX.cfg files looks different from ifcfg-ethX files 
which are accepted in Linux flavors such a RHEL, CentOS and Fedora, read more 
in the fix commit msg.
2. The usage of Flavor specific features such as 'upstart'.

I would like to have a discussion about the second bullet mentioned above.
Due to the fact that in Octavia the loadbalancer runs inside of an instance 
(Amphora), There are few actions that need to take place in the Amphora 
instance boot process:
a. namespace and NIC created.
b. amphora agent starts
c. haproxy (and possibly keepalived) start

The Amphora-agent leverages[2] the capabilities of 'upstart' to make that 
happen, which is a bit problematic if we wish it to work on other flavors.
The default cloud image for Amphora today is Ubuntu, yet there are few more 
options[3] such as CentOS and Fedora.
Unlike the Ubuntu base image, which uses 'sysvinit', The latter two flavors use 
'systemd'.
This creates incompatibility with the jinja2[4][5] templates used by the agent.

The way I see it there are two possible solutions for this:
1. Include a systemd equivalent in the fix[1] that will essentially duplicate 
the functionality mentioned above and work in the other flavors.
2. Have a the amphora agent be the only binary that needs to be configured to 
start upon boot, and that agent will take care of plugging namespaces and NICs 
and also spawning needs processes. This is how it is done in lbaas and l3 
agents.

While the latter solution looks like a more "clean" design, the trade-off here 
is a bigger change to the amphora agent.

[1] https://review.openstack.org/#/c/331841/
[2] 
https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/listener.py#L128
[3] 
https://github.com/openstack/octavia/blob/master/diskimage-create/diskimage-create.sh#L27
[4] 
https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/upstart.conf.j2
[5] 
https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/sysvinit.conf.j2


Thanks,
Nir

I have an alternative suggestion - Maybe we shouldn't be templating out the 
init scripts? What we are effectively doing here is code-gen which leads to 
problems exactly like this, and fixing it with more code gen actually makes the 
problem more difficult.

The incompatibility to systemd is not due to usage of templates and code 
generated files is a nice and useful tool to have.

Sure, its not a direct result, but it just shouldn't be necessary here and it 
makes this problem far more complicated than it needs to be. If we weren't 
using templating then supporting non-upstart would be as easy as creating a 
trivial init script and including it in the amphora element (which only requies 
copying a file in to that element, done.).


I see two fairly straightforward ways to not require this templating:

1) Use the agent to write out config for the init scripts in to 
/etc/defaults/amphora and have the init scripts consume that file (source 
variables in that file). The init script can then simply be a static file which 
we can even bake in to the image directly.

systemd does not use init script, which is why the current code is incompatible 
to the distros i mentioned.

Right, what I am saying is to separate out configuration from the 
init/upstart/systemd files and if necessary source that configuration. This is 
how init/upstart/systemd scripts are written for almost every application for a 
reason and why ubuntu has /etc/defaults and why systemd has things like 
EnvironmentFile. It sounds like the second option is what were leaning towards 
though, in which case this isn't needed.



2) Move the code which requires the templating in to another executable which 
the init scripts call out to. e.g. create a amphora-net-init executable that 
runs the same code as in the pre-up section of the upstart script. Then there 
is no need for templating in the init scripts themselves (they will all simply 
call the same executable) and we can also do something like bake 

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

[Edward Leafe]

On Jun 29, 2016, at 10:05 PM, Matt Riedemann  wrote:
> 
>>> 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.
> 
> As discussed in the API meeting this morning, I thought it would be odd to 
> set updated_at = created_at when the record is created.

It's really very common. Think of 'updated_at' as meaning 'the last time this 
record was modified'. For a new record, the initial creation is also the last 
time it was modified.

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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-infra][nodepool] Can the nodes created by nodepool be reused by jenkins jobs?

[Paul Belanger]

On Thu, Jun 30, 2016 at 10:49:41AM +0800, 王华 wrote:
> Hi all,
> 
> In OpenStack infra system after a job in Jenkins has finalized, Jenkins
> send a message called onFinalized to  nodepool to delete the node. I have a
> question. Between the time the job is done and
> the node is deleted by nodepool, will the node be reused by other jobs in
> jenkins? All nodes created by nodepool only run a jenkins job and then be
> deleted? Can we let some jenkins jobs like pep8 to reuse the nodes?
> 
Yes, it is possible. We have a setting in nodepool called
OFFLINE_NODE_WHEN_COMPLETE[1]. When this parameter is not set, jenkins will
be allow to reused the nodes created by nodepool.

It is possible to reused nodes for pep8 jobs only, it is a configuration change
to zuul.

But we don't wan to do this in openstack-infra, because we want new nodes for
each job.

[1] 
http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/openstack_functions.py#n34

> Best Regards,
> Wanghua

> __
> 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] [Nova] Questions about instance actions' update and finish

[Matt Riedemann]

On 6/29/2016 10:10 PM, Matt Riedemann wrote:

On 6/29/2016 6:40 AM, Andrew Laski wrote:




On Tue, Jun 28, 2016, at 09:27 PM, Zhenyu Zheng wrote:

How about I sync updated_at and created_at in my patch, and leave the
finish to the other BP, by this way, I can use updated_at for the
timestamp filter I added and it don't need to change again once the
finish BP is complete.


Sounds good to me.



It's been a long day so my memory might be fried, but the options we
talked about in the API meeting were:

1. Setting updated_at = created_at when the instance action record is
created. Laski likes this, I'm not crazy about it, especially since we
don't do that for anything else.

2. Update the instance action's updated_at when instance action events
are created. I like this since the instance action is like a parent
resource and the event is the child, so when we create/modify an event
we can consider it an update to the parent. Laski thought this might be
weird UX given we don't expose instance action events in the REST API
unless you're an admin. This is also probably not something we'd do for
other related resources like server groups and server group members (but
we don't page on those either right now).

3. Order the results by updated_at,created_at so that if updated_at
isn't set for older records, created_at will be used. I think we all
agreed in the meeting to do this regardless of #1 or #2 above.



Oh and

#4. Sean Dague needs to come back from leadership training camp in 
Michigan and make these kind of API decisions for us.


--

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] [Nova] Questions about instance actions' update and finish

[Matt Riedemann]

On 6/29/2016 6:40 AM, Andrew Laski wrote:




On Tue, Jun 28, 2016, at 09:27 PM, Zhenyu Zheng wrote:

How about I sync updated_at and created_at in my patch, and leave the
finish to the other BP, by this way, I can use updated_at for the
timestamp filter I added and it don't need to change again once the
finish BP is complete.


Sounds good to me.



It's been a long day so my memory might be fried, but the options we 
talked about in the API meeting were:


1. Setting updated_at = created_at when the instance action record is 
created. Laski likes this, I'm not crazy about it, especially since we 
don't do that for anything else.


2. Update the instance action's updated_at when instance action events 
are created. I like this since the instance action is like a parent 
resource and the event is the child, so when we create/modify an event 
we can consider it an update to the parent. Laski thought this might be 
weird UX given we don't expose instance action events in the REST API 
unless you're an admin. This is also probably not something we'd do for 
other related resources like server groups and server group members (but 
we don't page on those either right now).


3. Order the results by updated_at,created_at so that if updated_at 
isn't set for older records, created_at will be used. I think we all 
agreed in the meeting to do this regardless of #1 or #2 above.


--

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] [Nova] Questions about instance actions' update and finish

[Matt Riedemann]

On 6/28/2016 7:28 AM, Andrew Laski wrote:




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.


As discussed in the API meeting this morning, I thought it would be odd 
to set updated_at = created_at when the record is created.






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




--

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

[openstack-dev] [openstack-infra][nodepool] Can the nodes created by nodepool be reused by jenkins jobs?

[王华]

Hi all,

In OpenStack infra system after a job in Jenkins has finalized, Jenkins
send a message called onFinalized to  nodepool to delete the node. I have a
question. Between the time the job is done and
the node is deleted by nodepool, will the node be reused by other jobs in
jenkins? All nodes created by nodepool only run a jenkins job and then be
deleted? Can we let some jenkins jobs like pep8 to reuse the nodes?

Best Regards,
Wanghua
__
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] Continued support of Fedora as a base platform

[Gerard Braad]

Hi,


Kolla has supported Fedora AFAIK since the project started, and offers
several other valid options:

  # Valid options are [ centos, fedora, oraclelinux, ubuntu ]
  #kolla_base_distro: "centos"

but in recent time, it came to my attention that the support of Fedora
is lacking. There could be several reasons for this;

  1. interest
  2. lack of resources
  3. life cycle

Firstly, might this be related to the fact that deploying on Fedora is
not of interest to most? The majority of deployments of OpenStack
happen on either Ubuntu or RHEL/CentOS. However, supporting Fedora
early can help the deliverance on future version of RHEL/CentOS
(although, there can be years in between before this happens). It is
therefore still of importance.

Second, and this is probably more likely the case. The Kolla project
lacks the resources to maintain releasing on Fedora. Especially, since
Fedora carries newer versions of software, there is a tendency of
breakage. Automated tests is because of this of high importance.

Third, since Fedora does not have a concept of Long-term releases, the
release is only supported for a period of approximately 13 months.
This is detailed in the Release Life Cycle [1] and EOL status page
[2]. This means that after a release, like currently F24, the previous
version like F22 will be phased out.

A recent bugreport [3] about the image availability got resolved by
implementing F22 (which would have been phased out just a month or two
from now). The suggestion was to use CentOS for this. Maybe in this
case it was... but should we?

The question is not "Do we want to support Fedora?", but "Can we
support Fedora?. If my time allows, I will certainly work on making
this happen. But before, it might be needed to collect some of the
feedback what has been done, what needs to be done... and what is
currently the impediment of making it happen, like issues with
versions of the dependencies.

Would like to hear your thoughts...

regards,


Gerard

[1]  https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
[2]  https://fedoraproject.org/wiki/End_of_life
[3]  https://bugs.launchpad.net/kolla/+bug/1589770

-- 

   Gerard Braad | http://gbraad.nl
   [ Doing Open Source Matters ]

__
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] [octavia][upgrades] upgrade loadbalancer to new amphora image

[Brandon Logan]

Hi Ihar, thanks for starting this discussion.  Comments in-line.

After writing my comments in line, I might now realize that you're just
talking about documenting  a way for a user to do this, and not have
Octavia handle it at all.  If that's the case I apologize for my reading
comprehension, but I'll keep my comments in case I'm wrong.  My brain is
not working well today, sorry :(

Thanks,
Brandon

On Wed, 2016-06-29 at 18:14 +0200, Ihar Hrachyshka wrote:
> Hi all,
> 
> I was looking lately at upgrades for octavia images. This includes using new 
> images for new loadbalancers, as well as for existing balancers.
> 
> For the first problem, the amp_image_tag option that I added in Mitaka seems 
> to do the job: all new balancers are created with the latest image that is 
> tagged properly.
> 
> As for balancers that already exist, the only way to get them use a new image 
> is to trigger an instance failure, that should rebuild failed nova instance, 
> using the new image. AFAIU the failover process is not currently automated, 
> requiring from the user to set the corresponding port to DOWN and waiting for 
> failover to be detected. I’ve heard there are plans to introduce a specific 
> command to trigger a quick-failover, that would streamline the process and 
> reduce the time needed for the process because the failover would be 
> immediately detected and processed instead of waiting for keepalived failure 
> mode to occur. Is it on the horizon? Patches to review?

Not that I know of and with all the work slated for Newton, I'm 99% sure
it won't be done in Newton.  Perhaps Ocata.
> 
> While the approach seems rather promising and may be applicable for some 
> environments, I have several concerns about the failover approach that we may 
> want to address.
> 
> 1. HA assumption. The approach assumes there is another node running 
> available to serve requests while instance is rebuilding. For non-HA 
> amphoras, it’s not the case, meaning the image upgrade process has a 
> significant downtime.
> 
> 2. Even if we have HA, for the time of instance rebuilding, the balancer 
> cluster is degraded to a single node.
> 
> 3. (minor) during the upgrade phase, instances that belong to the same HA 
> amphora may run different versions of the image.
> 
> What’s the alternative?
> 
> One idea I was running with for some time is moving the upgrade complexity 
> one level up. Instead of making Octavia aware of upgrade intricacies, allow 
> it to do its job (load balance), while use neutron floating IP resource to 
> flip a switch from an old image to a new one. Let me elaborate.
I'm not sure I like the idea of tying this to floating IP as there are
deployers who do not use floating IPs.  Then again, we are currently
depending on allowed address pairs which is also an extension, but I
suspect its probably deployed in more places.  I have no proof of this
though.
> 
> Let’s say we have a load balancer LB1 that is running Image1. In this 
> scenario, we assume that access to LB1 VIP is proxied through a floating ip 
> FIP that points to LB1 VIP. Now, the operator uploaded a new Image2 to glance 
> registry and tagged it for octavia usage. The user now wants to migrate the 
> load balancer function to using the new image. To achieve this, the user 
> follows the steps:
> 
> 1. create an independent clone of LB1 (let’s call it LB2) that has exact same 
> attributes (members) as LB1.
> 2. once LB2 is up and ready to process requests incoming to its VIP, redirect 
> FIP to the LB2 VIP.
> 3. now all new flows are immediately redirected to LB2 VIP, no downtime (for 
> new flows) due to atomic nature of FIP update on the backend (we use 
> iptables-save/iptables-restore to update FIP rules on the router).
Will this sever any existing connections? Is there a way to drain
connections? Or is that already done?
> 4. since LB1 is no longer handling any flows, we can deprovision it. LB2 is 
> now the only balancer handling members.
> 
> With that approach, 1) we provide for consistent downtime expectations 
> irrelevant to amphora architecture chosen (HA or not); 2) we flip the switch 
> when the clone is up and ready, so no degraded state for the balancer 
> function; 3) all instances in an HA amphora run the same image.
> 
> Of course, it won’t provide no downtime for existing flows that may already 
> be handled by the balancer function. That’s a limitation that I believe is 
> shared by all approaches currently at the table.
> 
> As a side note, the approach would work for other lbaas drivers, like 
> namespaces, f.e. in case we want to update haproxy.
> 
> Several questions in regards to the topic:
> 
> 1. are there any drawbacks with the approach? can we consider it an 
> alternative way of doing image upgrades that could find its way into official 
> documentation?

Echoing my comment above of being tightly coupled with floating IPs is a
draw back.

Another way would be to make use of the allowed address pairs:
1) spin up a 

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

[Lingxian Kong]

+1 to the mistral-tornado.png logo, looks amazing! Thanks!

Regards!
---
Lingxian Kong


On Tue, Jun 28, 2016 at 5:38 PM, 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.
>
> 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
>

__
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] [app-catalog] App Catalog IRC meeting Thursday June 30th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for June 30th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Tomorrow we expect to talk in some detail about our next steps with
implement GLARE as a back-end for the Community App Catalog.
(Mirantis has thrown several resources at making this happen, thanks!)

Hope to see you there tomorrow!

__
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] [security] [horizon] Security implications of exposing a keystone token to a JS client

[Fox, Kevin M]

Ah. I was going to bring this up eventually but hadn't gotten to it yet.

I started up a patch for adding similar support for horizon here:
https://review.openstack.org/#/c/311189/

My intention is to use it to make a Horizon Plugin to speak to a Keystone 
authenticated Kubernetes api directly.

Thanks,
Kevin


From: Timur Sufiev [tsuf...@mirantis.com]
Sent: Wednesday, June 29, 2016 2:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [security] [horizon] Security implications of exposing 
a keystone token to a JS client

Hello, vigilant folks of OpenStack Security team!

The commit(s) I'd like you to take a look at introduces a new Horizon feature, 
Create (Glance) Image using CORS (AKA Cross-Origin Resource Sharing) [1].

The main idea is to bypass Horizon web-server when uploading large local image 
and to send it directly to Glance server, thus saving network bandwidth and 
disk space on the controller node where Horizon web-server is deployed. However 
there is one possible security trade-off I had to make so that Glance service 
would allow me to upload an image - I'm passing the Keystone token to the 
Horizon JS runtime [2], and then pass it to Glance service [3] or [4] 
(different links here correspond to different versions of new Create Image - 
Django and Angular). This trade-off made Horizon community somewhat hesitant if 
we should push these changes forward, but nobody yet voiced a viable 
alternative, so here I'm writing this letter to you.

The usual Horizon workflow for working with Keystone tokens is the following: 
retrieve scoped token and put it into web-server session, which is itself not 
exposed to browser (unless SESSION_STORAGE signed_cookies backend was chosen, 
but even in that case session contents are encrypted in some way), but is kept 
on web-server and referenced using the session key which is kept in browser 
cookies - so one may say that in existing setup keystone token never leaks to 
browser.

On the other hand, in some not so far (I hope) future, when more logic is moved 
to client-side UI (i.e. browser), the issue of browser authenticating to some 
OpenStack services directly would become more widespread, it just happened that 
this work on Create Image in Horizon is pioneering this area (AFAIK). So, what 
do you think of possible security implications of this setup?

Just for the reference, three patches mentioned in [1-3] implement most of the 
logic of new Create Image feature.

[1] 
https://blueprints.launchpad.net/horizon/+spec/horizon-glance-large-image-upload
[2] 
https://review.openstack.org/#/c/317365/15/openstack_dashboard/api/glance.py@215
[3] 
https://review.openstack.org/#/c/230434/37/horizon/static/horizon/js/horizon.modals.js@212
[4] 
https://review.openstack.org/#/c/317456/16/openstack_dashboard/static/app/core/openstack-service-api/glance.service.js@151
__
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][Neutron][Live-Migration] Cross l2 agent migration and solving Nova-Neutron live migration bugs

[Carl Baldwin]

On Tue, Jun 28, 2016 at 9:42 AM, Andreas Scheuring
 wrote:
> 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.

Thanks for sending this.

> 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)

Since all of these issues are experienced when using live migration, a
Nova feature, I was interested in finding out how Nova prioritizes
getting a fix and then trying to align Neutron's priority to that
priority.  It would seem artificial to me to drive priority from
Neutron.  That's why I mentioned it.  Since Nova is hitting a freeze
for non-priority work tomorrow, I don't think anything can be done for
Newton.  However, there is a lot of time to tee up this conversation
for Ocata if we get on it.

> 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].

I'll be there.

> 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

__
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] [security] [horizon] Security implications of exposing a keystone token to a JS client

[Timur Sufiev]

Hello, vigilant folks of OpenStack Security team!

The commit(s) I'd like you to take a look at introduces a new Horizon
feature, Create (Glance) Image using CORS (AKA Cross-Origin Resource
Sharing) [1].

The main idea is to bypass Horizon web-server when uploading large local
image and to send it directly to Glance server, thus saving network
bandwidth and disk space on the controller node where Horizon web-server is
deployed. However there is one possible security trade-off I had to make so
that Glance service would allow me to upload an image - I'm passing the
Keystone token to the Horizon JS runtime [2], and then pass it to Glance
service [3] or [4] (different links here correspond to different versions
of new Create Image - Django and Angular). This trade-off made Horizon
community somewhat hesitant if we should push these changes forward, but
nobody yet voiced a viable alternative, so here I'm writing this letter to
you.

The usual Horizon workflow for working with Keystone tokens is the
following: retrieve scoped token and put it into web-server session, which
is itself not exposed to browser (unless SESSION_STORAGE signed_cookies
backend was chosen, but even in that case session contents are encrypted in
some way), but is kept on web-server and referenced using the session key
which is kept in browser cookies - so one may say that in existing setup
keystone token never leaks to browser.

On the other hand, in some not so far (I hope) future, when more logic is
moved to client-side UI (i.e. browser), the issue of browser authenticating
to some OpenStack services directly would become more widespread, it just
happened that this work on Create Image in Horizon is pioneering this area
(AFAIK). So, what do you think of possible security implications of this
setup?

Just for the reference, three patches mentioned in [1-3] implement most of
the logic of new Create Image feature.

[1]
https://blueprints.launchpad.net/horizon/+spec/horizon-glance-large-image-upload
[2]
https://review.openstack.org/#/c/317365/15/openstack_dashboard/api/glance.py@215
[3]
https://review.openstack.org/#/c/230434/37/horizon/static/horizon/js/horizon.modals.js@212
[4]
https://review.openstack.org/#/c/317456/16/openstack_dashboard/static/app/core/openstack-service-api/glance.service.js@151
__
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] [craton] Developer weekly meeting scheduled every Thursday at 2100 UTC

[Jim Baker]

On Wed, Jun 29, 2016 at 2:59 PM, Ian Cordasco 
wrote:

> -Original Message-
> From: Jim Baker 
> Reply: OpenStack Development Mailing List (not for usage questions)
> 
> Date: June 29, 2016 at 14:08:25
> To: OpenStack Development Mailing List 
> Subject:  [openstack-dev] [craton] Developer weekly meeting scheduled
> every Thursday at 2100 UTC
>
> > Please join us for our weekly developer video conference call about
> Craton
> > development every Thursday at 2100 UTC.
> >
> > We meet on Vidyo; please use this link:
> >
> https://vc.rackspace.com/flex.html?roomdirect.html=OpmgbcmKWcXB31Tbl7VHgTrytb0
> >
> > Meetings will be recorded and posted to YouTube, so if you do not wish to
> > be recorded, please do not attend the meeting. The agenda can be found at
> > https://etherpad.openstack.org/p/craton-meetings, but most often we will
> > use a standing agenda: to discuss open development issues.
> >
> > - Jim
>
> Is this replacing the weekly Monday IRC meetings?
>

Good question!

No, this video conference call will not replace our weekly IRC meeting on
#openstack-meeting-4.

Instead, these two meetings will hopefully complement each other:

   - Monday's IRC meeting on #openstack-meeting-4 will set overall
   direction for Craton, including interaction with stakeholders and
   determining action items. Agendas will be published (
   https://etherpad.openstack.org/p/craton-meetings), and minutes recorded
   with meetbot and published on eavesdrop.
   - Thursday's Vidyo call will focus on development issues. We will record
   this call, and I'm sure notes will be taken in relevant etherpads, but it
   will be much more informal because we are simply trying to help each other
   make progress on our issues. Think standup, brainstorming, etc.


I'm sure these weekly meetings will evolve over time, and I welcome all
input on how to make them as effective as possible.

- Jim
__
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] [craton] Developer weekly meeting scheduled every Thursday at 2100 UTC

[Ian Cordasco]

-Original Message-
From: Jim Baker 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: June 29, 2016 at 14:08:25
To: OpenStack Development Mailing List 
Subject:  [openstack-dev] [craton] Developer weekly meeting scheduled
every Thursday at 2100 UTC

> Please join us for our weekly developer video conference call about Craton
> development every Thursday at 2100 UTC.
>
> We meet on Vidyo; please use this link:
> https://vc.rackspace.com/flex.html?roomdirect.html=OpmgbcmKWcXB31Tbl7VHgTrytb0
>
> Meetings will be recorded and posted to YouTube, so if you do not wish to
> be recorded, please do not attend the meeting. The agenda can be found at
> https://etherpad.openstack.org/p/craton-meetings, but most often we will
> use a standing agenda: to discuss open development issues.
>
> - Jim

Is this replacing the weekly Monday IRC meetings?

--
Ian Cordasco

__
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] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors

[Gregory Haynes]

On Wed, Jun 29, 2016, at 02:18 PM, Nir Magnezi wrote:
> Hi Greg,
>
> Thanks for the replay, comments inline.
>
> On Wed, Jun 29, 2016 at 9:59 PM, Gregory Haynes
>  wrote:
>> __
>> On Wed, Jun 29, 2016, at 10:26 AM, Nir Magnezi wrote:
>>> Hello,
>>>
>>> Lately, I've been working on a fix[1] for the amhpora-agent, which
>>> currently only support Debian based flavors such as Ubuntu.
>>>
>>> The main Issues here:
>>> 1. NIC hot plugs: Ubuntu's ethX.cfg files looks different from ifcfg-
>>>ethX files which are accepted in Linux flavors such a RHEL,
>>>CentOS and Fedora, read more in the fix commit msg.
>>> 2. The usage of Flavor specific features such as 'upstart'.
>>>
>>> I would like to have a discussion about the second bullet mentioned
>>> above.
>>> Due to the fact that in Octavia the loadbalancer runs inside of an
>>> instance (Amphora), There are few actions that need to take place in
>>> the Amphora instance boot process:
>>> a. namespace and NIC created.
>>> b. amphora agent starts
>>> c. haproxy (and possibly keepalived) start
>>>
>>> The Amphora-agent leverages[2] the capabilities of 'upstart' to make
>>> that happen, which is a bit problematic if we wish it to work on
>>> other flavors.
>>> The default cloud image for Amphora today is Ubuntu, yet there are
>>> few more options[3] such as CentOS and Fedora.
>>> Unlike the Ubuntu base image, which uses 'sysvinit', The latter two
>>> flavors use 'systemd'.
>>> This creates incompatibility with the jinja2[4][5] templates used by
>>> the agent.
>>>
>>> The way I see it there are two possible solutions for this:
>>> 1. Include a systemd equivalent in the fix[1] that will essentially
>>>duplicate the functionality mentioned above and work in the other
>>>flavors.
>>> 2. Have a the amphora agent be the only binary that needs to be
>>>configured to start upon boot, and that agent will take care of
>>>plugging namespaces and NICs and also spawning needs processes.
>>>This is how it is done in lbaas and l3 agents.
>>>
>>> While the latter solution looks like a more "clean" design, the trade-
>>> off here is a bigger change to the amphora agent.
>>>
>>> [1] https://review.openstack.org/#/c/331841/
>>> [2] 
>>> https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/listener.py#L128
>>> [3]https://github.com/openstack/octavia/blob/master/diskimage-create/diskimage-create.sh#L27
>>> [4]https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/upstart.conf.j2
>>> [5]https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/sysvinit.conf.j2
>>>
>>>
>>> Thanks,
>>> Nir
>>
>> I have an alternative suggestion - Maybe we shouldn't be templating
>> out the init scripts? What we are effectively doing here is code-gen
>> which leads to problems exactly like this, and fixing it with more
>> code gen actually makes the problem more difficult.
>>
> The incompatibility to systemd is not due to usage of templates and
> code generated files is a nice and useful tool to have.
 
Sure, its not a direct result, but it just shouldn't be necessary here
and it makes this problem far more complicated than it needs to be. If
we weren't using templating then supporting non-upstart would be as easy
as creating a trivial init script and including it in the amphora
element (which only requies copying a file in to that element, done.).
 
>
>> I see two fairly straightforward ways to not require this templating:
>>
>> 1) Use the agent to write out config for the init scripts in to
>>/etc/defaults/amphora and have the init scripts consume that file
>>(source variables in that file). The init script can then simply
>>be a static file which we can even bake in to the image directly.
>
> systemd does not use init script, which is why the current code is
> incompatible to the distros i mentioned.
 
Right, what I am saying is to separate out configuration from the
init/upstart/systemd files and if necessary source that
configuration. This is how init/upstart/systemd scripts are written
for almost every application for a reason and why ubuntu has
/etc/defaults and why systemd has things like EnvironmentFile. It
sounds like the second option is what were leaning towards though, in
which case this isn't needed.
 
>>
>>
>> 2) Move the code which requires the templating in to another
>>executable which the init scripts call out to. e.g. create a amphora-net-
>>init executable that runs the same code as in the pre-up section
>>of the upstart script. Then there is no need for templating in the
>>init scripts themselves (they will all simply call the same
>>executable) and we can also do something like bake init scripts
>>directly in to the image.
>
> I'm not sure I follow you here. but anyhow we cannot just give up the
> templates. how would you handle the parameters currently passed to
> those 

Re: [openstack-dev] [swift] Support for unicode filename in tempurl middleware

[Antonio Calanducci]

Hi Tim,

thank you. I have modified my local python swift client according the diff
on your patch and now I can generate tempURL on python2.7 too.

I have noticed a bizzarre thing now. Trying to use CURL to download the
generated tempURL, using a utf8 filename ("Monè.txt"), the download works
fine if I copy and paste the filename from "swift list" output, but if I
type the filename with my keyboard, it doesn't work anymore. Same "è"
character, not sure why. Maybe the key I type on the keyboard has a
different encoding than the one from the "swift list" output?

I have also a second question, related to filename that contains spaces. I
should not need to URL encode (with %20) the path to generate the tempURL,
but I should encode when doing the actual upload, correct?

Actually the code that generates the tempURL is a Node.js script written in
JavaScript. Probably I am not doing correctly the encodings (as far as I
know I should not encode anything in Node.js because of the native
support). Do you have any JS sample code for tempURL generation or any
hints I should follow to properly generate the tempURL?

thank you in advance
Best
Antonio








On Wed, Jun 29, 2016 at 8:27 PM, Tim Burke  wrote:

> Hi Antonio,
>
> That sounds like a bug! Looks like we decode the temporal key coming in
> from the terminal, but don't properly encode it when getting the HMAC. This
> generates the UnicodeEncodeError on python 2.7, and I've submitted
> https://review.openstack.org/#/c/335615/ to address this.
>
> I'm not sure about what's going on with the temporal generated on python
> 3, though. FWIW, I'll often forget whether it's supposed to be
> X-Container-Meta-Temp-Url-Key or X-Container-Meta-Tempurl-Key. (For
> reference, use the first one.) Maybe that's the issue?
>
> Tim
>
> > On Jun 29, 2016, at 10:06 AM, Dr Antonio Calanducci <
> antonio.calandu...@ct.infn.it> wrote:
> >
> > Hi,
> >
> > I hope this is the right mailing list to ask this question. In case it's
> not, please direct me to the right one and apologise.
> >
> > I have some files stored in a container the use german character (and in
> general non ascii character).
> > Using the swift REST APIs and python-swiftclient (3.0.0) download/upload
> command I have no problem to handle them.
> >
> > But when I try to generate tempurl for some of them with
> python-swiftclient, I got errors if I use python 2.7. By the way, switching
> to python3 I can generate properly the tempurl, but the URL is actually not
> working generating a 401 error.
> >
> > Looking at the github repo it seems there is utf8 support for the
> tempurl key, but I am not sure if you support unicode for path too. I am
> currently using swift 2.2.0 on the server.
> >
> > I read in the docs that I should not encode the path while generating
> the tempurl, but only to actually retrieve from the generate url.
> >
> > Could you confirm or not that filename with unicode chars are supported
> and if so in which version?
> >
> > thanks a lot for the attention
> > All the best
> > Antonio
> >
> > --
> >
> > Dr. Antonio Calanducci, PhD
> > INFN Catania
> >
> > Office:+39 095 3785519
> > Mobile:  +39 349 6762534
> > Skype:   tcaland
> >
> > antonio.calandu...@ct.infn.it
> > calandu...@unict.it
> >
> >
> >
> >
> >
> >
> >
> __
> > 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
>



-- 
Dr. *Antonio Calanducci*, PhD
INFN Catania
Dipartimento di Fisica e Astronomia - Università di Catania
*Via Santa Sofia, 64*
*95128 Catania (IT)*

O : +39 095 378 5519
M:  +39 349 6762534
Skype: tcaland
__
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] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors

[Nir Magnezi]

Hi Greg,

Thanks for the replay, comments inline.

On Wed, Jun 29, 2016 at 9:59 PM, Gregory Haynes  wrote:

> On Wed, Jun 29, 2016, at 10:26 AM, Nir Magnezi wrote:
>
> Hello,
>
> Lately, I've been working on a fix[1] for the amhpora-agent, which
> currently only support Debian based flavors such as Ubuntu.
>
> The main Issues here:
> 1. NIC hot plugs: Ubuntu's ethX.cfg files looks different from ifcfg-ethX
> files which are accepted in Linux flavors such a RHEL, CentOS and Fedora,
> read more in the fix commit msg.
> 2. The usage of Flavor specific features such as 'upstart'.
>
> I would like to have a discussion about the second bullet mentioned above.
> Due to the fact that in Octavia the loadbalancer runs inside of an
> instance (Amphora), There are few actions that need to take place in the
> Amphora instance boot process:
> a. namespace and NIC created.
> b. amphora agent starts
> c. haproxy (and possibly keepalived) start
>
> The Amphora-agent leverages[2] the capabilities of 'upstart' to make that
> happen, which is a bit problematic if we wish it to work on other flavors.
> The default cloud image for Amphora today is Ubuntu, yet there are few
> more options[3] such as CentOS and Fedora.
> Unlike the Ubuntu base image, which uses 'sysvinit', The latter two
> flavors use 'systemd'.
> This creates incompatibility with the jinja2[4][5] templates used by the
> agent.
>
> The way I see it there are two possible solutions for this:
> 1. Include a systemd equivalent in the fix[1] that will essentially
> duplicate the functionality mentioned above and work in the other flavors.
> 2. Have a the amphora agent be the only binary that needs to be configured
> to start upon boot, and that agent will take care of plugging namespaces
> and NICs and also spawning needs processes. This is how it is done in lbaas
> and l3 agents.
>
> While the latter solution looks like a more "clean" design, the trade-off
> here is a bigger change to the amphora agent.
>
> [1] https://review.openstack.org/#/c/331841/
> [2]
> https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/listener.py#L128
> [3]
> https://github.com/openstack/octavia/blob/master/diskimage-create/diskimage-create.sh#L27
> [4]
> https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/upstart.conf.j2
> [5]
> https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/sysvinit.conf.j2
>
>
> Thanks,
> Nir
>
>
> I have an alternative suggestion - Maybe we shouldn't be templating out
> the init scripts? What we are effectively doing here is code-gen which
> leads to problems exactly like this, and fixing it with more code gen
> actually makes the problem more difficult.
>
>
The incompatibility to systemd is not due to usage of templates and code
generated files is a nice and useful tool to have.


> I see two fairly straightforward ways to not require this templating:
>
> 1) Use the agent to write out config for the init scripts in to
> /etc/defaults/amphora and have the init scripts consume that file (source
> variables in that file). The init script can then simply be a static file
> which we can even bake in to the image directly.
>

systemd does not use init script, which is why the current code is
incompatible to the distros i mentioned.

>
> 2) Move the code which requires the templating in to another executable
> which the init scripts call out to. e.g. create a amphora-net-init
> executable that runs the same code as in the pre-up section of the upstart
> script. Then there is no need for templating in the init scripts themselves
> (they will all simply call the same executable) and we can also do
> something like bake init scripts directly in to the image.
>

I'm not sure I follow you here. but anyhow we cannot just give up the
templates. how would you handle the parameters currently passed to those
templates? some if them you cannot know in advance and just hardcode.

>
>
> My thinking is that this is only going to get more complex - what are we
> going to do to support the new ubuntu LTS which is systemd based? Or if
> folk show up with other distros that match neither? Its a lot easier to
> decouple the init scripts, which are target specific, from configuration
> specific components and avoid this issues all together.
>

Well, there is a solution that I mentioned in my first mail. both neutron
LBaaS and L3 agents take care of everything needed as far as namespaces ,
nics and processes. that would leave you with a single binary to activate
upon boot.


>
> HTH,
> Greg
>
>
Nir

> __
> 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] [craton] Developer weekly meeting scheduled every Thursday at 2100 UTC

[Jim Baker]

Please join us for our weekly developer video conference call about Craton
development every Thursday at 2100 UTC.

We meet on Vidyo; please use this link:
https://vc.rackspace.com/flex.html?roomdirect.html=OpmgbcmKWcXB31Tbl7VHgTrytb0

Meetings will be recorded and posted to YouTube, so if you do not wish to
be recorded, please do not attend the meeting. The agenda can be found at
https://etherpad.openstack.org/p/craton-meetings, but most often we will
use a standing agenda: to discuss open development issues.

- Jim
__
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] Neutron-lib and Stadium evolution

[Armando M.]

Hi Neutrinos,

As some of you may have noticed, since the merge of [1] you have now +2
rights on neutron-lib changes. Please make yourself familiar with review
guidelines [2]: in general, code that targets the library should go through
a much greater level of scrutiny and should be targeted if and only if it
serves the purpose of reuse across the Stadium, and the decoupling of
Neutron from its consumer projects.

Please, also bear in mind that since [3] is in effect, I'll be working over
the next few days to implement some of the steps outlined in the plan, and
that involves consolidating APIs and move them over to neutron-lib. Akihiro
started the effort of moving the API documentation [4] over neutron-lib,
and we'll continue towards the consolidation effort.

Please become more involved, and consider neutron-lib as one of the
projects you take the time of reviewing on a day to day basis.

Cheers,
Armando

[1] https://review.openstack.org/#/c/335250/
[2] http://docs.openstack.org/developer/neutron-lib/review-guidelines.html
[3]
http://specs.openstack.org/openstack/neutron-specs/specs/newton/neutron-stadium.html
[4] http://developer.openstack.org/api-ref/networking/
__
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] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors

[Gregory Haynes]

On Wed, Jun 29, 2016, at 10:26 AM, Nir Magnezi wrote:
> Hello,
>
> Lately, I've been working on a fix[1] for the amhpora-agent, which
> currently only support Debian based flavors such as Ubuntu.
>
> The main Issues here:
> 1. NIC hot plugs: Ubuntu's ethX.cfg files looks different from ifcfg-
>ethX files which are accepted in Linux flavors such a RHEL, CentOS
>and Fedora, read more in the fix commit msg.
> 2. The usage of Flavor specific features such as 'upstart'.
>
> I would like to have a discussion about the second bullet
> mentioned above.
> Due to the fact that in Octavia the loadbalancer runs inside of an
> instance (Amphora), There are few actions that need to take place in
> the Amphora instance boot process:
> a. namespace and NIC created.
> b. amphora agent starts
> c. haproxy (and possibly keepalived) start
>
> The Amphora-agent leverages[2] the capabilities of 'upstart' to make
> that happen, which is a bit problematic if we wish it to work on other
> flavors.
> The default cloud image for Amphora today is Ubuntu, yet there are few
> more options[3] such as CentOS and Fedora.
> Unlike the Ubuntu base image, which uses 'sysvinit', The latter two
> flavors use 'systemd'.
> This creates incompatibility with the jinja2[4][5] templates used by
> the agent.
>
> The way I see it there are two possible solutions for this:
> 1. Include a systemd equivalent in the fix[1] that will essentially
>duplicate the functionality mentioned above and work in the other
>flavors.
> 2. Have a the amphora agent be the only binary that needs to be
>configured to start upon boot, and that agent will take care of
>plugging namespaces and NICs and also spawning needs processes.
>This is how it is done in lbaas and l3 agents.
>
> While the latter solution looks like a more "clean" design, the trade-
> off here is a bigger change to the amphora agent.
>
> [1] https://review.openstack.org/#/c/331841/
> [2] 
> https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/listener.py#L128
> [3]https://github.com/openstack/octavia/blob/master/diskimage-create/diskimage-create.sh#L27
> [4]https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/upstart.conf.j2
> [5]https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/sysvinit.conf.j2
>
>
> Thanks,
> Nir
 
I have an alternative suggestion - Maybe we shouldn't be templating out
the init scripts? What we are effectively doing here is code-gen which
leads to problems exactly like this, and fixing it with more code gen
actually makes the problem more difficult.
 
I see two fairly straightforward ways to not require this templating:
 
1) Use the agent to write out config for the init scripts in to
   /etc/defaults/amphora and have the init scripts consume that file
   (source variables in that file). The init script can then simply be a
   static file which we can even bake in to the image directly.
 
2) Move the code which requires the templating in to another executable
   which the init scripts call out to. e.g. create a amphora-net-init
   executable that runs the same code as in the pre-up section of the
   upstart script. Then there is no need for templating in the init
   scripts themselves (they will all simply call the same executable)
   and we can also do something like bake init scripts directly in to
   the image.
 
 
My thinking is that this is only going to get more complex - what are we
going to do to support the new ubuntu LTS which is systemd based? Or if
folk show up with other distros that match neither? Its a lot easier to
decouple the init scripts, which are target specific, from configuration
specific components and avoid this issues all together.
 
HTH,
Greg
__
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] [Neutron][networking-sfc] NO networking-sfc project IRC meetings on 6/23/2016 and 6/30/2016

[Cathy Zhang]

FYI. No networking-sfc project meeting this week due to some project members 
being either in Summit/Conference or on vacation,. We will resume our meeting 
next Thursday 7/7/2016.
I have updated the meeting page for discussion topics. Feel free to add more if 
you have any.

Thanks,
Cathy

From: Cathy Zhang
Sent: Tuesday, June 21, 2016 3:55 PM
To: 'Cathy Zhang'; 'OpenStack Development Mailing List (not for usage 
questions)'
Subject: [openstack-dev] [Neutron][networking-sfc] NO networking-sfc project 
IRC meetings on 6/23/2016 and 6/30/2016

Hi everyone,
Since some of the project members are either in Summit/Conference or on 
vacation, we will not have project meetings on 6/23/2016 and 6/30/2016.
Thanks,
Cathy
__
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] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

[Arkady_Kanevsky]

Chris,
If we add openstack config to refstack submission will that provide sufficient 
info for "interoperability" LOGO?
That includes version  of APIs for each service.
https://review.openstack.org/#/c/300057/

Thanks,
Arkady

-Original Message-
From: Chris Hoge [mailto:ch...@openstack.org]
Sent: Wednesday, June 22, 2016 1:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tempest][nova][defcore] Add option to disable 
some strict response checking for interop testing


> On Jun 22, 2016, at 11:24 AM, Sean Dague wrote:
>
> On 06/22/2016 01:59 PM, Chris Hoge wrote:
>>
>>> On Jun 20, 2016, at 5:10 AM, Sean Dague
>>> > wrote:
>>>
>>> On 06/14/2016 07:19 PM, Chris Hoge wrote:

> On Jun 14, 2016, at 3:59 PM, Edward Leafe
> > wrote:
>
> On Jun 14, 2016, at 5:50 PM, Matthew Treinish
> > wrote:
>
>> But, if we add another possible state on the defcore side like
>> conditional pass, warning, yellow, etc. (the name doesn't matter)
>> which is used to indicate that things on product X could only
>> pass when strict validation was disabled (and be clear about
>> where and why) then my concerns would be alleviated.
>> I just do
>> not want this to end up not being visible to end users trying to
>> evaluate interoperability of different clouds using the test
>> results.
>
> +1
>
> Don't fail them, but don't cover up their incompatibility, either.
> -- Ed Leafe

 That's not my proposal. My requirement is that vendors who want to
 do this state exactly which APIs are sending back additional data,
 and that this information be published.

 There are different levels of incompatibility. A response with
 additional data that can be safely ignored is different from a
 changed response that would cause a client to fail.
>>>
>>> It's actually not different. It's really not.
>>>
>>> This idea that it's safe to add response data is based on an
>>> assumption that software versions only move forward. If you have a
>>> single deploy of software, that's fine.
>>>
>>> However as noted, we've got production clouds on Juno <-> Mitaka in
>>> the wild. Which means if we want to support horizontal transfer
>>> between clouds, the user experienced timeline might be start on a
>>> Mitaka cloud, then try to move to Juno. So anything added from Juno
>>> -> Mitaka without signaling has exactly the same client breaking
>>> behavior as removing attributes.
>>>
>>> Which is why microversions are needed for attribute adds.
>>
>> I'd like to note that Nova v2.0 is still a supported API, which as
>> far as I understand allows for additional attributes and extensions.
>> That Tempest doesn't allow for disabling strict checking when using a
>> v2.0 endpoint is a problem.
>>
>> The reporting of v2.0 in the Marketplace (which is what we do right
>> now) is also a signal to a user that there may be vendor additions to
>> the API.
>>
>> DefCore doesn't disallow the use of a 2.0 endpoint as part of the
>> interoperability standard.
>
> This is a point of confusion.
>
> The API definition did not allow that. The implementation of the API
> stack did.

And downstream vendors took advantage of that. We may not like it, but it's a 
reality in the current ecosystem.

> In Liberty the v2.0 API is optionally provided by a different backend
> stack that doesn't support extensions.
> In Mitaka it is default v2.0 API on a non extensions backend In Newton
> the old backend is deleted.
>
> From Newton forward there is still a v2.0 API, but all the code hooks
> that provided facilities for extensions are gone.

It's really important that the current documentation reflect the code and 
intent of the dev team. As of writing this e-mail,

"* v2 (SUPPORTED) and v2 extensions (SUPPORTED) (Will be deprecated in the near 
future.)"[1]

Even with this being removed in Newton, DefCore still has to allow for it in 
every supported version.

-Chris

[1] http://docs.openstack.org/developer/nova/

> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
>  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] [swift] Support for unicode filename in tempurl middleware

[Tim Burke]

Hi Antonio,

That sounds like a bug! Looks like we decode the temporal key coming in from 
the terminal, but don't properly encode it when getting the HMAC. This 
generates the UnicodeEncodeError on python 2.7, and I've submitted 
https://review.openstack.org/#/c/335615/ to address this.

I'm not sure about what's going on with the temporal generated on python 3, 
though. FWIW, I'll often forget whether it's supposed to be 
X-Container-Meta-Temp-Url-Key or X-Container-Meta-Tempurl-Key. (For reference, 
use the first one.) Maybe that's the issue?

Tim

> On Jun 29, 2016, at 10:06 AM, Dr Antonio Calanducci 
>  wrote:
> 
> Hi,
> 
> I hope this is the right mailing list to ask this question. In case it's not, 
> please direct me to the right one and apologise. 
> 
> I have some files stored in a container the use german character (and in 
> general non ascii character).
> Using the swift REST APIs and python-swiftclient (3.0.0) download/upload 
> command I have no problem to handle them.
> 
> But when I try to generate tempurl for some of them with python-swiftclient, 
> I got errors if I use python 2.7. By the way, switching to python3 I can 
> generate properly the tempurl, but the URL is actually not working generating 
> a 401 error.
> 
> Looking at the github repo it seems there is utf8 support for the tempurl 
> key, but I am not sure if you support unicode for path too. I am currently 
> using swift 2.2.0 on the server.
> 
> I read in the docs that I should not encode the path while generating the 
> tempurl, but only to actually retrieve from the generate url.
> 
> Could you confirm or not that filename with unicode chars are supported and 
> if so in which version?
> 
> thanks a lot for the attention
> All the best
> Antonio
> 
> -- 
> 
> Dr. Antonio Calanducci, PhD
> INFN Catania 
> 
> Office:+39 095 3785519
> Mobile:  +39 349 6762534
> Skype:   tcaland
> 
> antonio.calandu...@ct.infn.it
> calandu...@unict.it
> 
> 
> 
> 
> 
> 
> __
> 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] UFCG OneView CI comments missing recheck command

[Jeremy Stanley]

On 2016-06-29 00:23:36 + (+), Villalovos, John L wrote:
[...]
> Hopefully there is some standard for 3rd Party CI to use.
[...]

We've (Infra team) so far resisted the pressure to define a
standardized grammar for triggering jobs through review comments
since the goal is to eventually get rid of that as an interface in
favor of some sort of direct mechanism (maybe a rerun button which
calls directly back to a writable Zuul API). Review comments are an
ugly mechanism for this far better served by other means, and
further standardizing their use outside the upstream CI risks making
it harder for us to abandon that model quickly once we have
something better in place.
-- 
Jeremy Stanley

__
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] [horizon] npm lint and test problems in gate

[Timur Sufiev]

JFYI, CR [1] which fixes the corresponding bug [2] was merged on Jun 28, so
it may make sense to recheck you perfectly looking commit if it has been
staying in Gerrit for a while.

[1] https://review.openstack.org/#/c/334582/
[2] https://bugs.launchpad.net/horizon/+bug/1595938

On Mon, Jun 27, 2016 at 10:42 PM Jeremy Stanley  wrote:

> On 2016-06-24 22:08:40 + (+), Jeremy Stanley wrote:
> [...]
> > the gate-horizon-npm-run-test job uses that same configuration
> > (just passing a different {command}) and we're still seeing
> > failures registered for it even now.
> [...]
>
> Just following up since I got a few more minutes to poke at this
> after discussing in IRC: I have confirmed the stats we have in
> graphite seem to match what's recorded by logstash, and dug up
> three example failure logs from today.
>
>
> http://logs.openstack.org/00/334300/1/check/gate-horizon-npm-run-test/469ff89/console.html
>
>
> http://logs.openstack.org/03/320203/9/check/gate-horizon-npm-run-test/e71f803/console.html
>
>
> http://logs.openstack.org/28/333628/5/check/gate-horizon-npm-run-test/5ae2085/console.html
>
> However, there's (thankfully) a consistent explanation. Take a look
> at the timestamp gaps between the penultimate and ultimate lines of
> each log... timeouts! So I agree the issue seems to be lack of
> errexit in the npm-run builder. The old failures observed for
> gate-horizon-npm-run-lint are probably similarly explained as
> timeout issues we've just been lucky enough not to hit in the past
> week or so. Unfortunately those failures fall just outside our
> elasticsearch retention window so confirming that would be a very
> time-intensive exercise at this point.
> --
> Jeremy Stanley
>
> __
> 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] [mistal] Mistral logo ideas?

[Jason Rist]

On 06/29/2016 12:45 AM, Renat Akhmerov wrote:
> They all look good to me, and yes, I’d prefer mistral-tornado.png over 
> mistral.png. I also have the same concern about Michal’s idea if it will be a 
> small picture. Word “Mistral” may not be distinguishable.
>
> One more thing I’d like to add to the discussion: what if move away from 
> having word “Mistral” in the logo at all? It could just a symbol (mascot, if 
> you will) which does not explicitly tell that it’s Mistral.
>
> Renat Akhmerov
> @Nokia
>
> > On 28 Jun 2016, at 22:20, Elisha, Moshe (Nokia - IL) 
> >  wrote:
> >
> > 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
>
>
I was thinking of a tornado with eyes or a tasmanian devil.  Both are wind 
related.  Thoughts?

-J

-- 
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-dev] [swift] Support for unicode filename in tempurl middleware

[Dr Antonio Calanducci]

Hi,

I hope this is the right mailing list to ask this question. In case it's not, 
please direct me to the right one and apologise. 

I have some files stored in a container the use german character (and in 
general non ascii character).
Using the swift REST APIs and python-swiftclient (3.0.0) download/upload 
command I have no problem to handle them.

But when I try to generate tempurl for some of them with python-swiftclient, I 
got errors if I use python 2.7. By the way, switching to python3 I can generate 
properly the tempurl, but the URL is actually not working generating a 401 
error.

Looking at the github repo it seems there is utf8 support for the tempurl key, 
but I am not sure if you support unicode for path too. I am currently using 
swift 2.2.0 on the server.

I read in the docs that I should not encode the path while generating the 
tempurl, but only to actually retrieve from the generate url.

Could you confirm or not that filename with unicode chars are supported and if 
so in which version?

thanks a lot for the attention
All the best
Antonio

-- 

Dr. Antonio Calanducci, PhD
INFN Catania 

Office:+39 095 3785519
Mobile:  +39 349 6762534
Skype:   tcaland

antonio.calandu...@ct.infn.it 
calandu...@unict.it 







smime.p7s
Description: S/MIME cryptographic 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] [TripleO] TripleO deep dive hour?

[Jason Rist]

On 06/28/2016 04:00 PM, James Slagle wrote:
> We've got some new contributors around TripleO recently, and I'd like
> to offer up a "TripleO deep dive hour".
> 
> The idea is to spend 1 hour a week in a high bandwidth environment
> (Google Hangouts / Bluejeans / ???) to deep dive on a TripleO related
> topic. The topic could be anything TripleO related, such as general
> onboarding, CI, networking, new features, etc.
> 
> I'm by no means an expert on all those things, but I'd like to
> facilitate the conversation and I'm happy to lead the first few
> "dives" and share what I know. If it proves to be a popular format,
> hopefully I can convince some other folks to lead discussions on
> various topics.
> 
> I think it'd be appropriate to record these sessions so that what is
> discussed is available to all. However, I don't intend these to be a
> presentation format, and instead more of a q discussion. If I don't
> get any ideas for topics though, I may choose to prepare something to
> present :).
> 
> Our current meeting time of day at 1400 UTC seems to suit a lot of
> folks, so how about 1400 UTC on Thursdays? If folks think this is
> something that would be valuable and want to do it, we could start
> next Thursday, July 7th.
> 
> 

This sounds very useful. Will you be sending out some sort of invite or
notification once you've decided you're going to hold it?

-J

-- 
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] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors

[Brandon Logan]

I think we always expected other distros to be allowed, we just went
with ubuntu/debian in the beginning bc most of us were comfortable with
it.  It would be nice to also get an image working with a micro version
of "Company X" distro, if thats available.  I'd gladly accept taht as
the default image if it was the first.
On Wed, 2016-06-29 at 10:35 -0600, Doug Wiegley wrote:
> > On Jun 29, 2016, at 10:25 AM, Ihar Hrachyshka  wrote:
> > 
> > 
> >> On 29 Jun 2016, at 18:10, Doug Wiegley  
> >> wrote:
> >> 
> >> Interesting discussion, but the first question I’d ask is ‘why’ ?
> >> 
> >> Unlike openstack server software, the amphora are meant to be black box 
> >> appliance images, so why do we want to run different distros on them? Is 
> >> there a deployment scenario you’re concerned with, or other use case?
> > 
> > Because vendors want to keep control for the contents of the image. For 
> > one, Company X may not be particularly happy about shipping and supporting 
> > Ubuntu based images through its channels. And without it, there is no 
> > end-to-end support story for load balancers that the company could sell to 
> > its customers. The company may also want to specialize the image contents 
> > in some way, f.e. inject additional vendor specific security mechanisms, or 
> > ship a new better version of haproxy. 
> > 
> > I believe it’s self evident, but for completeness: Company X engineers 
> > would not support Ubuntu bits because 1. they don’t have expertise in 
> > Ubuntu. 2. it would give a really twisted message to customers.
> 
> Fair enough, and that’s the reply that I was expecting. So either we make the 
> amphora driver distro aware, or multiple amphora drivers/images. I presume 
> that “company x” is willing to devote resources to this?
> 
> Thanks,
> doug
> 
> > 
> > Ihar
> > __
> > 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] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors

[Doug Wiegley]

> On Jun 29, 2016, at 10:25 AM, Ihar Hrachyshka  wrote:
> 
> 
>> On 29 Jun 2016, at 18:10, Doug Wiegley  wrote:
>> 
>> Interesting discussion, but the first question I’d ask is ‘why’ ?
>> 
>> Unlike openstack server software, the amphora are meant to be black box 
>> appliance images, so why do we want to run different distros on them? Is 
>> there a deployment scenario you’re concerned with, or other use case?
> 
> Because vendors want to keep control for the contents of the image. For one, 
> Company X may not be particularly happy about shipping and supporting Ubuntu 
> based images through its channels. And without it, there is no end-to-end 
> support story for load balancers that the company could sell to its 
> customers. The company may also want to specialize the image contents in some 
> way, f.e. inject additional vendor specific security mechanisms, or ship a 
> new better version of haproxy. 
> 
> I believe it’s self evident, but for completeness: Company X engineers would 
> not support Ubuntu bits because 1. they don’t have expertise in Ubuntu. 2. it 
> would give a really twisted message to customers.

Fair enough, and that’s the reply that I was expecting. So either we make the 
amphora driver distro aware, or multiple amphora drivers/images. I presume that 
“company x” is willing to devote resources to this?

Thanks,
doug

> 
> Ihar
> __
> 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] [octavia][upgrades] upgrade loadbalancer to new amphora image

[Kosnik, Lubosz]

May you specify what exact use-case you have to upload incompatible images?
In my opinion we should prepare a flow which is like you said building new 
instance, configuring everything, adding that amphora into load balancer and 
removing old one. In that way we will be able to minimize retry to specific 
Amphorae not all load balancers.
Everything depends of that are we able to do something with Amphora image that 
it will not work any more in cluster with older versions.
 
Lubosz Kosnik
Cloud Software Engineer OSIC
lubosz.kos...@intel.com

> On Jun 29, 2016, at 11:14 AM, Ihar Hrachyshka  wrote:
> 
> Hi all,
> 
> I was looking lately at upgrades for octavia images. This includes using new 
> images for new loadbalancers, as well as for existing balancers.
> 
> For the first problem, the amp_image_tag option that I added in Mitaka seems 
> to do the job: all new balancers are created with the latest image that is 
> tagged properly.
> 
> As for balancers that already exist, the only way to get them use a new image 
> is to trigger an instance failure, that should rebuild failed nova instance, 
> using the new image. AFAIU the failover process is not currently automated, 
> requiring from the user to set the corresponding port to DOWN and waiting for 
> failover to be detected. I’ve heard there are plans to introduce a specific 
> command to trigger a quick-failover, that would streamline the process and 
> reduce the time needed for the process because the failover would be 
> immediately detected and processed instead of waiting for keepalived failure 
> mode to occur. Is it on the horizon? Patches to review?
> 
> While the approach seems rather promising and may be applicable for some 
> environments, I have several concerns about the failover approach that we may 
> want to address.
> 
> 1. HA assumption. The approach assumes there is another node running 
> available to serve requests while instance is rebuilding. For non-HA 
> amphoras, it’s not the case, meaning the image upgrade process has a 
> significant downtime.
> 
> 2. Even if we have HA, for the time of instance rebuilding, the balancer 
> cluster is degraded to a single node.
> 
> 3. (minor) during the upgrade phase, instances that belong to the same HA 
> amphora may run different versions of the image.
> 
> What’s the alternative?
> 
> One idea I was running with for some time is moving the upgrade complexity 
> one level up. Instead of making Octavia aware of upgrade intricacies, allow 
> it to do its job (load balance), while use neutron floating IP resource to 
> flip a switch from an old image to a new one. Let me elaborate.
> 
> Let’s say we have a load balancer LB1 that is running Image1. In this 
> scenario, we assume that access to LB1 VIP is proxied through a floating ip 
> FIP that points to LB1 VIP. Now, the operator uploaded a new Image2 to glance 
> registry and tagged it for octavia usage. The user now wants to migrate the 
> load balancer function to using the new image. To achieve this, the user 
> follows the steps:
> 
> 1. create an independent clone of LB1 (let’s call it LB2) that has exact same 
> attributes (members) as LB1.
> 2. once LB2 is up and ready to process requests incoming to its VIP, redirect 
> FIP to the LB2 VIP.
> 3. now all new flows are immediately redirected to LB2 VIP, no downtime (for 
> new flows) due to atomic nature of FIP update on the backend (we use 
> iptables-save/iptables-restore to update FIP rules on the router).
> 4. since LB1 is no longer handling any flows, we can deprovision it. LB2 is 
> now the only balancer handling members.
> 
> With that approach, 1) we provide for consistent downtime expectations 
> irrelevant to amphora architecture chosen (HA or not); 2) we flip the switch 
> when the clone is up and ready, so no degraded state for the balancer 
> function; 3) all instances in an HA amphora run the same image.
> 
> Of course, it won’t provide no downtime for existing flows that may already 
> be handled by the balancer function. That’s a limitation that I believe is 
> shared by all approaches currently at the table.
> 
> As a side note, the approach would work for other lbaas drivers, like 
> namespaces, f.e. in case we want to update haproxy.
> 
> Several questions in regards to the topic:
> 
> 1. are there any drawbacks with the approach? can we consider it an 
> alternative way of doing image upgrades that could find its way into official 
> documentation?
> 
> 2. if the answer is yes, then how can I contribute the piece? should I sync 
> with some other doc related work that I know is currently ongoing in the team?
> 
> Ihar
> __
> 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] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors

[Ihar Hrachyshka]

> On 29 Jun 2016, at 18:10, Doug Wiegley  wrote:
> 
> Interesting discussion, but the first question I’d ask is ‘why’ ?
> 
> Unlike openstack server software, the amphora are meant to be black box 
> appliance images, so why do we want to run different distros on them? Is 
> there a deployment scenario you’re concerned with, or other use case?

Because vendors want to keep control for the contents of the image. For one, 
Company X may not be particularly happy about shipping and supporting Ubuntu 
based images through its channels. And without it, there is no end-to-end 
support story for load balancers that the company could sell to its customers. 
The company may also want to specialize the image contents in some way, f.e. 
inject additional vendor specific security mechanisms, or ship a new better 
version of haproxy. 

I believe it’s self evident, but for completeness: Company X engineers would 
not support Ubuntu bits because 1. they don’t have expertise in Ubuntu. 2. it 
would give a really twisted message to customers.

Ihar
__
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] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors

[Kosnik, Lubosz]

Unfortunately I will be available on today meeting by phone so I’m not be able 
to discuss in way I would like to so I’m writing here.

May you describe what you understand by that info about configuring agent 
binary on start?
If I’m right the ideal situation would be like this:
1. We’re booting Ampora which is starting agent
2. Agent is calling worker metadata server to inform that is up
3. Agent is taking configuration (probably json) and configuring everything 
inside of the box:
- using that solution we can prepare multiple implementations of our agent - 
driver way - to configure systemd, sysvinit, something other

It’s what you was thinking or maybe you have some other way how you would like 
to organize that?

Lubosz Kosnik
Cloud Software Engineer OSIC
lubosz.kos...@intel.com

On Jun 29, 2016, at 10:26 AM, Nir Magnezi 
> wrote:

Hello,

Lately, I've been working on a fix[1] for the amhpora-agent, which currently 
only support Debian based flavors such as Ubuntu.

The main Issues here:
1. NIC hot plugs: Ubuntu's ethX.cfg files looks different from ifcfg-ethX files 
which are accepted in Linux flavors such a RHEL, CentOS and Fedora, read more 
in the fix commit msg.
2. The usage of Flavor specific features such as 'upstart'.

I would like to have a discussion about the second bullet mentioned above.
Due to the fact that in Octavia the loadbalancer runs inside of an instance 
(Amphora), There are few actions that need to take place in the Amphora 
instance boot process:
a. namespace and NIC created.
b. amphora agent starts
c. haproxy (and possibly keepalived) start

The Amphora-agent leverages[2] the capabilities of 'upstart' to make that 
happen, which is a bit problematic if we wish it to work on other flavors.
The default cloud image for Amphora today is Ubuntu, yet there are few more 
options[3] such as CentOS and Fedora.
Unlike the Ubuntu base image, which uses 'sysvinit', The latter two flavors use 
'systemd'.
This creates incompatibility with the jinja2[4][5] templates used by the agent.

The way I see it there are two possible solutions for this:
1. Include a systemd equivalent in the fix[1] that will essentially duplicate 
the functionality mentioned above and work in the other flavors.
2. Have a the amphora agent be the only binary that needs to be configured to 
start upon boot, and that agent will take care of plugging namespaces and NICs 
and also spawning needs processes. This is how it is done in lbaas and l3 
agents.

While the latter solution looks like a more "clean" design, the trade-off here 
is a bigger change to the amphora agent.

[1] https://review.openstack.org/#/c/331841/
[2] 
https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/listener.py#L128
[3] 
https://github.com/openstack/octavia/blob/master/diskimage-create/diskimage-create.sh#L27
[4] 
https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/upstart.conf.j2
[5] 
https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/sysvinit.conf.j2


Thanks,
Nir
__
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] [Nova] No cells meeting today

[Andrew Laski]

Sorry for the late notice but based on an informal poll of the usual
attendees due to the impending feature freeze everyone is busy with
other things, and there wouldn't be much of anything to discuss this
week. We will resume next week at the normal time.

__
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] [octavia][upgrades] upgrade loadbalancer to new amphora image

[Ihar Hrachyshka]

Hi all,

I was looking lately at upgrades for octavia images. This includes using new 
images for new loadbalancers, as well as for existing balancers.

For the first problem, the amp_image_tag option that I added in Mitaka seems to 
do the job: all new balancers are created with the latest image that is tagged 
properly.

As for balancers that already exist, the only way to get them use a new image 
is to trigger an instance failure, that should rebuild failed nova instance, 
using the new image. AFAIU the failover process is not currently automated, 
requiring from the user to set the corresponding port to DOWN and waiting for 
failover to be detected. I’ve heard there are plans to introduce a specific 
command to trigger a quick-failover, that would streamline the process and 
reduce the time needed for the process because the failover would be 
immediately detected and processed instead of waiting for keepalived failure 
mode to occur. Is it on the horizon? Patches to review?

While the approach seems rather promising and may be applicable for some 
environments, I have several concerns about the failover approach that we may 
want to address.

1. HA assumption. The approach assumes there is another node running available 
to serve requests while instance is rebuilding. For non-HA amphoras, it’s not 
the case, meaning the image upgrade process has a significant downtime.

2. Even if we have HA, for the time of instance rebuilding, the balancer 
cluster is degraded to a single node.

3. (minor) during the upgrade phase, instances that belong to the same HA 
amphora may run different versions of the image.

What’s the alternative?

One idea I was running with for some time is moving the upgrade complexity one 
level up. Instead of making Octavia aware of upgrade intricacies, allow it to 
do its job (load balance), while use neutron floating IP resource to flip a 
switch from an old image to a new one. Let me elaborate.

Let’s say we have a load balancer LB1 that is running Image1. In this scenario, 
we assume that access to LB1 VIP is proxied through a floating ip FIP that 
points to LB1 VIP. Now, the operator uploaded a new Image2 to glance registry 
and tagged it for octavia usage. The user now wants to migrate the load 
balancer function to using the new image. To achieve this, the user follows the 
steps:

1. create an independent clone of LB1 (let’s call it LB2) that has exact same 
attributes (members) as LB1.
2. once LB2 is up and ready to process requests incoming to its VIP, redirect 
FIP to the LB2 VIP.
3. now all new flows are immediately redirected to LB2 VIP, no downtime (for 
new flows) due to atomic nature of FIP update on the backend (we use 
iptables-save/iptables-restore to update FIP rules on the router).
4. since LB1 is no longer handling any flows, we can deprovision it. LB2 is now 
the only balancer handling members.

With that approach, 1) we provide for consistent downtime expectations 
irrelevant to amphora architecture chosen (HA or not); 2) we flip the switch 
when the clone is up and ready, so no degraded state for the balancer function; 
3) all instances in an HA amphora run the same image.

Of course, it won’t provide no downtime for existing flows that may already be 
handled by the balancer function. That’s a limitation that I believe is shared 
by all approaches currently at the table.

As a side note, the approach would work for other lbaas drivers, like 
namespaces, f.e. in case we want to update haproxy.

Several questions in regards to the topic:

1. are there any drawbacks with the approach? can we consider it an alternative 
way of doing image upgrades that could find its way into official documentation?

2. if the answer is yes, then how can I contribute the piece? should I sync 
with some other doc related work that I know is currently ongoing in the team?

Ihar
__
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] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors

[Doug Wiegley]

Interesting discussion, but the first question I’d ask is ‘why’ ?

Unlike openstack server software, the amphora are meant to be black box 
appliance images, so why do we want to run different distros on them? Is there 
a deployment scenario you’re concerned with, or other use case?

Thanks,
doug


> On Jun 29, 2016, at 9:26 AM, Nir Magnezi  wrote:
> 
> Hello,
> 
> Lately, I've been working on a fix[1] for the amhpora-agent, which currently 
> only support Debian based flavors such as Ubuntu.
> 
> The main Issues here:
> 1. NIC hot plugs: Ubuntu's ethX.cfg files looks different from ifcfg-ethX 
> files which are accepted in Linux flavors such a RHEL, CentOS and Fedora, 
> read more in the fix commit msg.
> 2. The usage of Flavor specific features such as 'upstart'.
> 
> I would like to have a discussion about the second bullet mentioned above.
> Due to the fact that in Octavia the loadbalancer runs inside of an instance 
> (Amphora), There are few actions that need to take place in the Amphora 
> instance boot process:
> a. namespace and NIC created.
> b. amphora agent starts
> c. haproxy (and possibly keepalived) start
> 
> The Amphora-agent leverages[2] the capabilities of 'upstart' to make that 
> happen, which is a bit problematic if we wish it to work on other flavors.
> The default cloud image for Amphora today is Ubuntu, yet there are few more 
> options[3] such as CentOS and Fedora.
> Unlike the Ubuntu base image, which uses 'sysvinit', The latter two flavors 
> use 'systemd'.
> This creates incompatibility with the jinja2[4][5] templates used by the 
> agent.
> 
> The way I see it there are two possible solutions for this:
> 1. Include a systemd equivalent in the fix[1] that will essentially duplicate 
> the functionality mentioned above and work in the other flavors.
> 2. Have a the amphora agent be the only binary that needs to be configured to 
> start upon boot, and that agent will take care of plugging namespaces and 
> NICs and also spawning needs processes. This is how it is done in lbaas and 
> l3 agents.
> 
> While the latter solution looks like a more "clean" design, the trade-off 
> here is a bigger change to the amphora agent. 
> 
> [1] https://review.openstack.org/#/c/331841/ 
> 
> [2] 
> https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/listener.py#L128
>  
> 
> [3] 
> https://github.com/openstack/octavia/blob/master/diskimage-create/diskimage-create.sh#L27
>  
> 
> [4] 
> https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/upstart.conf.j2
>  
> 
> [5] 
> https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/sysvinit.conf.j2
>  
> 
> 
> 
> Thanks,
> Nir
> __
> 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

[Sheel Rana Insaan]

Well, I do not belong to core group, but would like to vote for "*man with
micro versions*" tattoo.

Scott well deserves entry to this elite group.. he has always been there in
nova-cinder interactions/discussions, micro versions and many other
valuable additions to cinder component.

Good luck Scott for your next role!!

+1 from my side.

Best Regards,
Sheel Rana


On Wed, Jun 29, 2016 at 9:19 PM, Rosa, Andrea (HP Cloud Services) <
andrea.r...@hpe.com> wrote:

> One more vote from  "not a core member" .
> I am not a core and I am mainly involved in the Nova project where Scott
> presence is always useful
> and valuable when we need to sort out some cinder <-> nova issue.
>
> --
> Andrea Rosa
>
> 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] [tripleo] Network diagram blueprint

[Jason Rist]

On 06/29/2016 08:50 AM, Honza Pokorny wrote:
> Hello folks,
>
> Here is a blueprint that describes a new feature for the tripleo GUI:
> the network diagram.
>
> https://blueprints.launchpad.net/tripleo-ui/+spec/network-diagram
>
> I invite you to voice your opinions and share feedback.
>
> Thanks
>
> Honza Pokorny
>
> __
> 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
>
Hi Everyone - We're trying to determine if this is something we can get into 
Newton.  Please comment if this is crazy town banana pants or not.

-J

-- 
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] [Cinder] Nominating Scott D'Angelo to Cinder core

[Rosa, Andrea (HP Cloud Services)]

One more vote from  "not a core member" . 
I am not a core and I am mainly involved in the Nova project where Scott 
presence is always useful 
and valuable when we need to sort out some cinder <-> nova issue.

--
Andrea Rosa

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

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

[Vladimir Kozhukalov]

This is yet another related patch [1], that removes the code from master
branch and adds retirement warning. Review is welcome.

[1] https://review.openstack.org/#/c/334949/


Vladimir Kozhukalov

On Wed, Jun 29, 2016 at 4:00 PM, Ilya Kharin  wrote:

> Hi Vladimir,
>
> This change is reasonable because the fuel-upgrade repository is not
> supported since the 8.0 release due to the fact that upgrade activities
> were consolidated in the fuel-octane repository. Also, as I know upgrade
> tarballs are no longer supported for the old releases (less or equal 7.0).
>
> I see only one concern here that it can prevent to create some fixes for
> upgrade tarballs for old realease. Otherwise I have not any objections to
> send this repository on the retirement.
>
> Best regards,
> Ilya Kharin.
>
> On Tue, Jun 28, 2016 at 6:18 PM Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> 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
>>
>
> __
> 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] Change in openstack/trove[master]: Ophaned Volume Not Removed on Instance Delete

[Fox, Kevin M]

Thanks for the pointers. These look good, and I'll keep an eye on them. :)

Kevin

From: Peter Stachowski [pe...@tesora.com]
Sent: Wednesday, June 29, 2016 5:06 AM
To: OpenStack Development Mailing List (not for usage questions); Ali Adil
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete

Hi Kevin,

There are a few blueprints in Trove that might address your use case.  See 
https://blueprints.launchpad.net/trove/+spec/snapshot-as-backup-strategy or 
maybe https://blueprints.launchpad.net/trove/+spec/volume-delete-on-terminate . 
 If neither is entirely correct, please feel free to submit a new one.

Thanks!
Peter

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: June-28-16 7:10 PM
To: OpenStack Development Mailing List (not for usage questions); Ali Adil
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete

To me, one of the benefits of cinder is the ability to have the volume outlast 
the vm. So, for example, if you knew a yum upgrade went bad on the vm, but the 
db data is safe, it would be nice to be able to just delete the vm and have 
trove relaunch using the existing volume, not having to import all the data 
again. Or the host it was running on died but the volume is ok. It would be 
very nice if Trove supported this use case.

Thanks,
Kevin

From: Peter Stachowski [pe...@tesora.com]
Sent: Tuesday, June 28, 2016 3:39 PM
To: OpenStack Development Mailing List (not for usage questions); Ali Adil
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete
Hi Will,

Trove is a managed database service.  Once you delete the database, all 
associated volumes with it are also deleted, as is the Nova instance.  One of 
the key benefits of using Trove is that you don’t have to manage 
servers/volumes/security_groups etc.  Also, depending on the provider’s 
implementation, the volume may not be visible to the end user and thus would 
just be left lying around using up resources if it isn’t deleted by Trove 
(while potentially having the use charged back to the end user).  This is the 
case that is being addressed – having a volume left undeleted even if the Nova 
instance is gone (or in this case didn’t start successfully).

Thanks,
Peter


From: Will Zhou [mailto:zzxw...@gmail.com]
Sent: June-28-16 10:55 AM
To: OpenStack Development Mailing List (not for usage questions); Ali Adil
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete

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) 
>>
 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

[openstack-dev] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors

[Nir Magnezi]

Hello,

Lately, I've been working on a fix[1] for the amhpora-agent, which
currently only support Debian based flavors such as Ubuntu.

The main Issues here:
1. NIC hot plugs: Ubuntu's ethX.cfg files looks different from ifcfg-ethX
files which are accepted in Linux flavors such a RHEL, CentOS and Fedora,
read more in the fix commit msg.
2. The usage of Flavor specific features such as 'upstart'.

I would like to have a discussion about the second bullet mentioned above.
Due to the fact that in Octavia the loadbalancer runs inside of an instance
(Amphora), There are few actions that need to take place in the Amphora
instance boot process:
a. namespace and NIC created.
b. amphora agent starts
c. haproxy (and possibly keepalived) start

The Amphora-agent leverages[2] the capabilities of 'upstart' to make that
happen, which is a bit problematic if we wish it to work on other flavors.
The default cloud image for Amphora today is Ubuntu, yet there are few more
options[3] such as CentOS and Fedora.
Unlike the Ubuntu base image, which uses 'sysvinit', The latter two flavors
use 'systemd'.
This creates incompatibility with the jinja2[4][5] templates used by the
agent.

The way I see it there are two possible solutions for this:
1. Include a systemd equivalent in the fix[1] that will essentially
duplicate the functionality mentioned above and work in the other flavors.
2. Have a the amphora agent be the only binary that needs to be configured
to start upon boot, and that agent will take care of plugging namespaces
and NICs and also spawning needs processes. This is how it is done in lbaas
and l3 agents.

While the latter solution looks like a more "clean" design, the trade-off
here is a bigger change to the amphora agent.

[1] https://review.openstack.org/#/c/331841/
[2]
https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/listener.py#L128
[3]
https://github.com/openstack/octavia/blob/master/diskimage-create/diskimage-create.sh#L27
[4]
https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/upstart.conf.j2
[5]
https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/sysvinit.conf.j2


Thanks,
Nir
__
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

[Steven Hardy]

On Wed, Jun 29, 2016 at 02:59:45PM +0200, Dmitry Tantsur wrote:
> On 06/28/2016 01:37 PM, Erno Kuvaja wrote:
> > 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:
> 
> I hope we're not removing it completely...

No, definitely not - we require Swift for several things other than backing
glance, including:

- Storing introspection data from ironic-inspector
- Signals/Metadata-polling for Heat using the tempurl transport
- Mistral deployment workflows, where plans are pushed into swift

> > 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.
> 
> Please leave it there, we need it to support agent_* family of ironic
> drivers.

Yes, we need tempurl for heat metadata/signals and also upload of artefacts
such as puppet modules to the nodes, so we definitely need tempurl.

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-dev] [tripleo] Network diagram blueprint

[Honza Pokorny]

Hello folks,

Here is a blueprint that describes a new feature for the tripleo GUI:
the network diagram.

https://blueprints.launchpad.net/tripleo-ui/+spec/network-diagram

I invite you to voice your opinions and share feedback.

Thanks

Honza Pokorny

__
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

[Steven Dake (stdake)]

Haikel,

We are running master branch of rdo in master of kolla.  Thanks

Regards,
-steve


On 6/29/16, 3:45 AM, "Haïkel"  wrote:

>2016-06-28 17:53 GMT+02:00 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
>>
>
>Yes, we haven't branched Newton in stable repositories, but you can
>get it in trunk repositories.
>Feel free to CC rdo-list or me directly for anything related to packaging.
>
>H.
>
>
>> 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
>>
>
>__
>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] [tools] OpenStack client in a Docker container

[Steven Dake (stdake)]

Gerard,

The best way would be to make a jinja2 file out of your dockerfile and
introduce it as an added container.

Should be fairly straightforward but may require rework.

Regards
-steve

On 6/28/16, 6:20 PM, "Gerard Braad"  wrote:

>Hi Steve,
>
>
>How would you prefer me to approach this? At the moment I am
>generating the images based on some ansible scripts I have in a
>general playbook repository.
>
>regards,
>
>
>Gerard
>
>On Tue, Jun 28, 2016 at 11:56 PM, Steven Dake (stdake) 
>wrote:
>> Gerard,
>>
>> Yup we would take it in Kolla.  Prevents dirtying a system for CLI based
>> operations.
>>
>> Regards
>> -steve
>>
>> From: "Fox, Kevin M" 
>> Date: Tuesday, June 28, 2016 at 4:41 AM
>> To: Gerard Braad , "openst...@lists.openstack.org"
>> , openstack-operators
>> 
>> Subject: Re: [Openstack-operators] [openstack] [tools] OpenStack client
>>in a
>> Docker container
>>
>> Cool. Maybe this could be contributed to the Kolla project?
>>
>> Thanks,
>> Kevin
>
>-- 
>
>   Gerard Braad | http://gbraad.nl
>   [ Doing Open Source Matters ]


__
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] Build the docker images in a graceful way

[Jeffrey Zhang]

On Wed, Jun 29, 2016 at 9:26 PM, Gerard Braad  wrote:

> Although I saw the Ansible Container repo, I wasn't that excited about
> it at the moment. It still feels complicated when compared to how Chef
> describes a container. However, it is still promising.
>

​The ansible container is more complicated. I do not mean to using it
directly. But using the concept that replace the
raw scripts with
ansible-playbook in the Dockerfile . The Dockerfile
will become very simple and the main logical will
​​
enclos
​​
e
​​
the
​A
nsible
playbooks.

Just like what your openstack client container does.​


>
> On the reasons I did not choose to use it either is that Automated
> builds only handle Dockerfiles. I'd rather run a script in a statement
> to ensure it is one layer. and inside this script use Ansible to
> orchestrate when necessary.
>
​



-- 
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] [kolla] Build the docker images in a graceful way

[Jeffrey Zhang]

On Wed, Jun 29, 2016 at 9:26 PM, Gerard Braad  wrote:

> "did Kolla drop support for
> Fedora" ?
>

​no one maintain the fedora and no gate for fedora too. So i am not sure
whether the fedora works.​



-- 
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] [kolla] [tools] OpenStack client in a Docker container

[Gerard Braad]

Hi Jeffrey,


On Wed, Jun 29, 2016 at 9:51 AM, Jeffrey Zhang  wrote:
> i am Interested in you Ansible scripts. Could u share it?

Everything is on GitHub [1] (and Gitlab [2]). I have a constraint that
I have to work with, and that is the Automated builds at the Docker
Registry. This is because I can not use gitlab shared runners to
perform the build (they haven't enabled --privileged for dind to work)
and I prefer not to use travis-ci.

Because of this, I am unable to use Ansible Containers. So basically,
I have a small run script to ensure a single layer, that installs
Ansible, it curls a playbook and runs this against localhost and then
purges Ansible and curl.

The Ansible playbooks are actually tested/reused this way, as I
normally use them to provision new workstations from a Heat template.

I will certainly want to investigate more about Ansible Containers and
the possibility to replace the Dockerfile with this.

Cheers,


Gerard


[1]  https://github.com/gbraad/docker-openstack-client
[2]  https://gitlab.com/gbraad/openstack-client

__
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] Build the docker images in a graceful way

[Gerard Braad]

Hi Jeffrey,


Although I saw the Ansible Container repo, I wasn't that excited about
it at the moment. It still feels complicated when compared to how Chef
describes a container. However, it is still promising.

On the reasons I did not choose to use it either is that Automated
builds only handle Dockerfiles. I'd rather run a script in a statement
to ensure it is one layer. and inside this script use Ansible to
orchestrate when necessary.

Anyways, I will have a better look at your code later... although I
had one question after a quick glance, "did Kolla drop support for
Fedora" ?

regards,


Gerard

On Wed, Jun 29, 2016 at 8:50 PM, Jeffrey Zhang  wrote:
> Recently, Ansible release 2.1 version with lots of new feature. One of the
> interesting feature
> is the management for docker.
>
> Redhat also announced the Ansible Container project[0][1], which can build
> docker images by using
> Ansible Playbooks. No more write the ugly Dockerfile script. I think this
> will be more graceful.
>
> Here the explanation that why not use Dockerfile from ansible-container
> readme file.
>
> A Dockerfile is not much more than a script with hand-crafted shell
> commands. We're well past the
> point where we should be managing build processes with manually maintained
> series of shell scripts.
> That's why we wrote Ansible in the first place, and this is just as
> applicable to containers.
>
> Ansible Container permits orchestration even during the build process,
> whereas docker build does
> not. For example, in a Django project, your VCS may contain a bunch of
> sources for static assets
> that need to be compiled and then collected. With Ansible Container, you can
> compile the static
> assets in your Django container and then collect them into your static file
> serving container.
>
> Many people use Docker for development environments only but then use
> Ansible playbooks to push
> out to staging or production. This allows you to use the same playbooks and
> roles in your Docker
> dev environment as in your production environments.
>
> Ansible Container does all of this without installing SSH, leaving Ansible
> artifacts on your
> built images, or having excess layers to the union filesystem.
>
> I also pushed a PS to implement almost the same thing for Kolla[3].  There
> many benefit for this.
>
> 1. more easy to understand. The original base/Dockerfile is too long, mixed
> with different base image logical
>and different install type. Whereas in the new implement, it is more
> clearly. it is split into multi
>YAML file.
> 2. easy to extend. We can reuse the role concept for the Ansible. For
> example, when you want to extend
>the neutron-server container. You can write your own roles, like
> neutron-server-lbaas role, and just
>add this to the neutron-server playbooks. In this way, we can implement
> the customize issue. ( this will
>implement later.)
> 3. It is also possible to change the exist data. For example, i want to
> change the repo url to a internal
>ones.
> The user can provide a ansible variables file, which hold the new repo url
> and overwrite the
>exist one.
>
> This PS is in POC stage. Post this mail to gather any advise and better
> ideas.
>
> [0] https://github.com/ansible/ansible-container
> [1]
> https://www.helpnetsecurity.com/2016/06/20/ansible-native-container-workflow-project/
> [2] https://review.openstack.org/334208
>
> --
> 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
>



-- 

   Gerard Braad | http://gbraad.nl
   [ Doing Open Source Matters ]

__
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][keystone] is there chance the keystone cached the catalog and can not get the latest endpoints?

[Jeffrey Zhang]

Yes it is the Bug.
Thanks Kairat.

On Wed, Jun 29, 2016 at 8:53 PM, Kairat Kushaev 
wrote:

> Hi,
> Looks like this bug is duplicate of
> https://bugs.launchpad.net/oslo.cache/+bug/1590779
> HTH
>
> Best regards,
> Kairat Kushaev
>
> On Wed, Jun 29, 2016 at 3:32 PM, Jeffrey Zhang 
> wrote:
>
>> In Kolla CI, we see[1]
>>
>> publicURL endpoint for compute service not found
>>
>> this error for many times. The bug is here[0]
>>
>>
>> After some debug, I found the endpoint is exist in the DB. But when
>> running `nova service-list`
>> It says `publicURL endpoint for compute service not found
>> ​`​. After a few seconds, when you run
>> the `nova service-list` again. it works as expected.
>>
>> I think the root cause it the keystone. seem that the keystone cached the
>> catalog, and return
>> the cached version without query it from the DB. So anyone can explain
>> why it happen? and how to
>> avoid this( any workaround?)
>>
>> The env:
>> OS/Docker image: no matter, this happen on both CentOS and Ubuntu
>> OpenStack: master branch
>>
>> [0] https://bugs.launchpad.net/kolla/+bug/1587226
>> [1]
>> http://logs.openstack.org/91/328891/5/check/gate-kolla-dsvm-deploy-oraclelinux-source/3af433c/console.html#_2016-06-29_10_10_33_298298
>>
>> --
>> 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
>>
>>
>
> __
> 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
>
>


-- 
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] [kolla] Build the docker images in a graceful way

[Ryan Hallisey]

Hey Jeff,

Can you write up a spec with the details?  That way the community can see the 
full layout
of the proposal.

Thanks,
-Ryan

- Original Message -
From: "Jeffrey Zhang" 
To: "OpenStack Development Mailing List" 
Sent: Wednesday, June 29, 2016 8:50:28 AM
Subject: [openstack-dev] [kolla] Build the docker images in a graceful way

Recently, Ansible release 2.1 version with lots of new feature. One of the 
interesting feature 
is the management for docker. 

Redhat also announced the Ansible Container project[0][1], which can build 
docker images by using 
Ansible Playbooks. No more write the ugly Dockerfile script. I think this will 
be more graceful. 

Here the explanation that why not use Dockerfile from ansible-container readme 
file. 




A Dockerfile is not much more than a script with hand-crafted shell commands. 
We're well past the 
point where we should be managing build processes with manually maintained 
series of shell scripts. 
That's why we wrote Ansible in the first place, and this is just as applicable 
to containers. 

Ansible Container permits orchestration even during the build process, whereas 
docker build does 
not. For example, in a Django project, your VCS may contain a bunch of sources 
for static assets 
that need to be compiled and then collected. With Ansible Container, you can 
compile the static 
assets in your Django container and then collect them into your static file 
serving container. 

Many people use Docker for development environments only but then use Ansible 
playbooks to push 
out to staging or production. This allows you to use the same playbooks and 
roles in your Docker 
dev environment as in your production environments. 

Ansible Container does all of this without installing SSH, leaving Ansible 
artifacts on your 
built images, or having excess layers to the union filesystem. 

​I also pushed a PS to implement ​almost the same thing for Kolla[3]. There 
many benefit for this. 

​1. more easy to understand. The original base/Dockerfile is too long, mixed 
with different base image logical 
and different install type. Whereas in the new implement, it is more clearly. 
it is split into multi 
YAML file. 
​2. easy to extend. We can reuse the role concept for the Ansible. For example, 
when you want to extend 
the neutron-server container. You can write your own roles, like 
neutron-server-lbaas role, and just 
add this to the neutron-server playbooks. In this way, we can implement the 
customize issue. ( this will 
implement later.) 
3. It is also possible to change the exist data. For example, i want to change 
the repo url to a internal 
ones. ​ 
​ 
​The user can provide a ansible variables file, which hold the new repo url and 
overwrite the 
exist one. 

This PS is in POC stage. Post this mail to gather any advise and better ideas. 

​[0] https://github.com/ansible/ansible-container 
[1] 
https://www.helpnetsecurity.com/2016/06/20/ansible-native-container-workflow-project/
 
[2] https://review.openstack.org/334208 

-- 
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

__
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][keystone] is there chance the keystone cached the catalog and can not get the latest endpoints?

[Boris Bobrov]

On Wednesday 29 June 2016 15:53:15 Kairat Kushaev wrote:
> Hi,
> Looks like this bug is duplicate of
> https://bugs.launchpad.net/oslo.cache/+bug/1590779

Looks like it.

> HTH
> 
> Best regards,
> Kairat Kushaev
> 
> On Wed, Jun 29, 2016 at 3:32 PM, Jeffrey Zhang
> 
> wrote:
> > In Kolla CI, we see[1]
> > 
> > publicURL endpoint for compute service not found
> > 
> > this error for many times. The bug is here[0]
> > 
> > 
> > After some debug, I found the endpoint is exist in the DB. But
> > when
> > running `nova service-list`
> > It says `publicURL endpoint for compute service not found
> > ​`​. After a few seconds, when you run
> > the `nova service-list` again. it works as expected.
> > 
> > I think the root cause it the keystone. seem that the keystone
> > cached the catalog, and return
> > the cached version without query it from the DB. So anyone can
> > explain why it happen? and how to
> > avoid this( any workaround?)
> > 
> > The env:
> > OS/Docker image: no matter, this happen on both CentOS and Ubuntu
> > OpenStack: master branch
> > 
> > [0] https://bugs.launchpad.net/kolla/+bug/1587226
> > [1]
> > http://logs.openstack.org/91/328891/5/check/gate-kolla-dsvm-deploy
> > -oraclelinux-source/3af433c/console.html#_2016-06-29_10_10_33_2982
> > 98
> > 
> > --
> > 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


__
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

[Dmitry Tantsur]

On 06/28/2016 01:37 PM, Erno Kuvaja wrote:

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:


I hope we're not removing it completely...


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.


Please leave it there, we need it to support agent_* family of ironic 
drivers.



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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ilya Kharin]

Hi Vladimir,

This change is reasonable because the fuel-upgrade repository is not
supported since the 8.0 release due to the fact that upgrade activities
were consolidated in the fuel-octane repository. Also, as I know upgrade
tarballs are no longer supported for the old releases (less or equal 7.0).

I see only one concern here that it can prevent to create some fixes for
upgrade tarballs for old realease. Otherwise I have not any objections to
send this repository on the retirement.

Best regards,
Ilya Kharin.

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

> 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
>
__
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][Plugins] Fuel Plugin Builder 4.1.0 released!

[Jonnalagadda, Venkata]

Wow! Thanks Igor for the update.

Thanks & Regards,

J. Venkata Mahesh



-Original Message-
From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com] 
Sent: Wednesday, June 29, 2016 5:58 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Fuel][Plugins] Fuel Plugin Builder 4.1.0 released!

Hey Fuelers,

I'm glad to announce that FPB (fuel plugin builder) v4.1.0 has been released on 
PyPI [1].

It's mostly a maintenance release without new features. Here's a changelog 
highlights:

* `tasks.yaml` is now optional for package version "4.0.0" [2]
* Fuel Mitaka (9.0) is supported by default in package version "4.0.0" [3]
* Use more reliable way to check for `fpm` Ruby GEM [4]
* Add ability for role to conflict with all roles by using `*` sign [5]
* Do not execute `uninstall.sh` on plugin upgrade [6]
* Add possiblity to use generators in `environment_config.yaml` [7]
* Don't put any code to PREUN section if `uninstall.sh` doesn't exist or empty 
[8]
* Allow a user to specify any arbitrary string as role name for cross-deps [9]
* Add deployment tasks v2.1 validation support [10]

- Igor


[1]: https://pypi.io/project/fuel-plugin-builder/4.1.0/
[2]: https://bugs.launchpad.net/fuel/+bug/1552248
[3]: https://bugs.launchpad.net/fuel/+bug/1549276
[4]: https://bugs.launchpad.net/fuel/+bug/1561069
[5]: https://bugs.launchpad.net/fuel/+bug/1547590
[6]: https://bugs.launchpad.net/fuel/+bug/1564123
[7]: https://bugs.launchpad.net/fuel/+bug/1557562
[8]: https://bugs.launchpad.net/fuel/+bug/1574478
[9]: https://bugs.launchpad.net/fuel/+bug/1557997
[10]: https://bugs.launchpad.net/fuel/+bug/1590389

__
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][keystone] is there chance the keystone cached the catalog and can not get the latest endpoints?

[Kairat Kushaev]

Hi,
Looks like this bug is duplicate of
https://bugs.launchpad.net/oslo.cache/+bug/1590779
HTH

Best regards,
Kairat Kushaev

On Wed, Jun 29, 2016 at 3:32 PM, Jeffrey Zhang 
wrote:

> In Kolla CI, we see[1]
>
> publicURL endpoint for compute service not found
>
> this error for many times. The bug is here[0]
>
>
> After some debug, I found the endpoint is exist in the DB. But when
> running `nova service-list`
> It says `publicURL endpoint for compute service not found
> ​`​. After a few seconds, when you run
> the `nova service-list` again. it works as expected.
>
> I think the root cause it the keystone. seem that the keystone cached the
> catalog, and return
> the cached version without query it from the DB. So anyone can explain why
> it happen? and how to
> avoid this( any workaround?)
>
> The env:
> OS/Docker image: no matter, this happen on both CentOS and Ubuntu
> OpenStack: master branch
>
> [0] https://bugs.launchpad.net/kolla/+bug/1587226
> [1]
> http://logs.openstack.org/91/328891/5/check/gate-kolla-dsvm-deploy-oraclelinux-source/3af433c/console.html#_2016-06-29_10_10_33_298298
>
> --
> 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
>
>
__
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] Build the docker images in a graceful way

[Jeffrey Zhang]

Recently, Ansible release 2.1 version with lots of new feature. One of the
interesting feature
is the management for docker.

Redhat also announced the Ansible Container project[0][1], which can build
docker images by using
Ansible Playbooks. No more write the ugly Dockerfile script. I think this
will be more graceful.

Here the explanation that why not use Dockerfile from ansible-container
readme file.

A Dockerfile is not much more than a script with hand-crafted shell
commands. We're well past the
point where we should be managing build processes with manually maintained
series of shell scripts.
That's why we wrote Ansible in the first place, and this is just as
applicable to containers.

Ansible Container permits orchestration even during the build process,
whereas docker build does
not. For example, in a Django project, your VCS may contain a bunch of
sources for static assets
that need to be compiled and then collected. With Ansible Container, you
can compile the static
assets in your Django container and then collect them into your static file
serving container.

Many people use Docker for development environments only but then use
Ansible playbooks to push
out to staging or production. This allows you to use the same playbooks and
roles in your Docker
dev environment as in your production environments.

Ansible Container does all of this without installing SSH, leaving Ansible
artifacts on your
built images, or having excess layers to the union filesystem.

​I also pushed a PS to implement ​almost the same thing for Kolla[3].
There many benefit for this.

​1. more easy to understand. The original base/Dockerfile is too long,
mixed with different base image logical
   and different install type. Whereas in the new implement, it is more
clearly. it is split into multi
   YAML file.
​2. easy to extend. We can reuse the role concept for the Ansible. For
example, when you want to extend
   the neutron-server container. You can write your own roles, like
neutron-server-lbaas role, and just
   add this to the neutron-server playbooks. In this way, we can implement
the customize issue. ( this will
   implement later.)
3. It is also possible to change the exist data. For example, i want to
change the repo url to a internal
   ones. ​
​
​The user can provide a ansible variables file, which hold the new repo url
and overwrite the
   exist one.

This PS is in POC stage. Post this mail to gather any advise and better
ideas.

​[0] https://github.com/ansible/ansible-container
[1]
https://www.helpnetsecurity.com/2016/06/20/ansible-native-container-workflow-project/
[2] https://review.openstack.org/334208

-- 
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] [Fuel][Plugins] Fuel Plugin Builder 4.1.0 released!

[Michal Skalski]

Hi,

Great news, thanks!

Regards,
Michal
> On 29 Jun 2016, at 14:28, Igor Kalnitsky  wrote:
> 
> Hey Fuelers,
> 
> I'm glad to announce that FPB (fuel plugin builder) v4.1.0 has been
> released on PyPI [1].
> 
> It's mostly a maintenance release without new features. Here's a
> changelog highlights:
> 
> * `tasks.yaml` is now optional for package version "4.0.0" [2]
> * Fuel Mitaka (9.0) is supported by default in package version "4.0.0" [3]
> * Use more reliable way to check for `fpm` Ruby GEM [4]
> * Add ability for role to conflict with all roles by using `*` sign [5]
> * Do not execute `uninstall.sh` on plugin upgrade [6]
> * Add possiblity to use generators in `environment_config.yaml` [7]
> * Don't put any code to PREUN section if `uninstall.sh` doesn't exist
> or empty [8]
> * Allow a user to specify any arbitrary string as role name for cross-deps [9]
> * Add deployment tasks v2.1 validation support [10]
> 
> - Igor
> 
> 
> [1]: https://pypi.io/project/fuel-plugin-builder/4.1.0/
> [2]: https://bugs.launchpad.net/fuel/+bug/1552248
> [3]: https://bugs.launchpad.net/fuel/+bug/1549276
> [4]: https://bugs.launchpad.net/fuel/+bug/1561069
> [5]: https://bugs.launchpad.net/fuel/+bug/1547590
> [6]: https://bugs.launchpad.net/fuel/+bug/1564123
> [7]: https://bugs.launchpad.net/fuel/+bug/1557562
> [8]: https://bugs.launchpad.net/fuel/+bug/1574478
> [9]: https://bugs.launchpad.net/fuel/+bug/1557997
> [10]: https://bugs.launchpad.net/fuel/+bug/1590389
> 
> __
> 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] [kolla][keystone] is there chance the keystone cached the catalog and can not get the latest endpoints?

[Jeffrey Zhang]

In Kolla CI, we see[1]

publicURL endpoint for compute service not found

this error for many times. The bug is here[0]


After some debug, I found the endpoint is exist in the DB. But when running
`nova service-list`
It says `publicURL endpoint for compute service not found
​`​. After a few seconds, when you run
the `nova service-list` again. it works as expected.

I think the root cause it the keystone. seem that the keystone cached the
catalog, and return
the cached version without query it from the DB. So anyone can explain why
it happen? and how to
avoid this( any workaround?)

The env:
OS/Docker image: no matter, this happen on both CentOS and Ubuntu
OpenStack: master branch

[0] https://bugs.launchpad.net/kolla/+bug/1587226
[1]
http://logs.openstack.org/91/328891/5/check/gate-kolla-dsvm-deploy-oraclelinux-source/3af433c/console.html#_2016-06-29_10_10_33_298298

-- 
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

[openstack-dev] [Fuel][Plugins] Fuel Plugin Builder 4.1.0 released!

[Igor Kalnitsky]

Hey Fuelers,

I'm glad to announce that FPB (fuel plugin builder) v4.1.0 has been
released on PyPI [1].

It's mostly a maintenance release without new features. Here's a
changelog highlights:

* `tasks.yaml` is now optional for package version "4.0.0" [2]
* Fuel Mitaka (9.0) is supported by default in package version "4.0.0" [3]
* Use more reliable way to check for `fpm` Ruby GEM [4]
* Add ability for role to conflict with all roles by using `*` sign [5]
* Do not execute `uninstall.sh` on plugin upgrade [6]
* Add possiblity to use generators in `environment_config.yaml` [7]
* Don't put any code to PREUN section if `uninstall.sh` doesn't exist
or empty [8]
* Allow a user to specify any arbitrary string as role name for cross-deps [9]
* Add deployment tasks v2.1 validation support [10]

- Igor


[1]: https://pypi.io/project/fuel-plugin-builder/4.1.0/
[2]: https://bugs.launchpad.net/fuel/+bug/1552248
[3]: https://bugs.launchpad.net/fuel/+bug/1549276
[4]: https://bugs.launchpad.net/fuel/+bug/1561069
[5]: https://bugs.launchpad.net/fuel/+bug/1547590
[6]: https://bugs.launchpad.net/fuel/+bug/1564123
[7]: https://bugs.launchpad.net/fuel/+bug/1557562
[8]: https://bugs.launchpad.net/fuel/+bug/1574478
[9]: https://bugs.launchpad.net/fuel/+bug/1557997
[10]: https://bugs.launchpad.net/fuel/+bug/1590389

__
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] [Fuel][Plugins] Transition of SDK to docs.openstack.org

[Irina Povolotskaya]

Hi to everyone,

please be informed that Fuel Plugin SDK is being migrated to
docs.openstack.org to deliver a better dev. experience and versioning.

the current version placed here [1] features the very initial revision of
the SDK, with no specifics of the wiki page content  [2].

*REQUEST:*
if you have some extra feedback for SDK (e.g. for non-documented features),
you are very welcome to file a bug report following instructions [3].

thanks to everyone who contributed to SDK!

[1]
http://docs.openstack.org/developer/fuel-docs/plugindocs/fuel-plugin-sdk-guide.html
[2] https://wiki.openstack.org/wiki/Fuel/Plugins
[3]
http://docs.openstack.org/developer/fuel-docs/plugindocs/fuel-plugin-sdk-guide/additional-information.html

-- 
Best regards,

Irina Povolotskaya
__
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

[Peter Stachowski]

Hi Kevin,

There are a few blueprints in Trove that might address your use case.  See 
https://blueprints.launchpad.net/trove/+spec/snapshot-as-backup-strategy or 
maybe https://blueprints.launchpad.net/trove/+spec/volume-delete-on-terminate . 
 If neither is entirely correct, please feel free to submit a new one.

Thanks!
Peter

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: June-28-16 7:10 PM
To: OpenStack Development Mailing List (not for usage questions); Ali Adil
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete

To me, one of the benefits of cinder is the ability to have the volume outlast 
the vm. So, for example, if you knew a yum upgrade went bad on the vm, but the 
db data is safe, it would be nice to be able to just delete the vm and have 
trove relaunch using the existing volume, not having to import all the data 
again. Or the host it was running on died but the volume is ok. It would be 
very nice if Trove supported this use case.

Thanks,
Kevin

From: Peter Stachowski [pe...@tesora.com]
Sent: Tuesday, June 28, 2016 3:39 PM
To: OpenStack Development Mailing List (not for usage questions); Ali Adil
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete
Hi Will,

Trove is a managed database service.  Once you delete the database, all 
associated volumes with it are also deleted, as is the Nova instance.  One of 
the key benefits of using Trove is that you don’t have to manage 
servers/volumes/security_groups etc.  Also, depending on the provider’s 
implementation, the volume may not be visible to the end user and thus would 
just be left lying around using up resources if it isn’t deleted by Trove 
(while potentially having the use charged back to the end user).  This is the 
case that is being addressed – having a volume left undeleted even if the Nova 
instance is gone (or in this case didn’t start successfully).

Thanks,
Peter


From: Will Zhou [mailto:zzxw...@gmail.com]
Sent: June-28-16 10:55 AM
To: OpenStack Development Mailing List (not for usage questions); Ali Adil
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete

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) 
>>
 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

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

[Peter Stachowski]

Hi Will,

Any time.  ☺  If there is specific functionality that you think is missing and 
would like to see added to Trove, please enter a blueprint.  Thanks!

Peter

From: Will Zhou [mailto:zzxw...@gmail.com]
Sent: June-29-16 12:53 AM
To: OpenStack Development Mailing List (not for usage questions); Ali Adil
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete

Hi Peter,

I got the point and I realize that I am wrong about the fix. Thanks for the 
clarification.
On Wed, Jun 29, 2016 at 6:42 AM Peter Stachowski 
> wrote:
Hi Will,

Trove is a managed database service.  Once you delete the database, all 
associated volumes with it are also deleted, as is the Nova instance.  One of 
the key benefits of using Trove is that you don’t have to manage 
servers/volumes/security_groups etc.  Also, depending on the provider’s 
implementation, the volume may not be visible to the end user and thus would 
just be left lying around using up resources if it isn’t deleted by Trove 
(while potentially having the use charged back to the end user).  This is the 
case that is being addressed – having a volume left undeleted even if the Nova 
instance is gone (or in this case didn’t start successfully).

Thanks,
Peter


From: Will Zhou [mailto:zzxw...@gmail.com]
Sent: June-28-16 10:55 AM
To: OpenStack Development Mailing List (not for usage questions); Ali Adil

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

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) 
>>
 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 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 

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

[Shinobu Kinjo]

It may be better to attach setup.cfg you using, and paste traceback (if
there).

Cheers,
Shinobu

On Wed, Jun 29, 2016 at 4:57 PM, Yipei Niu  wrote:

> Hi all,
>
> I have succeed in registering a config option and obtaining it. So how to
> load an option from a customized file? Through
> cfg.CONF(default_config_files=[setup.cfg]? Still fails loading the config
> options in setup.cfg.
>
> Best regards,
> Yipei
>
> On Wed, Jun 29, 2016 at 8:36 AM, joehuang  wrote:
>
>> Hi, Yipei,
>>
>>
>> "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."
>>
>> You are using entry point but not configuration options for plugin
>> discovery, and no config option you have registered in oslo_config.cfg, so
>> " no such option in group DEFAULT:".
>>
>> Best Regards
>> Chaoyi Huang ( joehuang )
>>
>> --
>> *From:* Yipei Niu [newy...@gmail.com]
>> *Sent:* 28 June 2016 22:05
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Cc:* joehuang; Vega Cai; ski...@redhat.com; 金城 忍
>> *Subject:* Re: [tricircle] About registering and loading a plugin
>>
>> 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

>>>
>>>
>>
>


-- 
Email:
shin...@linux.com
shin...@redhat.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] [trove] Trove meeting today (June 29th) is canceled

[Amrith Kumar]

I'm canceling today's Trove meeting as there is nothing on the agenda and 
several people are either traveling or otherwise unable to make it to the 
meeting.

We will meet again on July 6th.

-amrith

__
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

[Andrew Laski]

 
 
 
On Tue, Jun 28, 2016, at 09:27 PM, Zhenyu Zheng wrote:
> How about I sync updated_at and created_at in my patch, and leave the
> finish to the other BP, by this way, I can use updated_at for the
> timestamp filter I added and it don't need to change again once the
> finish BP is complete.
 
Sounds good to me.
 
>
> On Tue, Jun 28, 2016 at 8:28 PM, Andrew Laski
>  wrote:
>> __
>>
>>
>>
>>
>> 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
>>
> -
> 
> 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] [TripleO] TripleO deep dive hour?

[Swapnil Kulkarni (coolsvap)]

On Wed, Jun 29, 2016 at 4:57 PM, Swapnil Kulkarni (coolsvap)
 wrote:
> On Wed, Jun 29, 2016 at 3:30 AM, James Slagle  wrote:
>> We've got some new contributors around TripleO recently, and I'd like
>> to offer up a "TripleO deep dive hour".
>>
>> The idea is to spend 1 hour a week in a high bandwidth environment
>> (Google Hangouts / Bluejeans / ???) to deep dive on a TripleO related
>> topic. The topic could be anything TripleO related, such as general
>> onboarding, CI, networking, new features, etc.
>>
>> I'm by no means an expert on all those things, but I'd like to
>> facilitate the conversation and I'm happy to lead the first few
>> "dives" and share what I know. If it proves to be a popular format,
>> hopefully I can convince some other folks to lead discussions on
>> various topics.
>>
>> I think it'd be appropriate to record these sessions so that what is
>> discussed is available to all. However, I don't intend these to be a
>> presentation format, and instead more of a q discussion. If I don't
>> get any ideas for topics though, I may choose to prepare something to
>> present :).
>>
>> Our current meeting time of day at 1400 UTC seems to suit a lot of
>> folks, so how about 1400 UTC on Thursdays? If folks think this is
>> something that would be valuable and want to do it, we could start
>> next Thursday, July 7th.
>>
>>
>> --
>> -- James Slagle
>> --
>>
>> __
>> 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
>
> +1

I have done some bootstrapping in the ehterpad [1]. Hoping to see some
action there :)

[1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics

__
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] TripleO deep dive hour?

[Swapnil Kulkarni (coolsvap)]

On Wed, Jun 29, 2016 at 3:30 AM, James Slagle  wrote:
> We've got some new contributors around TripleO recently, and I'd like
> to offer up a "TripleO deep dive hour".
>
> The idea is to spend 1 hour a week in a high bandwidth environment
> (Google Hangouts / Bluejeans / ???) to deep dive on a TripleO related
> topic. The topic could be anything TripleO related, such as general
> onboarding, CI, networking, new features, etc.
>
> I'm by no means an expert on all those things, but I'd like to
> facilitate the conversation and I'm happy to lead the first few
> "dives" and share what I know. If it proves to be a popular format,
> hopefully I can convince some other folks to lead discussions on
> various topics.
>
> I think it'd be appropriate to record these sessions so that what is
> discussed is available to all. However, I don't intend these to be a
> presentation format, and instead more of a q discussion. If I don't
> get any ideas for topics though, I may choose to prepare something to
> present :).
>
> Our current meeting time of day at 1400 UTC seems to suit a lot of
> folks, so how about 1400 UTC on Thursdays? If folks think this is
> something that would be valuable and want to do it, we could start
> next Thursday, July 7th.
>
>
> --
> -- James Slagle
> --
>
> __
> 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

+1

__
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] TripleO deep dive hour?

[jason raju]

+1 , That would be really helpful ..

On Wed, Jun 29, 2016 at 2:21 PM, Sanjay Upadhyay 
wrote:

> +1 great, looking forward to it.
>
> On Wed, Jun 29, 2016 at 5:29 AM, Victoria Martínez de la Cruz <
> victo...@vmartinezdelacruz.com> wrote:
>
>> +1 Awesome idea!
>>
>> 2016-06-28 20:01 GMT-03:00 Emilien Macchi :
>>
>>> Excellent idea, it would also be a good opportunity to take notes and
>>> improve our documentation.
>>>
>>> ---
>>> Emilien Macchi
>>>
>>> On Jun 28, 2016 6:24 PM, "Qasim Sarfraz"  wrote:
>>>
 +2, that would be great.

 On Wednesday, June 29, 2016, James Slagle 
 wrote:

> We've got some new contributors around TripleO recently, and I'd like
> to offer up a "TripleO deep dive hour".
>
> The idea is to spend 1 hour a week in a high bandwidth environment
> (Google Hangouts / Bluejeans / ???) to deep dive on a TripleO related
> topic. The topic could be anything TripleO related, such as general
> onboarding, CI, networking, new features, etc.
>
> I'm by no means an expert on all those things, but I'd like to
> facilitate the conversation and I'm happy to lead the first few
> "dives" and share what I know. If it proves to be a popular format,
> hopefully I can convince some other folks to lead discussions on
> various topics.
>
> I think it'd be appropriate to record these sessions so that what is
> discussed is available to all. However, I don't intend these to be a
> presentation format, and instead more of a q discussion. If I don't
> get any ideas for topics though, I may choose to prepare something to
> present :).
>
> Our current meeting time of day at 1400 UTC seems to suit a lot of
> folks, so how about 1400 UTC on Thursdays? If folks think this is
> something that would be valuable and want to do it, we could start
> next Thursday, July 7th.
>
>
> --
> -- James Slagle
> --
>
>
> __
> 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
>


 --
 Regards,
 Qasim Sarfraz



 __
 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
>
>


-- 
Fear of The LORD is the beginning of Wisdom.
 Proverbs 9:10
 Psalms 111:10
Seek first the kingdom of GOD & HIS righteousness & all these things shall
be added unto you.
 Matthew 6:33
__
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] Replace OSTF with Rally

[Alexander Kostrikov]

Boris, can You take a look on HA scenarios [0] to give a quick feedback on
how it should be implemented with Rally in right way? Plugins/templates/how
yaml should look like.
To make correct comparison of ostf and rally-based version.

Thanks!
[0] http://paste.openstack.org/show/523983/

On Tue, Jun 28, 2016 at 3:34 AM, Boris Pavlovic 
wrote:

> Igor,
>
>
> I wonder what are the benefits of using Rally then? We can run whatever
>> we want by means of MCollective or Ansible. Is there something that could
>> help us? I don't know, maybe some dashboard integration with per test
>> results or running by tests by tag?
>
>
> Benefits are in the Rally framework, engine and integrated tooling, that
> are doing very hard things to provide simple interfaces for writing simple
> plugins that are emulating complicated test cases.
>
> The major benefits are next:
>
> *1) Generalization*
> 1.1) One tool with one reporting system and one output format for all
> kinds of testing strategies (functional, load, perf, scale, ...)
> 1.2) One set of plugins (code) that can be used to generate all kinds of
> testing strategies
> 1.3.) One API for all kinds of testing strategies
>
> *2) Simplicity *
> 2.1) Plugins are really simple to write, usually requires one method to be
> implemented
> 2.2) Auto discovery: adding plugins == add code in special (or specified)
> directory
>
> *3) Reusability & Data Driven approach: *
> 3.1) Split code (plugins) & tests cases (yaml files)
> 3.2) Test cases is mixture of different plugins
> 3.3) Plugins accept arguments
>
> *4) Integrated tooling*
> 4.1) All results are persisted in Rally DB and you can access it in any
> moment
> 4.2) Results can be exported in different formats (you can write even own
> plugins for simplifying integration)
> 4.3) Detailed HMTL reports with task results overview and trends
>
>
>
>
> Before switching Fuel from ostf to rally, I would like to see feature
>> parity comparison. It's very necessary to understand how much work we need
>> to spend to rewrite all our tests in rally way.
>
>
> Totally agree, let's do it.
>
>
> Best regards,
> Boris Pavlovic
>
>
>
> On Mon, Jun 27, 2016 at 8:58 AM, Vladimir Kuklin 
> wrote:
>
>> +1 to initial suggestion, but I guess we need to have a full feature
>> equality (e.g. HA tests for mysql and rabbitmq replication) before
>> switching to Rally.
>>
>> On Mon, Jun 27, 2016 at 6:17 PM, Sergii Golovatiuk <
>> sgolovat...@mirantis.com> wrote:
>>
>>> Hi,
>>>
>>> Before switching Fuel from ostf to rally, I would like to see feature
>>> parity comparison. It's very necessary to understand how much work we need
>>> to spend to rewrite all our tests in rally way.
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Sergii Golovatiuk,
>>> Skype #golserge
>>> IRC #holser
>>>
>>> On Mon, Jun 27, 2016 at 4:32 PM, Alexander Kostrikov <
>>> akostri...@mirantis.com> wrote:
>>>
 Hello, everybody!
 Hello, Alex!
 >I thought Rally was more for benchmarking.  Wouldn't Tempest make
 more sense?
 Rally is a good tool with nice api/usage/extensibility.
 I really liked "up and running tests in 5 minutes" in Rally with clear
 picture of what I am doing.
 So, I 100% for a Rally as a QA.

 Another note:
 We will need to implement some HA tests, probably not in Rally.

 On Mon, Jun 27, 2016 at 4:57 PM, Andrey Kurilin 
 wrote:

>
>
> On Mon, Jun 27, 2016 at 4:46 PM, Igor Kalnitsky <
> ikalnit...@mirantis.com> wrote:
>
>>
>> > On Jun 27, 2016, at 16:23, Alex Schultz 
>> wrote:
>> >
>> > I thought Rally was more for benchmarking.  Wouldn't Tempest make
>> more sense?
>>
>> According to Rally wiki page [1], it seems they have a verification
>> layer (Tempest so far). Hm, I wonder does it mean we will need to rewrite
>> our scenarios for Tempest?
>>
>>
> Rally consists of two main components: Rally Task and Rally
> Verification. They are totally separated.
> Task component is fully pluggable and you can run there whatever you
> want in whatever you want way.
> Verification component is hardcoded now. It was designed for
> managing(install, configure) and launching(execute and store results)
> Tempest. But we have a spec to make this component pluggable too.
>
>
>> - igor
>>
>>
>> [1] https://wiki.openstack.org/wiki/Rally
>>
>> __
>> 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,
> Andrey Kurilin.
>
>
> __
> 

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

[Vasyl Saienko]

Dmitry thanks for rising this question!

On Tue, Jun 28, 2016 at 6:32 PM, 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?
>

Neutron already provides great flexibility by ML2 drivers. Multi hardware
environments can be managed without any problems if Ironic uses Neutron, by
using different ML2 driver for different hardware types.

With multitenancy there might be cases when user don't want to use Neutron
and Neutron ML2 drivers. In this case only specifying network_interface per
node may give full flexibility in multivendor environments.


> 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.
>
>
I vote for greater flexibility in future, even there might be some difficulties
during upgrades.


> 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] [OpenStack-docs] [telemetry] Ceilometer and Aodh install guide(s)

[Ildikó Váncsa]

Hi Andreas,

Thanks for the clarification on this. We will consider the options.

Best Regards,
Ildikó

> -Original Message-
> From: Andreas Jaeger [mailto:a...@suse.com]
> Sent: June 28, 2016 20:44
> 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 06/28/2016 08:23 PM, Ildikó Váncsa wrote:
> > 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.?
> 
> We want the same infra-jobs for all these books and no special rules for
> one of them. Renaming doc/source to doc/developer for a large part of
> our 1100+ repos is a large undertaking...
> 
> Btw. nothing stops the telemetry team to have a special "telemetry-docs"
> repository that includes some of these guides,
> 
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: 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] [kolla] version of python2-oslo-config

[Haïkel]

2016-06-28 17:53 GMT+02:00 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
>

Yes, we haven't branched Newton in stable repositories, but you can
get it in trunk repositories.
Feel free to CC rdo-list or me directly for anything related to packaging.

H.


> 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
>

__
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?

[Dmitry Tantsur]

On 06/29/2016 12:08 PM, Sam Betts (sambetts) wrote:

My use case is supporting mixed hardware environments with hardware that
has greater network capabilities and hardware without these capabilities
without limiting my all my equipment to the lowest common feature set.
The use case I’m describing will have some nodes configured with the
neutron multi-tenant driver (generic hardware, smart switch) and some
nodes configured with a custom neutron multi-tenant+cisco magic network
driver (cisco hardware, smart switch).

Perhaps a it’ll be clearer to understand why we need the driver in the
patches if I give a description of the network drivers and why we’re
adding them, and how I see the the current patches working in an upgrade
scenario:

*Flat*
This matches the existing networking implementation in Ironic today, but
with added validation on conductor start to ensure that Ironic is
configured correctly (cleaning_network_uuid set) to support this feature.

*None*


Python value None means the default, here we're using a string "none", 
and I suggest using something else to avoid confusion. Maybe "manual"?



This is what standalone users have been faking by setting the DHCP
provider to None for a long time. The reason this worked before is
because DHCP providers did more than just set DHCP options and actually
started configuring the cleaning network, this job is now superseded by
the network provider, so we need a true no-op driver for when
configuring cleaning networks is deprecated out of the DHCP provider
interface.

*Neutron*
Multi-tenant neutron network support

The problem I see is that the existing networking behaviour in Ironic is
implicit and affected by different things (DHCP Provider, cleaning
enabled/disabled etc, what driver I’ve configured on the node). I
believe that the upgrade process can be handled in a sane way by doing a
data migration as part of the upgrade and maintaining awareness about
what configuration options a user has set and what that means their
previous configuration actually was, for example:

DHCP Provider: None -> No neutron integration -> Configure existing
nodes to None to match what they’ve actually been getting because of
their configuration
DHCP Provider: Neutron -> Existing neutron integration -> Configure
existing nodes to Flat to match what they’ve been getting because of
their configuration

That was the easy part, to make existing nodes continue to work as
before. Now we have to consider what happens when we create a new node
in Ironic after we’ve upgraded, and I think that Ironic should behave as
such:

DHCP Provider: None,  No network interface in request -> Still no
expressed neutron integration -> Configure node to None because no
neutron integration expressed
DHCP Provider: Neutron, No network interface in request -> Basic neutron
integration implied by DHCP provider -> Configure node to Flat to match
how Ironic works today
DHCP Provider: Neutron, network interface in request -> Basic neutron
integration implied by DHCP provider, but network interface in request
takes priority -> Configure node to requested network interface

I suggest we maintain this behaviour for at least a cycle to allow for
people to upgrade and maintain current functionality and then we can
work out what we want to do with DHCP providers and the default network
interface configuration.

I personally hate the current DHCP provider concept and once we
introduce the new network interfaces and deprecate cleaning from the
existing DHCP providers I believe we should consider the DHCP provider's
usefulness. We have to maintain the current driver interface as it is
today for backward compatibility for those who have out of tree DHCP
providers. But I believe that it is heavily tied to both the network
interface you pick for a node, and also the PXE boot interface (we do
not need DHCP options set for virtual media boot for example). I
personally have been considering whether it should actually be
configured has part of the driver_info when a node is configured for PXE
boot or have the logic merged into the network interfaces itself.

Sam

On 28/06/2016 18:28, "Vladyslav Drok" > wrote:

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 

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

[Sam Betts (sambetts)]

My use case is supporting mixed hardware environments with hardware that has 
greater network capabilities and hardware without these capabilities without 
limiting my all my equipment to the lowest common feature set. The use case I’m 
describing will have some nodes configured with the neutron multi-tenant driver 
(generic hardware, smart switch) and some nodes configured with a custom 
neutron multi-tenant+cisco magic network driver (cisco hardware, smart switch).

Perhaps a it’ll be clearer to understand why we need the driver in the patches 
if I give a description of the network drivers and why we’re adding them, and 
how I see the the current patches working in an upgrade scenario:

Flat
This matches the existing networking implementation in Ironic today, but with 
added validation on conductor start to ensure that Ironic is configured 
correctly (cleaning_network_uuid set) to support this feature.

None
This is what standalone users have been faking by setting the DHCP provider to 
None for a long time. The reason this worked before is because DHCP providers 
did more than just set DHCP options and actually started configuring the 
cleaning network, this job is now superseded by the network provider, so we 
need a true no-op driver for when configuring cleaning networks is deprecated 
out of the DHCP provider interface.

Neutron
Multi-tenant neutron network support

The problem I see is that the existing networking behaviour in Ironic is 
implicit and affected by different things (DHCP Provider, cleaning 
enabled/disabled etc, what driver I’ve configured on the node). I believe that 
the upgrade process can be handled in a sane way by doing a data migration as 
part of the upgrade and maintaining awareness about what configuration options 
a user has set and what that means their previous configuration actually was, 
for example:

DHCP Provider: None -> No neutron integration -> Configure existing nodes to 
None to match what they’ve actually been getting because of their configuration
DHCP Provider: Neutron -> Existing neutron integration -> Configure existing 
nodes to Flat to match what they’ve been getting because of their configuration

That was the easy part, to make existing nodes continue to work as before. Now 
we have to consider what happens when we create a new node in Ironic after 
we’ve upgraded, and I think that Ironic should behave as such:

DHCP Provider: None,  No network interface in request -> Still no expressed 
neutron integration -> Configure node to None because no neutron integration 
expressed
DHCP Provider: Neutron, No network interface in request -> Basic neutron 
integration implied by DHCP provider -> Configure node to Flat to match how 
Ironic works today
DHCP Provider: Neutron, network interface in request -> Basic neutron 
integration implied by DHCP provider, but network interface in request takes 
priority -> Configure node to requested network interface

I suggest we maintain this behaviour for at least a cycle to allow for people 
to upgrade and maintain current functionality and then we can work out what we 
want to do with DHCP providers and the default network interface configuration.

I personally hate the current DHCP provider concept and once we introduce the 
new network interfaces and deprecate cleaning from the existing DHCP providers 
I believe we should consider the DHCP provider's usefulness. We have to 
maintain the current driver interface as it is today for backward compatibility 
for those who have out of tree DHCP providers. But I believe that it is heavily 
tied to both the network interface you pick for a node, and also the PXE boot 
interface (we do not need DHCP options set for virtual media boot for example). 
I personally have been considering whether it should actually be configured has 
part of the driver_info when a node is configured for PXE boot or have the 
logic merged into the network interfaces itself.

Sam

On 28/06/2016 18:28, "Vladyslav Drok" 
> wrote:

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 

Re: [openstack-dev] [TripleO] TripleO deep dive hour?

[Steven Hardy]

On Tue, Jun 28, 2016 at 06:00:11PM -0400, James Slagle wrote:
> We've got some new contributors around TripleO recently, and I'd like
> to offer up a "TripleO deep dive hour".
> 
> The idea is to spend 1 hour a week in a high bandwidth environment
> (Google Hangouts / Bluejeans / ???) to deep dive on a TripleO related
> topic. The topic could be anything TripleO related, such as general
> onboarding, CI, networking, new features, etc.
> 
> I'm by no means an expert on all those things, but I'd like to
> facilitate the conversation and I'm happy to lead the first few
> "dives" and share what I know. If it proves to be a popular format,
> hopefully I can convince some other folks to lead discussions on
> various topics.

Great idea, I'd be happy to volunteer for leading a session on the TripleO
Heat template model, heat debugging and perhaps some other topics.

> I think it'd be appropriate to record these sessions so that what is
> discussed is available to all. However, I don't intend these to be a
> presentation format, and instead more of a q discussion. If I don't
> get any ideas for topics though, I may choose to prepare something to
> present :).

Yeah, I like the Q+A format idea - I've done some slide based discussions
like this and I think a more interactive session (perhaps with some screen
sharing to hack on live examples and walk through code) would be helpful.

Perhaps we should start an etherpad where folks can put their ideas for topics?

I created https://etherpad.openstack.org/p/tripleo-deep-dive-topics but let
me know if you had another location in mind.

We could even broaden the scope so folks either request deep-dive on a
particular topic,  or a live session on "how do I integrate $foo" and we
could hack on some patches live, talking through the process then push the
result to gerrit.

> Our current meeting time of day at 1400 UTC seems to suit a lot of
> folks, so how about 1400 UTC on Thursdays? If folks think this is
> something that would be valuable and want to do it, we could start
> next Thursday, July 7th.

+1, sounds good, 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] [TripleO] TripleO deep dive hour?

[Sanjay Upadhyay]

+1 great, looking forward to it.

On Wed, Jun 29, 2016 at 5:29 AM, Victoria Martínez de la Cruz <
victo...@vmartinezdelacruz.com> wrote:

> +1 Awesome idea!
>
> 2016-06-28 20:01 GMT-03:00 Emilien Macchi :
>
>> Excellent idea, it would also be a good opportunity to take notes and
>> improve our documentation.
>>
>> ---
>> Emilien Macchi
>>
>> On Jun 28, 2016 6:24 PM, "Qasim Sarfraz"  wrote:
>>
>>> +2, that would be great.
>>>
>>> On Wednesday, June 29, 2016, James Slagle 
>>> wrote:
>>>
 We've got some new contributors around TripleO recently, and I'd like
 to offer up a "TripleO deep dive hour".

 The idea is to spend 1 hour a week in a high bandwidth environment
 (Google Hangouts / Bluejeans / ???) to deep dive on a TripleO related
 topic. The topic could be anything TripleO related, such as general
 onboarding, CI, networking, new features, etc.

 I'm by no means an expert on all those things, but I'd like to
 facilitate the conversation and I'm happy to lead the first few
 "dives" and share what I know. If it proves to be a popular format,
 hopefully I can convince some other folks to lead discussions on
 various topics.

 I think it'd be appropriate to record these sessions so that what is
 discussed is available to all. However, I don't intend these to be a
 presentation format, and instead more of a q discussion. If I don't
 get any ideas for topics though, I may choose to prepare something to
 present :).

 Our current meeting time of day at 1400 UTC seems to suit a lot of
 folks, so how about 1400 UTC on Thursdays? If folks think this is
 something that would be valuable and want to do it, we could start
 next Thursday, July 7th.


 --
 -- James Slagle
 --


 __
 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

>>>
>>>
>>> --
>>> Regards,
>>> Qasim Sarfraz
>>>
>>>
>>>
>>> __
>>> 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

[openstack-dev] [tricircle]agenda of weekly meeting of Jun.29

[joehuang]

Hi, team,



After some feature spec patches merged and Mitaka tagging finished, and the 
feauture development is ongoing, the agenda of this weekly meeting is:


IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every 
Wednesday starting from UTC 13:00.



# progress of ‘cross pod L2 networking’ and ‘dynamic pod binding’

# todo list review

# integration test for new features


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

Best Regards
Chaoyi Huang (joehuang)
__
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

[Yipei Niu]

Hi all,

I have succeed in registering a config option and obtaining it. So how to
load an option from a customized file? Through
cfg.CONF(default_config_files=[setup.cfg]? Still fails loading the config
options in setup.cfg.

Best regards,
Yipei

On Wed, Jun 29, 2016 at 8:36 AM, joehuang  wrote:

> Hi, Yipei,
>
>
> "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."
>
> You are using entry point but not configuration options for plugin
> discovery, and no config option you have registered in oslo_config.cfg, so
> " no such option in group DEFAULT:".
>
> Best Regards
> Chaoyi Huang ( joehuang )
>
> --
> *From:* Yipei Niu [newy...@gmail.com]
> *Sent:* 28 June 2016 22:05
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Cc:* joehuang; Vega Cai; ski...@redhat.com; 金城 忍
> *Subject:* Re: [tricircle] About registering and loading a plugin
>
> 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] [mistal] Mistral logo ideas?

[Renat Akhmerov]

They all look good to me, and yes, I’d prefer mistral-tornado.png over 
mistral.png. I also have the same concern about Michal’s idea if it will be a 
small picture. Word “Mistral” may not be distinguishable.

One more thing I’d like to add to the discussion: what if move away from having 
word “Mistral” in the logo at all? It could just a symbol (mascot, if you will) 
which does not explicitly tell that it’s Mistral.

Renat Akhmerov
@Nokia

> On 28 Jun 2016, at 22:20, Elisha, Moshe (Nokia - IL)  
> wrote:
> 
> 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

__
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