Re: [openstack-dev] [Magnum] New Core Reviewers

[taget]

+1 for both.

On 2016年11月08日 03:06, Adrian Otto wrote:

Magnum Core Team,

I propose Jaycen Grant (jvgrant) and Yatin Karel (yatin) as new Magnum Core 
Reviewers. Please respond with your votes.

Thanks,


--
Best Regards,
Eli Qiao (乔立勇), Intel OTC.


__
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][ovo] Need help to understand the exception of NeutronSyntheticFieldMultipleForeignKeys

[taget]

hi Artur,

Thanks for you response and suggestion, I update patch as your 
suggestion [1], but I am not sure if the synth_objs can be loaded 
correctly since
it requires to use foreign_keys to get objects [2]. We may need to 
implement your propose patch `Add support fro multiple foreign keys in 
NeutronDbObject`[3] as some patches requires that too, I will follow up 
with it.


[1]https://review.openstack.org/306685
[2]https://github.com/openstack/neutron/blob/9.0.0.0b2/neutron/objects/base.py#L434
[3]https://review.openstack.org/#/c/357207

Thanks Eli.

On 2016年08月18日 21:20, Korzeniewski, Artur wrote:

Hi,
So in the first place, you do not need the multiple foreign keys in Flavor db 
use case.
You can only declare flavor_id and service_profile_id in 
FlavorServiceProfileBinding object, since the relationships ('flavor' and 
'service_profile') is not used anywhere, only ids.

Secondly, nobody right now is working on improving the situation. I have two 
ideas how to fix it:
The example:
{
'network_id': 'id',
'agent_id': id
}

1) add a name of object to the value ('id' i.e.)
{
'network_id': 'Network.id',
'agent_id': 'Agent.id'
}
It would be kind of complicated to get this used in [1], where the foreign keys 
are accessed

2) get deeper structure like:
{
'Network': {'network_id': 'id'},
'Agent': {'agent_id': id}
}
It looks better, because you just add proper foreign key under the related 
object name. Then you can proceed without any issues in [1], just grab the 
proper object name value as dictionary of single foreign key, you can check the 
[2] to see how it should look like for second option.

Regards,
Artur

[1] 
https://github.com/openstack/neutron/blob/9.0.0.0b2/neutron/objects/base.py#L433
[2] https://review.openstack.org/#/c/357207
-Original Message-
From: taget [mailto:qiaoliy...@gmail.com]
Sent: Thursday, August 18, 2016 5:08 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Cc: Qiao, Liyong <liyong.q...@intel.com>; Bhatia, Manjeet S 
<manjeet.s.bha...@intel.com>; Korzeniewski, Artur <artur.korzeniew...@intel.com>
Subject: [neutron][ovo] Need help to understand the exception of 
NeutronSyntheticFieldMultipleForeignKeys

hi neutron ovo hacker:

Recently I am working on neutron OVO blue print, and found there are some 
blocking (slow progress) issues when tring to add new object to Neutron.

When I try to add Flavor related object on [1], I need to add 2 foreign_keys to 
FlavorServiceProfileBinding :

flavor_id: Flavor.id
service_profile_id: ServiceProfile.id

For ServiceProfile and Flavor object, FlavorServiceProfileBinding is a 
synthetic_fields, we refer FlavorServiceProfileBinding in [2], but in currently 
object base implementation, we only allow synthetic_fields to only have 1 
foreignkeys[3].

can anyone help to clarify this? or give some guide on how to overcome [1]? If 
there's anyone who working on to fix it too?


P. S There are other use case for multiple foreign keys [4]
[1]https://review.openstack.org/#/c/306685/6/neutron/db/flavor/models.py@45
[2]https://github.com/openstack/neutron/blob/9.0.0.0b2/neutron/db/flavors_db.py#L86
[3]https://github.com/openstack/neutron/blob/9.0.0.0b2/neutron/objects/base.py#L429-L430
[4]https://review.openstack.org/#/c/307964/20/neutron/objects/router.py@33



--
Best Regards,
Eli Qiao (乔立勇), Intel OTC.

__
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][ovo] Need help to understand the exception of NeutronSyntheticFieldMultipleForeignKeys

[taget]

hi neutron ovo hacker:

Recently I am working on neutron OVO blue print, and found there are 
some blocking (slow progress) issues when tring

to add new object to Neutron.

When I try to add Flavor related object on [1], I need to add 2 
foreign_keys to FlavorServiceProfileBinding :


flavor_id: Flavor.id
service_profile_id: ServiceProfile.id

For ServiceProfile and Flavor object, FlavorServiceProfileBinding is a 
synthetic_fields, we refer FlavorServiceProfileBinding in [2],
but in currently object base implementation, we only allow 
synthetic_fields to only have 1 foreignkeys[3].


can anyone help to clarify this? or give some guide on how to overcome 
[1]? If there's anyone who working on to fix it too?



P. S There are other use case for multiple foreign keys [4]
[1]https://review.openstack.org/#/c/306685/6/neutron/db/flavor/models.py@45
[2]https://github.com/openstack/neutron/blob/9.0.0.0b2/neutron/db/flavors_db.py#L86
[3]https://github.com/openstack/neutron/blob/9.0.0.0b2/neutron/objects/base.py#L429-L430
[4]https://review.openstack.org/#/c/307964/20/neutron/objects/router.py@33

--
Best Regards,
Eli Qiao (乔立勇), Intel OTC.


__
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] [Zun][Higgins] Proposing Sudipta Biswas and Wenzhi Yu for Zun core reviewer team

[taget]

+1 for both, they would be great addition to zun team.

On 2016年08月12日 10:26, Yanyan Hu wrote:


Both Sudipta and Wenzhi have been actively contributing to the Zun 
project for a while. Sudipta provided helpful advice for the project 
roadmap and architecture design. Wenzhi consistently contributed high 
quality patches and insightful reviews. I think both of them are 
qualified to join the core team.




--
Best Regards,
Eli Qiao (乔立勇), Intel OTC.


__
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] [magnum] ssh and http connection lost

[taget]

Seems there's no relationship with Magnum service at all, you may need 
to fix figure out why you can not access your test machine.


As for as I know, bay-create won't block your network access.

- Eli.

On 2016年08月11日 16:13, Yasemin DEMİRAL (BİLGEM BTE) wrote:


Hi

I installed magnum on devstack successfully. I tired the "magnum 
bay-create --name k8sbay --baymodel k8sbaymodel --node-count 1 " 
command in the guide 
 .
but in i lost my ssh connection for my test machine and http 
connection for horizon. what can i do ? i can not connect to terminal 
screen my test machine ?


Can you help me?

Thanks


__
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,
Eli Qiao (乔立勇), Intel OTC.

__
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] [Magnum] Microversioning implementation

[taget]

Hongbin & team

Please forget Semantic Versioning API, that should not be done in short 
term especially API WG had defined lots

of Microversion API docs, sorry to make confusions.

Of cause that Microversion API is important to OpenStack, and it has 
documented well in API WG [1].
For Magnum, I remember that the implementation idea is from ironic [2], 
it is simple.


For [3] which comes from Nova is complex because that nova implement 
router itself, but Magnum
(Ironic) use pecan. We need to maintain it Magnum as well, also when I 
doing some testing, I still
find some unexpected exception if passing bad Microversion, it should 
follow API WG.


At last Magnum has very few APIs entry point now,
baymodel.py bay.py certificate.py magnum_services.py

Seen from Ironic, it has bump the version to v1.21 [2] with current 
Magnum's microversion's infra


I am okay to go with [3] as long as [3] fellows up with APIWG[1] and 
have better testing, I really don't

want to maintain an infra which won't be used frequently.

[1] https://wiki.openstack.org/wiki/VersionDiscovery
[2] https://github.com/openstack/ironic/blob/master/doc/source/webapi/v1.rst
[3] 
https://review.openstack.org/#/c/343060/8/magnum/api/controllers/v1/bay.py



On 2016年07月29日 03:19, Hongbin Lu wrote:

OK. My replies are inline.


-Original Message-
From: Grant, Jaycen V [mailto:jaycen.v.gr...@intel.com]
Sent: July-28-16 2:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum] Microversioning implementation

I was completely unaware of any discussion of Semantic Versioning.
That was brought up by Eli Qiao in the code review, so he might be the
one to point us in the right direction for that.

Jaycen

-Original Message-
From: Hongbin Lu [mailto:hongbin...@huawei.com]
Sent: Thursday, July 28, 2016 11:10 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [Magnum] Microversioning implementation

Added this to the agenda of next team meeting [1].

I would like to ask clarification for " the community are discussing to
using Semantic Versioning(X.Y.Z) instead of microversion X.Y ". Could
anyone provide more information about that?

Best regards,
Hongbin


-Original Message-
From: Grant, Jaycen V [mailto:jaycen.v.gr...@intel.com]
Sent: July-28-16 10:52 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Magnum] Microversioning implementation


There has been a discussion around micro versioning implementation
going on in the following patch:
https://review.openstack.org/#/c/343060/8 and I was asked to bring it
to the mailing list for further discussion.

Magnum added header support for microversioning according to the
Openstack spec[1] but since we haven’t had any changes yet it was not
being used.  In the patch mentioned above I added code that provides
infrastructure for implementing micro versions for our API methods.

I

took the idea from how Nova implemented micro versioning and used

some

of their code modified to work with Pecan.  The basic idea is that

you

version a method using api_version decorator as shown below:

@base.Controller.api_version("1.1")
 @expose.expose(BayCollection, types.uuid)
 def get_all(self, marker=None):
 """Retrieve a list of bays.
# code for version 1.1

@base.Controller.api_version(“1.2”, “1.3")
@expose.expose(BayCollection,
types.uuid) def get_all(self, marker=None):
"""Retrieve a list of bays.
# code for versions 1.2 through 1.3

@base.Controller.api_version("1.4")
@expose.expose(BayCollection, types.uuid) def get_all(self,
marker=None):
"""Retrieve a list of bays.
# code for version 1.4 to latest version


The api_version code takes care of selecting the correct version

based

on version requested in the header. It also checks for version
overlaps in the methods and gaps in the method versions.


While working on this Vijendar(working on the first api changes that
need api versioning) and myself, evaluated several other alternatives:

1) Just have each method check the version object and handle the
differences. This was the most basic solution and will work but we
were concerned it would add a lot of duplicate code. We were also
concerned it would be messy in the future as more and more micro
versions were added. Each method would now be responsible for
additional checking and more places to change code if there were
overall micro version code changes in the future.

2) Separate pecan controllers for each micro version. When a new

micro

version is added a new controller would be created inheriting from

the

previous version controller. The new controller would override the
modified methods. Routing changes would be added to make sure that

the

correct controller was used depending on the API header.  We felt

that

the api_version decorator was slightly less complicated and less code
overhead 

Re: [openstack-dev] [Magnum] Select our project mascot/logo

[taget]

Does anyone know that Magnum is a brand of ice cream[1]?

I love it! can we use it, maybe it may bring some copyright issue, but I 
don't know..


[1] http://www.magnumicecream.com/us/en/home.html

On 2016年07月27日 13:47, hie...@vn.fujitsu.com wrote:

Hi all,

I think Magnum mascot should be related to something that really big, can cover 
small things inside.
So, my 2$ idea is the yin-yang whale: 
https://s-media-cache-ak0.pinimg.com/736x/90/1d/66/901d66b496d9b5470f22981ab3c16da4.jpg

Best regards,
Hieu LE.

-Original Message-
From: Hongbin Lu [mailto:hongbin...@huawei.com]
Sent: Wednesday, July 27, 2016 9:26 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Magnum] Select our project mascot/logo

Dims,

You are fast :). I believe OpenStack Foundation will coordinate in this case.

Best regards,
Hongbin


-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com]
Sent: July-26-16 9:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum] Select our project mascot/logo

Hongbin,

Moose is already taken by Oslo team (2 summits ago :)

-- Dims

On Tue, Jul 26, 2016 at 9:48 PM, Hongbin Lu 
wrote:

Hi all,



Thanks for providing mascot ideas. As discussed at the team meeting,
below is the short list of popular mascots. I believe you will

receive

a link to vote among them later.

* Waves - http://www.123rf.com/photo_11649085_set-of-waves.html

* Kangaroo - http://www.supercoloring.com/pages/red-kangaroo

* Shark - http://www.logoground.com/logo.php?id=10554

* Majestic moose -


https://images.indiegogo.com/file_attachments/1328366/files/2015032608

3908-Mooselaughing.jpg?1427384348



Best regards,

Hongbin



From: Watson, Stephen [mailto:stephen.wat...@intel.com]
Sent: July-26-16 12:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum] Select our project mascot/logo



+1 for kangaroo and stallion



And my own suggestion even though it doesn’t fit the container or

name

themes directly would be a St. Bernard because dogs and myths are

cool:

http://mentalfloss.com/article/20908/why-are-st-bernards-always-

depict

ed-barrels-around-their-necks



-Stephen



From: Hongbin Lu 
Reply-To: "OpenStack Development Mailing List (not for usage

questions)"


Date: Monday, July 25, 2016 at 5:54 PM
To: "OpenStack Development Mailing List (not for usage questions)"

Subject: [openstack-dev] [Magnum] Select our project mascot/logo



Hi team,



OpenStack want to promote individual projects by choosing a mascot
to represent the project. The idea is to create a family of logos
for OpenStack projects that are unique, yet immediately identifiable
as

part of OpenStack.

OpenStack will be using these logos to promote each project on the
OpenStack website, at the Summit and in marketing materials.



We can select our own mascot, and then OpenStack will have an
illustrator create the logo for us. The mascot can be anything from
the natural world—an animal, fish, plant, or natural feature such as

a

mountain or waterfall. We need to select our top mascot candidates
by the first deadline (July 27, this Wednesday). There’s more info
on

the website:

http://www.openstack.org/project-mascots



Action Item: Everyone please let me know what is your favorite mascot.
You can either reply to this ML or discuss it in the next team

meeting.



Best regards,

Hongbin




__

 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




--
Davanum Srinivas :: https://twitter.com/dims

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


--
Best Regards,
Eli Qiao (乔立勇), Intel OTC.


__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [magnum] Proposing Spyros Trigazis for Magnum core reviewer team

[taget]

I am +1

Eli.

On 2016年07月23日 04:27, Hongbin Lu wrote:


Hi all,

Spyros has consistently contributed to Magnum for a while. In my 
opinion, what differentiate him from others is the significance of his 
contribution, which adds concrete value to the project. For example, 
the operator-oriented install guide he delivered attracts a 
significant number of users to install Magnum, which facilitates the 
adoption of the project. I would like to emphasize that the Magnum 
team has been working hard but struggling to increase the adoption, 
and Spyros’s contribution means a lot in this regards. He also 
completed several essential and challenging tasks, such as adding 
support for OverlayFS, adding Rally job for Magnum, etc. In overall, I 
am impressed by the amount of high-quality patches he submitted. He is 
also helpful in code reviews, and his comments often help us identify 
pitfalls that are not easy to identify. He is also very active in IRC 
and ML. Based on his contribution and expertise, I think he is 
qualified to be a Magnum core reviewer.


I am happy to propose Spyros to be a core reviewer of Magnum team. 
According to the OpenStack Governance process [1], we require a 
minimum of 4 +1 votes from Magnum core reviewers within a 1 week 
voting window (consider this proposal as a +1 vote from me). A vote of 
-1 is a veto. If we cannot get enough votes or there is a veto vote 
prior to the end of the voting window, Spyros is not able to join the 
core team and needs to wait 30 days to reapply.


The voting is open until Thursday July 29st.

[1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

Best regards,

Hongbin



__
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,
Eli Qiao (乔立勇), Intel OTC.

__
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] [Magnum] What is Magnum's behaviour wrt Images in Glance and which ones are downloaded to COE ?

[taget]

On 2016年07月20日 00:35, Waines, Greg wrote:


Does MAGNUM automatically download all Glance Images of a particular 
Container Format to the COE ?



No, Magnum will not do this.
Only  the swarm docker image is download by Magnum.


In the above setup, which Glance Image does the ‘docker image’ 
“cirros” correspond to ?



None of from glance image.

You launched the swarm docker container with image 'cirros', the image 
of 'cirros' was downloaded by docker daemon which is from OFFICIAL image 
hub from https://hub.docker.com/


--
Best Regards,
Eli Qiao (乔立勇), Intel OTC.

__
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] [Kuryr][Magnum] - Kuryr nested containers and Magnum Integration

[taget]

hi Vikas,
thanks for you clarify, relied in lines.

On 2016年06月22日 14:36, Vikas Choudhary wrote:


Magnum:

 1. Support to pass neutron network names at container creation apis
such as pod-create in k8s case.

Hmm. Magnum has deleted all wrapper API for container creation and 
pod-create


 1. If Kuryr is used as network driver at bay creation, update heat
template creation logic for kuryr-agent provisioning on all the
bay nodes. This will also include passing required configuration
and credentials also.



In this case, I am confused, we need to install kuryr-agent on all bay 
nodes, so and kuryr-agent's for binding neutron ports and containers 
port, we will need to install neutron-agent on bay nodes too?



--
Best Regards,
Eli Qiao (乔立勇), Intel OTC.

__
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] [sahara] openstack Unauthorized HTTP 401 'Could not find user' when sahara call heat

[taget]

oh, so old of Juno, Kilo's reached EOL already.

Suggest you to add [sahara] in subject.

On 2016年06月03日 09:51, 阮鹏飞 wrote:





Hi, Friends,

I used Openstack-Juno heat, keystone and Mitaka sahara in CentOS7. 
Sahara is installed in docker container using host network.
When sahara wants to call heat to create a hadoop cluster, the below 
error is happened.
Could you help to check this issue? I guess, the heat couldn't create 
user in keystone. The attachment is the conf file and log file. Please 
reference them.

Thanks for your help in advance. Hoping for your answer.

2016-05-31 11:22:45.625 41759 INFO urllib3.connectionpool [-] Starting 
new HTTP connection (1): 10.252.100.4
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource Traceback 
(most recent call last):
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource   File 
"/usr/lib/python2.6/site-packages/heat/engine/resource.py", line 435, 
in _action_recorder

2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource yield
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource   File 
"/usr/lib/python2.6/site-packages/heat/engine/resource.py", line 505, 
in _do_action
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource yield 
self.action_handler_task(action, args=handler_args)
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource   File 
"/usr/lib/python2.6/site-packages/heat/engine/scheduler.py", line 286, 
in wrapper
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource step = 
next(subtask)
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource   File 
"/usr/lib/python2.6/site-packages/heat/engine/resource.py", line 476, 
in action_handler_task
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource 
handler_data = handler(*args)
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource   File 
"/usr/lib/python2.6/site-packages/heat/engine/resources/wait_condition.py", 
line 143, in handle_create
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource token = 
self._user_token()
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource   File 
"/usr/lib/python2.6/site-packages/heat/engine/stack_user.py", line 75, 
in _user_token
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource 
project_id=project_id, password=password)
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource   File 
"/usr/lib/python2.6/site-packages/heat/common/heat_keystoneclient.py", 
line 410, in stack_domain_user_token
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource 
authenticated=False)
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource   File 
"/usr/lib/python2.6/site-packages/keystoneclient/session.py", line 
430, in post
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource return 
self.request(url, 'POST', **kwargs)
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource   File 
"/usr/lib/python2.6/site-packages/keystoneclient/utils.py", line 318, 
in inner
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource return 
func(*args, **kwargs)
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource   File 
"/usr/lib/python2.6/site-packages/keystoneclient/session.py", line 
346, in request
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource raise 
exceptions.from_response(resp, method, url)
2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource Unauthorized: 
Could not find user: 
haddp45018380-test-master-ajdlwfudliu2-0-hnnojqmbzkbr-test-master-wc-handle-dp4cqhkmtykr 
(Disable debug mode to suppress these details.) (HTTP 401)

2016-05-31 11:22:45.663 41759 TRACE heat.engine.resource

Fred Ruan







__
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,
Eli Qiao (乔立勇), Intel OTC.

__
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] [higgins][devstack][swift] Service name conflict in devstack

[taget]

hi Rana

Thanks for you quick response, really appreciate of your help.

On 2016年05月27日 14:45, Sheel Rana Insaan wrote:

Dear Eli Qiao,

>@Higgins team
>I workaround it by naming them as "higgi-api" and "higgi-cond" (seems 
no magic in "-i")

>Also, the api-port number as "9517", any comments?

We should update the regex.
s- should be updated to ^s- @ 
https://github.com/openstack-dev/devstack/blob/master/lib/swift#L163


 "[[ ,${ENABLED_SERVICES}=~,"s-"]]" should be updated to [[ 
,${ENABLED_SERVICES}=~,^s-]]"
(this regex is still not tested, but regex update will work, this or 
that way)


I will update this for swift soon in devstack after discussing with 
swift team.


So, you can continue with higgins- as service name.

Please let me know in case I missed, something else, you wanted to point.

Best Regards,
Sheel Rana

On Fri, May 27, 2016 at 11:15 AM, taget <qiaoliy...@gmail.com 
<mailto:qiaoliy...@gmail.com>> wrote:


hi team,

I am working on adding devstack plugin for Higgins, meet some
troubles.

I named the service name as higgins-api, higgins-cond. in the
plugin, but I found that devstack try to install swift service,
and I got the reason is that [1], swift plugin try to grep 's-' in
the service name, this may not so good for other new project which
has 's-'
in it's service.

Can we improve swift plugin to use full service name?
Is there any doc that how to naming a new service or the service
name list of OpenStack?

@Higgins team
I workaround it by naming them as "higgi-api" and "higgi-cond"
(seems no magic in "-i")
Also, the api-port number as "9517", any comments?


[1]
https://github.com/openstack-dev/devstack/blob/master/lib/swift#L163


-- 
Best Regards, Eli Qiao (乔立勇)



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Best Regards, Eli Qiao (乔立勇)

__
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] [higgins][devstack][swift] Service name conflict in devstack

[taget]

hi team,

I am working on adding devstack plugin for Higgins, meet some troubles.

I named the service name as higgins-api, higgins-cond. in the plugin, 
but I found that devstack try to install swift service,
and I got the reason is that [1], swift plugin try to grep 's-' in the 
service name, this may not so good for other new project which has 's-'

in it's service.

Can we improve swift plugin to use full service name?
Is there any doc that how to naming a new service or the service name 
list of OpenStack?


@Higgins team
I workaround it by naming them as "higgi-api" and "higgi-cond" (seems no 
magic in "-i")

Also, the api-port number as "9517", any comments?


[1] https://github.com/openstack-dev/devstack/blob/master/lib/swift#L163


--
Best Regards, Eli Qiao (乔立勇)


__
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] [magnum] Discuss the idea of manually managing the bay nodes

[taget]

hi Tom
I like your idea on define a generic approach of bay life cycle operations.

Seems current propose is to allow user dynamically adding/deleting nodes 
from a created bay, what if the master/node flavor in baymodel(bay's 
flavor) ? if a user add a new node with flavor which is not defined in 
baymodel, what the behavior should be like, bad request?


Beside, seems we added a new resource 'node' which will represent a node 
in cluster, then what the node api looks like? how to deail a orphan node?
if a node (or node group) is deleted by user from a bay, destroy 
it(them) or just detach them? We may need to think about node life-cycle 
too.


We can also define a group nodes as node group to allow user do batch 
operation.



On 2016年05月16日 17:28, Cammann, Tom wrote:

magnum bay-manage  reset –hard
magnum bay-manage  rebuild
magnum bay-manage  node-delete 
magnum bay-manage  node-add –flavor 
magnum bay-manage  node-reset 
magnum bay-manage  node-list


--
Best Regards, Eli Qiao (乔立勇)


__
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] [magnum] How to document 'labels'

[taget]

+1 for #2, to keep help message in magnum API server, since we have an 
validation list in API Server, see 
https://review.openstack.org/#/c/312990/5/magnum/api/attr_validator.py@23 .


But, if we chose #2 , CLI should add supporting to retrieve help message 
from API server.


On 2016年05月12日 09:10, Shuu Mutou wrote:

Hi all,

+1 for option #2.

Yuanying drafted following blueprint. And I will follow up this.
https://blueprints.launchpad.net/magnum/+spec/magnum-api-swagger-support

I think, this will be satisfy Tom's comments.

regards,

Shu Muto


__
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, Eli Qiao (乔立勇)


__
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] Should be instance_dir in all nova compute node same ?

[taget]

Thanks Matt

That really surprised me.

On 2016年05月03日 17:42, Matthew Booth wrote:
On Fri, Apr 29, 2016 at 2:47 AM, Eli Qiao > wrote:


hi team,

Is there any require that all compute node's instance_dir should
be same?


Yes. This is assumed in many places, certainly in cold migration/resize.

Matt


--
Best Regards, Eli Qiao (乔立勇)

__
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] Should be instance_dir in all nova compute node same ?

[taget]

hi Timofei

I don't have any specific use case, this issue is found while I am doing 
live migration testing, what I did is:


1. create 2 compute node,
2. create a nfs service on one of compute node, let's say node-2 and 
expose /opt/stack/date/nova/instances

3. mount node-2:/opt/stack/date/nova/instances to node-1 's /mnt
4. specify /mnt as node-1's instance_dir so node-1 and node-2 have 
shared instance_dir(with different path)

5. live migration an instance and fail.


Thanks
Eli.

On 2016年04月29日 19:52, Timofei Durakov wrote:

Hi,

From the first sight there are no restrictions for instance_path 
option. Could you please provide some details about the use case?
I wonder would this functionality be really useful for 
cloud-operators, or we just should add description to instance path 
option, forcing to use the same path on compute nodes?


Timofey



On Fri, Apr 29, 2016 at 4:47 AM, Eli Qiao > wrote:


hi team,

Is there any require that all compute node's instance_dir should
be same?

I recently get an issue while doing live migration with
migrateToURI3 method of libvirt python interface, if
source and dest host are configured with difference instance_dir,
migration will fail since migrateToURI3
requires a new xml, but we don't modified the instance_dir of dest
xml.

I reported a bug on [1]_ , would like to get confirmation before
spend effort working on it.

[1] https://bugs.launchpad.net/nova/+bug/1576245

Thanks.

-- 


Best Regards, Eli Qiao (乔立勇)
Intel OTC China


__
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


--
Best Regards, Eli Qiao (乔立勇)

__
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] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

[taget]

+1,
Looking forward for reviewing this cool feature.

On 2016年04月21日 14:57, Kai Qiang Wu wrote:


Hi Duan Li,

We welcome to that contribution if you had. Just make sure that spec 
can be flexible handle 2 ~ N flavor cases. That could handle future 
requirements for N flavors, as in the ML, I found some ops had such 
requirements.




Thanks

Best Wishes,

Kai Qiang Wu (吴开强 Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193

Follow your heart. You are miracle!

Inactive hide details for "Duan, Li-Gong (Gary, 
HPServers-Core-OE-PSC)" ---21/04/2016 02:31:46 pm---Hi Eli, This is 
exactly wha"Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)" ---21/04/2016 
02:31:46 pm---Hi Eli, This is exactly what I want. If you guys think 
this requirement is reasonable, I’d like to c


From: "Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)" 
To: "OpenStack Development Mailing List (not for usage questions)" 


Date: 21/04/2016 02:31 pm
Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to 
provision minion nodes






Hi Eli,

This is exactly what I want. If you guys think this requirement is 
reasonable, I’d like to commit a design spec so that we could discuss 
it in details.


Regards,
Gary Duan

*From:*Eli Qiao [mailto:liyong.q...@intel.com] *
Sent:*Wednesday, April 20, 2016 5:08 PM*
To:*openstack-dev@lists.openstack.org*
Subject:*Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to 
provision minion nodes



Kannan,

I think Duan Li is talking about using both 2 kinds of (secure-booted 
and non-secure-booted) node deploy *minion* node.


The scenario may like this:
let say 2 flavors:

  o flavor_secure
  o flavor_none_secure

For now, flavor-id in baymodel can only be set as one value, Duan Li's 
requirement is to using flavor-id = [flavor_none_secure, flavor_secure]
and provision one cluster which minion nodes are build from 2 types of 
flavor, then after cluster(bay ) provision finished , passing lable to

let k8s cluster to chose a minion node to start pod on that specific node.


For now, Magnum doesn't support it yet, I think it good to have it, 
but the implementation may be differnece per COE since after we

provision bay, the scheduler work are done by k8s/swarm/mesos.

Eli.

On 2016年04月20日16:36, Kai Qiang Wu wrote:

Hi Duan Li,

Not sure if I get your point very clearly.

1> Magnum did support :_

__https://github.com/openstack/magnum/blob/master/magnum/api/controllers/v1/baymodel.py#L65_

flavor-id for minion node
master-flavor-id for master node

So your K8s cluster could have such two kinds of flavors.


2> For one question about ironic case (I found you deploy on
ironic), I did not think Magnum templates now support ironic
case now.
As ironic VLAN related feature are still developing, and not
merged(many patches are under review, pick one for example
_https://review.openstack.org/#/c/277853_)


I am not sure how would you use ironic for k8s cluster ?

-- 
Best Regards, Eli Qiao (乔立勇)

Intel OTC

China__
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


--
Best Regards, Eli Qiao (乔立勇)

__
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] [Magnum]Cache docker images

[taget]

hi hello again

I believe you are talking about this bp 
https://blueprints.launchpad.net/magnum/+spec/cache-docker-images
then ignore my previous reply, that may another topic to solve network 
limited problem.


I think you are on the right way to build docker images but this image 
could only bootstrap by cloud-init, without cloud-init
the container image tar file are not loaded at all, but seems this may 
not be the best way.


I'v suggest that may be the best way is we pull docker images while 
building atomic-image. Per my understanding, the
image build process is we mount the image to read/write mode to some tmp 
directory and chroot to to that dircetory,

we can do some custome operation there.

I can do a try on the build progress(guess rpm-ostree should support 
some hook scripts)



On 2016年04月19日 11:41, Eli Qiao wrote:

@wanghua

I think there were some discussion already , check 
https://blueprints.launchpad.net/magnum/+spec/support-private-registry
and 
https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig 


On 2016年04月19日 10:57, 王华 wrote:

Hi all,

We want to eliminate pulling docker images over the Internet on bay 
provisioning. There are two problems of this approach:

1. Pulling docker images over the Internet is slow and fragile.
2. Some clouds don't have external Internet access.

It is suggested to build all the required images into the cloud 
images to resolved the issue.


Here is a solution:
We export the docker images as tar files, and put the tar files into 
a dir in the image when we build the image. And we add scripts to 
load the tar files in cloud-init, so that we don't need to download 
the docker images.


Any advice for this solution or any better solution?

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


--
Best Regards, Eli Qiao (乔立勇)
Intel OTC China


__
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, Eli Qiao (乔立勇)

__
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] [magnum] Proposing Eli Qiao for Magnum core reviewer team

[taget]

hi hongbin & team.

Thanks for all your supporting, Magnum core team and the community, I am 
very glad to have this opportunity
to join this team. I will try my best to contribute Magnum team and 
OpenStack community.


Thanks
Eli.

On 2016年04月08日 03:35, Hongbin Lu wrote:


Hi all,

Thanks for your feedback. The vote is unanimous. Eli Qiao has been 
added to the core team [1].


[1] https://review.openstack.org/#/admin/groups/473,members

Best regards,

Hongbin



--
Best Regards, Eli Qiao (乔立勇)

__
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